Subject: Re: External ID draft
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