[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Topic 1: Terminolgy alignment
Len, I stand corrected. Having just reread your post you were simply providing a mapping and not suggesting a change. This red-herring was not intentional but just a result of poor reading on my part. I apologize for the misunderstanding. Lets move on to substance. This email is just an admission of guilt. Len Gallagher wrote: > At 01:19 AM 9/21/00 , Farrukh Najmi - JavaSoft East wrote: > >name). So for example description was with lower case rather than upper > >case as Len suggested it should be. I am a little surprised by that level of > >expected consistency ('d' Vs. 'D') with OASIS or anything else. I > >hope that the team does not expect us to use OASIS verbatim. > > This discussion over spelling and naming is a red herring. The mappings in > my comments were simply to map the proposed ebXML name to the OASIS name. I > only asked that the mappings be included in the table in the Appendix! > Camel naming conventions are OK with me, although that looks a bit funny > sometimes when making higher-level presentations. > > The substantive part of the comments are that ebXML should make a > distinction among the following objects: > > 1) the content of the object itself > (e.g. registered object) > > 2) a reference to metadata for a registered object in a registry > (e.g. registry item) > > 3) a distinction among registry items in the local registry implementation > versus registry items in a separate remote ebXML conforming > registry/repository. > (e.g. local registry item vs remote registry item) > > 4) objects that are not managed in any registry, the registry simply keeps > a list of tagged URL's that can be listed as informational items about > a registry item. > (e.g. related data) > > I feel it is critical that the ebXML specification recognize and respect > the distinction between "registry item" and "registered object" and respect > the fact that they may have different owners. One industry consortium may > want to register an object owned and maintained by some other industry > consortium, thus they may create a registry item that points to the > external registered object. In that case the "ebxml:url" or > "oasis:ObjectLocation" in the local registry item would be the same as the > "url" or "ObjectLocation" in the remote registry, but the two registry > items may have other different content. For example, the description in > the local registry may be from that consortium's perspective, which may > differ from the description in the remote registry. And some of the > associations may emphasize different things of importance. So the metadata > about the same registered object in the two registries may be quite > different. The two registries will likely want standardized registry to > registry protocols so that they can share registry metadata as appropriate. > But they will insist upon local control over the things they own and manage! > > Once we get over this hurdle I think progress will come quickly! Yes -- > things will be a bit more complex, since we'll have to consider conflicting > interests among the owners of registered objects and owners of external > registry items that reference the registered object, but that's the real world. > > If the need to keep these items distinct is supported by the group, then I > think a few global changes to the proposed document, and a few paragraphs > of explanation, can put it into shape for potential adoption as a base > document for an "ebXML registry/repository Information Model". Note: I > suggest adding "registry" to the title to emphasize that the information > model describes both the registry model and the repository model. In this > sense it is an extension of the OASIS model (which is only a registry > model), since the ebXML model will likely give special treatment to the > storage and maintenance of special ebXML objects, e.g. profiles, TPA's, > core components, etc. > > Sincerely, > Len Gallagher > > ************************************************************** > Len Gallagher LGallagher@nist.gov > NIST Work: 301-975-3251 > Bldg 820 Room 562 Home: 301-424-1928 > Gaithersburg, MD 20899-8970 USA Fax: 301-948-6213 > ************************************************************** -- Regards, Farrukh
begin:vcard n:Najmi;Farrukh tel;fax:781-442-1610 tel;work:781-442-0703 x-mozilla-html:TRUE url:www.sun.com org:Sun Microsystems;Java Software adr:;;1 Network Drive, MS BUR02-302;Burlington;MA;01803-0902;USA version:2.1 email;internet:najmi@east.sun.com fn:Farrukh S. Najmi end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC