Re: Topic 1: Terminolgy alignment

[Farrukh Najmi <Farrukh.Najmi@east.sun.com>]

This message is about the substance issues raised by Len in his latest email. I am
grateful that Len echoes my sentiment about working on substance issues of which
there are so very many.



Len Gallagher wrote:
<snip>

> 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 agree 100% that the (1, 2 and 4) distinctions you state, need to be very clear.
The only issue is picking the terminology that we feel is best. I am not wed to my
termonology proposals in the first message of the thread. However, it did state my
concerns about the OASIS terminologies suggested and reasons why I felt those
concerns and the history that led to the current choices. In the interest of
avoiding confusion, I recommend we use the RIF 0.1 terms for discussion until the
issue is resolved.

So far my thinking on the terminology has not shifted. Lets hear some other ideas
and then if there is deadlock then we could take a vote. We all agree that we need
to get past the terminology and focus and the model issues.

The one model issue I see is in 3) above. It is also related to object
identification in the global issues thread. IMHO, (this is not a strong opinion but
just thinking out loud) we should have one element in model for a managed object.
The ManagedObject metadata instance should have methods to determine whether it is
local or remote. In other words my bias is to hide the details of whether an object
is local or remote.
This simplifies the model so there is'nt a third Object sub-class besides
ManagedObject and ExternalObject. Team share your thoughts.

Notice in this discussion how ExternalObject is becoming ambiguous. I am begining
to get disenchanted with ExternalObject. I have suggsted LinkedObject and I am now
also throwing in ReferencedObject. However, I see the same ambiguity issues with
all of my new sugegstions. Are'nt 2 managed objects that have an association
'linked' in the english language sense. However, I like them better than
RelatedData. I am willing to accept whatever the teams concensus is on
ExternalData. I would just like a second or third opinion.

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

Len, you unintentionaly brought up another excellent global issue (need for a
common namespace scheme). IMHO it should be added to the Topic 0 list for TA to
address. I like your suggestions (ebxml, oasis) though as being obvious. Scott, as
our link to TA could you consolodate the global issues and raise it in that group?
Keep us posted on if/when they are likely to get addressed in some document.

But you raise some very complicated and thought provoking issues about how objects
could be shared across repositories and the potentially complex workflows involved.
I do not feel I have the competence to have an opinion on the scenarios you suggest
in the absence of associated requirements. Maybe you can help reshape these
thoughts and experiences by taking the task of getting the requirements doc updated
and formalized for team review. You have the perfect background to get the
requirements identified.

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

Agreed. Any dissenting opinions?

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

Len, you have finally adressed by underlying fear or concern (now realized as
unfounded) that you were trying to have us adopt OASIS lock stock an barrel. This
concern may explain my being a little defensive and misreading the terminlogy map.

Thank you. We are now fully engaged and I think we will get a mind meld very soon
on the immediate fundemental issues and later the Tokyo related issues. I think we
should consider a face to face meeting in the next couple of weeks. What do you
guys think?

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