RE: RE: Long Tags Codes etc. again

["Probert, Sue" <Sue.Probert@commerceone.com>]

Thanks David.

You put together exactly the same reply as I was about to try to pen. I
absolutely agree that the UID is the key whether directly or indirectly
referenced in whatever way suits individual syntax or business solutions.
Isn't that the whole point of the CC exercise - individually well defined
and labelled semantics?

regards

Sue

Sue Probert
Director, Document Engineering
Commerce One
Tel: +44 1332 342080
www.commerceone.com


-----Original Message-----
From: David RR Webber [mailto:Gnosis_@compuserve.com]
Sent: 17 April 2001 21:04
To: CRAWFORD, Mark
Cc: 'ebXML Core' (E-mail)
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.

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org