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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: Core Component Analysis - SWIFT's Comments

This discussion seems to have wandered down a path we have been before.

To avoid conflicts of 'name this' verse 'name that' - the TA and the
Registry are
both working on the basis of UID's - and by internal extension GUID's
generated internal registry codes) to create linkage and cross-referencing.

For extended details on this see http://www.bizcodes.org

In a nutshell this works by associating a UID attribute with a tag, so
in the well formed XML you have:


and in the DTD (or schema) you associate a UID value:

<!ELEMENT foobar (#PCDATA)>

<!ATTLIST foobar
                       UID CDATA  '[urn:]uidvalue' #FIXED >

This has many important advantages - first the wellformed
XML does not have to be changed.  So any existing XML
can use this right out the gate by simply adding UID
attributes to the DTD/schema.

Second - lookup to the registry allows extensive retrieval
of metadata and semantics about foobar - as the business
needs determine - and the core component representation
within the registry provide.

It allows users to build sets of UIDs for industries that facilitate

Lets not get too hung up on language wars.  Notice that
at last count english is an amalgum of latin, celtic, norse,
anglosaxon, german, french, arabic, hindi, malay, chinese,
and a few more besides.   So instead of having one
word for things its has a helpful six or seven choices:

invoice, bill, ticket, charges, costings... depending if you
want latin, french, german or other root word set.

Convenient huh?


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC