MHonArc v2.5.0b2 -->
ubl message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Extension element children (was: [ubl] Minutes of Atlantic UBL TC call 5 April 2006)
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]