Subject: Re: External ID draft
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.
eList eXpress LLC