Re: Topic 1: Terminolgy alignment

[Len Gallagher <LGallagher@nist.gov>]

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
**************************************************************