RE: Comments on ebXML-V_0.7

["Nieman, Scott" <Scott.Nieman@NorstanConsulting.com>]

Line 413-414: I believe another form of synchronization occurs between networked registries (registry to registry).  The existing architectural statements focus on ensuring the links are accurate.  Some registries which focus on housing specific vertical specifications may have "dependencies" to other specifications residing in a completely different registry/repository.  When a specification changes (is versioned), the registry that houses the specification could/should issue a publish event to notify all subscribing registries that the specification(s) which have this dependency may be affected by the change. 

 

e.g., OMG may have a registry / repository that houses its specifications, and when the UML metamodel changes from v1.3 to v1.4,  registries that store UML models should be notified of this change.  Sorry for the bad example, but you may get the point.

 

Line 490:  This section talks about classification as standardized objects...I don't see a list anywhere about the OTHER types of classifications.  A vital part of the registry is that a registered object is associated to a classification scheme.  There will be multiple "types" (in UML sense too) of classification schemes for registered objects and a registered objects may classified under multiple schemes.  the ANSI ASC X3 group's X3.285 (proposed addition to ISO 11179) has this notion and should be looked at.  By classifying an object according to a scheme and indexing according to these schemes will make searching faster and allow hierarchical navigation (browsing).  This document should at minimum suggest "that core components and business processes each need a classification scheme" (in order to find them within a repository).  The Boeing eBIS document suggests a number of classifications required, and could be incorporated in concept.  I believe the eBIS document was submitted to ebXML prior to the Brussels meeting.

 

Line 508-521: Defining Processes: It seems that "deriving XML syntax from UML models" may impose a requirement on the registry / repository for transformation services.  We did identify this in Part1, but as an optional service that rides on top of a registry. 

 

I also question whether 2.2.7.c needs to in this document, as I strongly believe that the SME would never 1) care about what a business process looks like, or 2) know how to integrate business processes if they are different.  They just want "stuff" to work...and "now".  I believe that the "customer" is the software developer and integration specialists, and in the long term intelligent software agents (produced by software developers and configured by SMEs based on their business profile).  The vision has been to make available low cost software components that comply with specified business processes including the definitions of which scenarios within a process it complies with.  If the SME wants to "see" the business process, that is a matter of rendering.

 

Line 541-542: I think the architecture document does NOT need to delve into HOW duplication is prevented (to counter John's comment below).  That is an implementation consideration. 

Scott

-----Original Message-----
From: Petit, John [mailto:jpetit@kpmg.com]
Sent: Monday, July 24, 2000 3:10 PM
To: Duane Nickull
Cc: ebXML-arch List
Subject: Comments on ebXML-V_0.7

Some of these line reference numbers may be slightly off.

 

Line 417: A repository and registry shall synchronize their contents with one another in a symbiotic “publish/subscribe” relationship.

Can we expand on this by adding "This is a synchronization of pointers from the Registry to the Repository. Not a synchronization of content data."

 

Line 512: A component library also facilitates the development of software components.

Why is this under repository object definition? If it does, the relationship needs to be better explained (or at least link to the Reg/Rep document that does).

Should also add a line in this section that states " Repository objects can have associated binary files (gifs, movs, picts, etc.)." Although this is assured by the XML specification docs to which repository object follow, I think that it should be mentioned so that developers know that catalogs of binary objects can be part of the ebXML repository (if only by association).

 

Line 555: At the stage a new submission is received, it shall be examined by the Repository Authority who shall have a mandate to avoid duplication of atomic data elements.

Is the mechanics of how duplication of atomic data elements can be avoided described elsewhere?

 

I suggest that we move Repository object up to 2.2.6 thru 2.2.9 up under 2.2.2. In this way, we get the registry/repository decriptions done before we start to discuss the interactions between them.

Line 584: Figure 2.2.1 In the above example, Party 1 has attributes which can be extracted and labelled as data elements (repository objects).

This is confusing. You mean “additional repository objects.” The way the sentence is structured now, it seems as though you are saying that only data elements are repository objects.

 

Line 628: It is to be used by the Query mechanism to locate the repository data element.

You seem to be saying that there would be a unique ID at the data CONTENT, or value, level. I do not believe that you are saying that in a XML phone book, each unique phone number would also have a unique identifier. Rather we should be saying that the data element definition (at the DTD or Schema level) would have a unique id. Otherwhise there would be tremendous data bloat. This is illustrated by the following example. Here the values are changed but the schema level IDs remain the same.

Identifier	Description	Value
PARTYNAME	NAME	Billy Bob’s Rock House
MEE002	STREET ADDRESS	5492 Endover Rd.
VILLE	CITY	Los Angeles
THDX3	Province	CA
ZIP	ZIP	91011
AREACODE	PREFIX	(818)
FONE	PHONE	790-1100

 

The idea needs to be stated more accurately (perhaps using an illustration similar to above).

Also, lets coordinate of re-doing the graphics BEFORE the next meeting. It will not take that long, and will make the document much more professional looking.

Cheers, John Petit
KPMG
XMLfs Team
Office: 970 728 9468
Mobile: 312 961 8956