RE: Core Component Analysis - SWIFT's Comments

[David RR Webber <Gnosis_@compuserve.com>]

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
(machine
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:

<foobar>
  <morefoobar>Stuff</morefoobar>
</foobar>

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

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?

DW.