Re: Re: OTA Tag name rules

[Bruce Peat <BPeat@eProcessSolutions.com>]

Slow...   slow.... slow....   ...      s...l...o....w....    .....s
....l......

the version needs to be carried within the message for speed, and
classification (and other indirection) derived from this information as a
lookup reference for both "nouns" and "verbs" or "objects" at a logical unit
level.   I want 80% of processing to take this direct route, and the other
20% of the time take the indirect route for discovery, interpretation, etc.
I would like to see GUIDs be unique to the version and be able to invoke the
mechanism which you speak from this when required.

Of course one alternative is roll the entire transaction, and we might as
well start digging our grave.

- Bruce



----- Original Message -----
From: "David RR Webber" <Gnosis_@compuserve.com>
To: "Bruce Peat" <BPeat@eProcessSolutions.com>
Cc: "Christopher Ferris" <chris.ferris@east.sun.com>;
<ebxml-architecture@lists.ebxml.org>
Sent: Saturday, September 30, 2000 12:27 PM
Subject: Re: Re: OTA Tag name rules


Message text written by Bruce Peat
>
I believe the version doesn't get placed on 1.0 version of anything.
Version only counts when you have two of something.

- Bruce

<<<<<<<<<<<<<

Correct of course - but notice that historically changes that are
backward compatible are not an issue - and EDI practice
has been if the changes are not backward compatible - then
create a sub-definition or related new item with a new
reference type.

Here's the rub - we need to strive to keep the
XML document INSTANCE - the payload - clean and simple
so that interoperabilty is maximized.

That is why I see version in the tag itself as unacceptable
overhead and compication.

Instead we use the Schema / DTD mechanisms underneath to
relay the semantic information - specifically by linking each
metadata semantic unit to the Registry via a GUID reference.

That is one and only one reference mechanism - and one
that does the complete functional job.

Looking at a fragment from the GCI example for the Tokyo PoC :

[snip]
<element name = "AdvancedShipNotice">
 <complexType content = "elementOnly">
    <sequence>
        <element ref = "DocumentLevel"/>
        <element ref = "Party"/>
        <element ref = "Product"/>
[/snip]

then becomes :

[snip]
<element name = "AdvancedShipNotice" GUID="GCI01020">
 <complexType content = "elementOnly">
    <sequence>
        <element ref = "DocumentLevel"  GUID="GCI01025"/>
        <element ref = "Party"                       GUID="GCI01026"/>
        <element ref = "Product"                  GUID="GCI01030"/>
[/snip]

Notice of course that inside the Schema/DTD the associated
attributes are still 'there' but with a #FIXED '{value}'  construct
so they never clutter up the payload itself.

Once you have the GUID reference - then you can use the
Registry itself to control the draft/candidate/approved/deprecated
and similar and this is a much cleaner model as maintenance
is under open control at a single point - not hard wired and
dispersed (the fundamental flaw in W3C schema as is).

Much more important is the approach - too much of EDI tries
to dictate the SENDERS model on the receiver(s).   The
semantic context should be resolved AT POINT OF USE.

I pass you the GUID - if your system requires version 1.2.7
(deprecated) then your software should handle that.
Similarly, from your TP profile - you can publish a Payload
structure (schema or DTD) that conforms to that - with the
GUID reference handling this. (The GUIDE document
shows how extensions and permitations can be handle
by the GUID - example:  GUID="GCI03041:X12-edi"

retrieves the X12-edi extension of the base GUID
reference to a GCI03041 semantic reference into the
Registry.

One task in Tokyo is to exactly refine and document
the full set of behaviours and mechanism for GUID
so that all these aspects are documented.  The TA
document - in a technical addendum - is the place
I anticipate this needs to be included.

DW.