OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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?


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.


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]