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: 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'

    <Name>Mark Crawford</Name>
   <Name>Martin Bryan</Name>

and then notice:

   <AmountPaid curr="CENTS">2</AmountPaid>
   <BuyerPartyName>Mark Crawford</BuyerPartyName>

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'/>
<SellerParty UID='EBX001020'>
   <Name UID='EBX005070'>Martin Bryan</Name>
   <Address UID='EBX005080'>
      <County UID='EBX005085'>Gloucestershire</County>

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>

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

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.

[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