Re: External ID draft

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

David,

I have been under the assumption that a core component is a repository
item and not a registry entry. Do you have some new information from CC
that says that they are RegistryEntry? If I am correct then we still do
not have a use case for justifying URI for RegistryEntry.


David RR Webber wrote:

> Message text written by Yutaka Yoshida
> >
> David,
>
> I think there's a misunderstanding. I suppose it's
> my action item to address the external ID and I already
> proposed that a few days ago. As far as I understand,
> your action item was to figure out the linkage mechanism
> between uri and the internal ID.(correct me if I'm wrong)
>
> yutaka yoshida
> Sun Microsystems
>
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
> Yutaka,
>
> Not really!  I sensed on the Conf call that we all were envisioning
> different things!!
>
> Here's one use case scenario that I see right off the bat that is
> a need to solve.
>
> Core components.  These are definately in the registry, not the
> repository, as per Farrukh's note.
>
> Therefore - if a schema is comprised of Core components (CCmp),
> we need an XML way to link to those CCmp from the schema XML
> itself.
>
> The UID provides this very simply and elegantly as an attribute
> of each CCmp reference within the schema.
>
> We really cannot address this any other way.
>
> So the notion is not one of linking between a URI and an internal
> ID, it is an external reference mechanism that links to an
> existing business domain - such as EDI element dictionary.
> If EDI elements are placed in the registry as CCmp using XML
> content as envisioned by CCmp group, and then we have no
> way to cross associate based on an external coding, then the
> whole thing breaks and we cannot guarantee interoperability
> between schema, nor associate behaviours.
> And these are central requirements of ebXML.
>
> OK - that's just one instance - but probably that alone shows
> that this is a critical need.  Coupled to versioning as CCmp
> see it - and as I detailed this as a suffix mechanism, then we
> again see that versioning base on GUID is just not going
> to work for implementing CCmp's into a schema.
>
> We probably need to have another Conf Call on this - or
> for me to try and explain this better in extending the document.
> My concern in the draft was to provide an open mechanism
> that was not too constrained - the alternative approach is
> to make a very constrained mechanism - however the
> approach we have always taken is to avoid tightly
> bound solutions in favour of generic.
>
> What I proposed is deliberately very generic to allow
> broad use well beyond just CCmp linkage.
>
> Thanks, DW.
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-regrep-request@lists.ebxml.org

--
Regards,
Farrukh

begin:vcard 
n:Najmi;Farrukh
tel;work:781-442-0703
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh Najmi
end:vcard