Extension element children (was: [ubl] Minutes of Atlantic UBL TC call 5 April 2006)

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2006-04-10 13:33 -0700, jon.bosak@sun.com wrote:
>MINUTES OF ATLANTIC UBL TC MEETING
>15:00 - 17:00 UTC WEDNESDAY 5 APRIL 2006
>...
>NDR WORK SESSION
>
>    Extension proposal:
>
>       http://lists.oasis-open.org/archives/ubl/200604/msg00013.html
>
>    MG: No objection.
>
>    MC: Comfortable with this because the extensions live in their
>    own namespace.
>
>    TC: In MDDL, people do want to use the original elements [in
>    extensions] to make it clear where they are doing the same
>    thing.  We originally prohibited this and then recanted.  The
>    extensions are wrapped in a special element...
>
>    JB/BR: This is what's being suggested for UBL.
>
>    TC: We should allow the UBL children directly in the special
>    element; it's the element that tells you that you have the
>    extension.
>
>    All: We're not sure why GKH wanted a non-UBL layer between the
>    extension element and the UBL children.

For ease of validation and for explicitly wrapping labels of UBL 
semantics in a foreign label, such that the foreign label dictates 
the context of the UBL information item based on the semantics of 
that foreign label.

>    JB: In mail off the list, he said:
>
>       What this means is that we can, in XSD, express "child
>       elements in any non-UBL namespace" and have it throw an
>       error if one of those children is in UBL.  Note that
>       descendants below children may be in the UBL namespace
>       ... this will allow an extension writer to take advantage of
>       UBL, but still require them to wrap their extension use of
>       UBL in one of their extension elements.  I'm hoping I'll be
>       able to "say" this in NVDL.
>
>    All: We could use more discussion on this point in email.

For validation consider that the UBL schema can express that content 
be entirely in a foreign namespace or in no namespace:

   <xs:complexType name="any-non-UBL">
     <xs:choice minOccurs="0" maxOccurs="unbounded">
       <xs:any namespace="##other" processContents="skip"/>
       <xs:any namespace="##local" processContents="skip"/>
     </xs:choice>
   </xs:complexType>

For the ephemeral issue of semantics, information items with UBL 
labels in a UBL document have a context and our documentation 
dictates the semantics of the information wrapped with UBL labels in 
a UBL context.  Yes, we could (I think we would have to) state that 
UBL labels as direct children of the UBL extension element do not 
represent the information as having the semantics as documented for 
those labels.  But I believe one cannot say categorically what 
semantics the UBL labels do represent when they are used as direct 
children of the UBL extension.  The designer of an extension 
vocabulary can, however, document the semantics represented by the 
use of a UBL label within an extension vocabulary label they divine.

What if two different extenders of UBL both happen to choose the same 
UBL construct to use as a direct child of the UBL extension 
element?  Which of the two semantics is this use supposed to represent?

In fact the same question comes up if no namespace is used for the 
child of the extension element, but that is just a matter of 
ambiguity of not being sufficiently unique in non-UBL labels, not the 
issue of what do the already-documented UBL labels mean when found in 
the extension element.

However if extenders of UBL were obliged to use labels with 
namespaces as direct children of the UBL extension element, then a 
recipient of a UBL document has explicit context for the use of UBL 
labels within the UBL extension element, and can then track down the 
documentation for the use of said foreign labels, and then implement 
the semantics as they see fit for the information found in the extension.

Oh, finally, in support of NVDL that will siphon off different 
subtrees of an instance to different validation tasks based on the 
namespace of the element, we would not be able to use NVDL for the 
automated validation of the subtrees if the subtree began with a UBL 
element at the apex.

There is a precedent for this ... this came up in the design of 
XSL-FO, and the internal XSL-FO extension element requires the child 
to be in a namespace (not in no namespace) and that namespace cannot 
be the XSL-FO namespace.

>    AGREED that the document extension area should go at a high
>    level, but last in the schema.
>
>    ACTION: PB and BR to submit a more detailed proposal along
>    these lines, possibly contacting MG offline; for submission
>    week after next at the latest.  (Next week is the Easter
>    holiday in Europe.)
>
>    MG: What of GKH's thought about extending Party?
>
>    BR: In dk practice it turned out that people just wanted to
>    extend the document.
>
>    AGREED that we will just specify extension at the document
>    level in the 2.0 cycle and then take up the question of
>    extending other pieces in future versions.

I'll accept that, though in my own experiments of implementing 
Crane's invoices using UBL invoice, I readily took advantage of 
extensions at the line and party level.  I can see, however, how I 
will aggregate all that information into a single document-level 
extension, so I'm prepared to concede on this.

I hope this helps.

. . . . . . . . . . . . . Ken

--
Registration open for XSLT/XSL-FO training: Wash.,DC 2006-06-12/16
Also for XML/XSLT/XSL-FO training:Birmingham,England 2006-05-22/25
Also for XSLT/XSL-FO training:    Copenhagen,Denmark 2006-05-08/11
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal