Re: [ubl-ndrsc] Re: [ubl-lcsc] [ubl-ndrsc][ubl-lcsc] Versioning,Extension and Header Containers

[Tim McGrath <tmcgrath@portcomm.com.au>]

It is on the agenda for the LC call.

As I wan't be able to call in, I willl give my opinion  in this email..

          if i understand what arofan is saying, he is re-stating the fact
that XSD extension only allows new elements to be added at the end of a 'type'.
  
 
 It makes little difference if  this is caused by customised extension or 
minor release, does it?
 
 this is not inconsistency, it is pointing out that ALL our structures are
affected by the limitations of XSD extension.
 
 surely, the idea of creating 'header's will not solve this? the extended 
elements appear may still be 'prohibitively ugly' (and i am not sure what
that really means for machine processible documents).  for example, our current 
Order document has an OrderType that contains 20 simple elements and 13 complexTypes. 
 What arofan is saying (i think) is that if I wanted to extend any of the
13 complexTypes, then the new elements would appear at the end of the complexType
itself.  If I wanted to add a 21st simple element, then  it appears after
the 13th complexType.  is that a technical problem or just aesthetics?  what
are the down sides to having extended elements at the end?  do we need to
fix this?
 
if it is a problem , then i am not sure such a simplistic approach is going
to fix it.  in fact, i suspect the solution is a refinement of the list-containership
question and i think the same concerns apply.  for example: 
* yes, many PO documents do have an apparent structure that looks like Hd1, Hd2, Hd3, Hd4, Item+. 
* yes, that could be described by HdType, Item+. 
- so we have a prettier(?) extension for PO Documents. but  how do we achieve
this for :
* Waybills (with Hd1, Hd2, Item1+,Hd3, Hd4, Item2+), 
* Container Release documents (just Item+ - with no Hd at all) or 
* Arrival Notices (just Hd with no Item+) as does our humble Order Response
(simple) 

the next complexity in this proposal is that Item+ is not the only repeating
set of elements in our document type definitions.  we cannot base our rules
on ambiguous identification of what should or should not be in 'header's.
 
One of the objectives here is to formalise the way we structure ABIEs and 
our documents.  We have not come up with a reliable way of describing this 
'header' concept (possibly because it is not a consistent pattern).  one
day, if we come up with a workable container -list concept then this isue
will fall out of that.

Meanwhile, such a crude concept would confirm to our critics that UBL is
just a procurement/purchase order system.
 
Until we get practical answers to these issues we should move on from this
and get 1.0 out of the way.


jon.bosak@sun.com wrote:
> | Unless we have Header containers of some sort, we will have to add any
> | additional elements to header containers at the end of the document in
> | subsequent minor versions.  A similar phenomenon applies to extension -
> | if anyone wants to extend our set of "header" elements, the additions
> | will go after the body items.
>
> This looks like a pretty big problem.  Is it on the agenda for
> discussion this week?
>
> Jon
>
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl-ndrsc/members/leave_workgroup.php.

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160