OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: Topic 1: Terminolgy alignment


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


org:Sun Microsystems;Java Software
adr:;;1 Network Drive, MS BUR02-302;Burlington;MA;01803-0902;USA
fn:Farrukh S. Najmi

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC