← Prev in month
← Prev in thread
RE: Comments on ebXML-V_0.7
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:[email protected]]
Sent: Monday, July 24, 2000 3:10 PM
To: Duane Nickull
Cc: ebXML-arch List
Subject: Comments on ebXML-V_0.7Some 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
← Prev in month
← Prev in thread