Re: Re: OTA Tag name rules

[David RR Webber <Gnosis_@compuserve.com>]

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.