[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 (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.
Powered by eList eXpress LLC