ebxml-regrep message

OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

Subject: Re: External ID draft


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


fn:Farrukh Najmi

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC