[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Registry of Registries: RE: Comments on ebXML-V_0.7
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) srh@us.ibm.com, Fax: 512-838-1074 "Nieman, Scott" <Scott.Nieman@NorstanConsulting.com> on 07/25/2000 11:03:22 AM To: "'Petit, John'" <jpetit@kpmg.com> cc: ebXML-arch List <ebxml-architecture@lists.ebxml.org> 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:jpetit@kpmg.com] 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:Scott.Nieman@NorstanConsulting.com] 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: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.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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC