Scott, John,
Related to John's Registry of Registry is a document I distributed to spur
discussion at
http://www.ebxml.org/working/project_teams/business_process/IBMRegistryDraft4.pdf
.
Perhaps we could have more discussion on the RegRep Distribution Model in
SJ.
Scott Hinkelman
Senior Software Engineer, SWG IBM Austin
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
[email protected], Fax: 512-838-1074
"Nieman, Scott" <[email protected]> on 07/25/2000 11:03:22
AM
To: "'Petit, John'" <[email protected]>
cc: ebXML-arch List <[email protected]>
Subject: Registry of Registries: RE: Comments on ebXML-V_0.7
there has been very little elaboration work done on this concept.� I agree
that there needs to be a mechanism similar to this concept, but I am
concerned that the registry of registries may force registration authority
control and maintanance issues (again, it may be debated otherwise).� To
me self-service will be vital to the concepts success, and must follow a
DNS like model.
Scott
-----Original Message-----
From: Petit, John [mailto:[email protected]]
Sent: Tuesday, July 25, 2000 10:54 AM
To: 'Nieman, Scott'
Cc: ebXML-arch List
Subject: RE: Comments on ebXML-V_0.7
Scott,
Regarding your line 413 - 414 comment on the synchronization of networked
registries (registry to registry). This relates to the "Registry of
Registries" concept which would tie the whole ebXML universe together. Has
this "Registry of Registries" concept progressed much since Brussels? I
think that it greatly increases the power, cohesiveness, and utility of
ebXML. If it has gained momentum, perhaps we should touch on this in the
architecture document.
I agree that we do not need to delve into how duplication is prevented
within the Arch doc. This was more for my own interest.
-----Original Message-----
From: Nieman, Scott [mailto:[email protected]]
Sent: Tuesday, July 25, 2000 9:29 AM
To: 'Petit, John'; Duane Nickull; ebXML-arch List
Subject: 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.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.1In 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
