Re: External ID draft

[Yutaka Yoshida <Yutaka.Yoshida@eng.sun.com>]

David,

I'm still confused. I thought CC is yet another repository
item and in that case, your discussion doesn't sound legitimate
to me. Or, are you saying we have to register CC as a metadata?

yutaka yoshida
Sun Micorystems

 > Date: Fri, 9 Mar 2001 02:27:01 -0500
 > From: David RR Webber <Gnosis_@compuserve.com>
 > 
 > 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.