Re: External ID draft

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