[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: UID: RE: Long Tags Codes etc. again
The problem is that BOTH are correct - Martin and Mark, and this is all about CONTEXT. Notice: SAMPLE 'A' <BuyerParty> <Name>Mark Crawford</Name> <Address/> </BuyerParty> <SellerParty> <Name>Martin Bryan</Name> <Address> <County>Gloucestershire</County> </Address> </SellerParty> and then notice: <PaymentReceipt> <AmountPaid curr="CENTS">2</AmountPaid> <BuyerPartyName>Mark Crawford</BuyerPartyName> <BuyerReference>0023553</BuyerReference> </PaymentReceipt> But further notice that none of this is going to ever work - when you use names to denote things - then machine processing and machine interpretable logic flies out the window and is gone. And then the French want different tags names anyway. At the risk of being a broken record on this UID's, UID's and UID's. Use them, embed them, put them in the Registry, build schema fragments around them, think UID's, assemble UID based DTD and Schema fragments, use UID's to denote context, in fact put UID's everywhere - nouns, verb, templates, forms, programs, stylesheets, classifications, business processes, CPP's.... Here's what this then brings to the table: Notice: SAMPLE 'B' <BuyerParty UID='EBX001010'> <Name UID='EBX005070'>Mark Crawford</Name> <Address UID='EBX005080'/> </BuyerParty> <SellerParty UID='EBX001020'> <Name UID='EBX005070'>Martin Bryan</Name> <Address UID='EBX005080'> <County UID='EBX005085'>Gloucestershire</County> </Address> </SellerParty> and then notice: <PaymentReceipt UID='EBX002010'> <AmountPaid curr="CENTS" UID='EBX002011'>2</AmountPaid> <BuyerPartyName UID='EBX001010:V011'>Mark Crawford</BuyerPartyName> <BuyerReference UID='EBX001080'/>0023553</BuyerReference> </PaymentReceipt> Notice that ALL these UID references go in the DTD or Schema; NOT in the well-formed XML - so this document actually looks like A, but derives as B, when the parser reads both the wellformed instance and the ebXML compliant DTD or Schema into memory. Now you know that BuyerPartyName is a sub-version of the component BuyerParty, and when you look it up in the Registry - you discover an associative link to EBX005070, the Name component. I've been telling the W3C for two years that Schema cannot do this, and that Registry is the way to store and reference extended semantics. Fortunately James Clark and James Tauber understand this, and now we have the TREX work - which cleanly separates structure from all the other mess. As part of the work XMLGlobal is doing with NIST we are now demonstrating this kind of use of Registry interactions and storing Component definitions - using the ebXML Registry API and IE5.0 to show how this plays out. I look forward to being able to demonstrate this to interested parties in Vienna - and also to sharing lessons learned on actually storing and retrieving XML representations of Core Components to/from the Registry. Thanks, DW.
Powered by eList eXpress LLC