[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl] Extension Element Action item SV: [ubl] Minutes of Atla nticUBL TC call 5 April 2006
All,
How about two rules:
[CTDx] The xsd:any element MAY only be used within the 'UBLExtension' element definition, and with xsd:processContents set to 'skip'.
[ELD9] The 'UBLExtension' element MUST only be declared immediately following the 'UBLVersion' element within the document schema, with xsd:maxOccurs="1".
<Bryan>"The attributes I propose are..."</Bryan>
We currently do not allow attributes not defined by CCTS. Also, even those are only allowed on leaf nodes (BBIEs). I recommend capturing all this info in elements; let's try to minimize the 'damage'...
Also, maybe these should be captured within the 'custom' element that will be a child of the 'UBLExtension' element. After all, this is information about *that* element, and not the 'UBLExtension' element. What do you think?
Thanks,
Mike
-----Original Message-----
From: Bryan Rasmussen [mailto:BRS@itst.dk]
Sent: Tuesday, 25 April 2006 0714
To: ubl@lists.oasis-open.org
Subject: [ubl] Extension Element Action item SV: [ubl] Minutes of Atlantic UBL TC call 5 April 2006
Hi,
The following is what I figured could be the NDR text for xsd:any:
5.2.7 xsd:any Element
UBL allows the use of xsd:any under controlled circumstances, because this feature permits the introduction of potentially unknown elements into an XML instance the processContents attribute of the element must always be set to skip as this will remove possible errors in the validation layer. The xsd:any construct is seen as aiding the requirements of interoperability and as mainly be useful in cases where organizations that wish to use UBL are required by law to send additional information not covered by the UBL document structure, thus extending the UBL message. Since it is a priority that there can be meaningful validation of the UBL document instances xsd:any must be used sparingly, and only within UBL defined elements meant for containing non-UBL elements that can be understood to extend UBL. Any use of xsd:any must also only allow no more than one element in the non-UBL namespace, this is to ease serialization of the extending element as its own XML instance that can then
be validated, if an implementer wishes to do so, outside the UBL validation process.
[ELD9] The xsd:any element can be used, with processContents set to 'skip'
and minOccurs=1, maxOccurs=1.
-----------------------------------------------------------------------------
-----------------------------------------
The following is a very rough suggestion for how the element should actually look but Peter and I think it's a reasonable starting point to open up for discussion, it's taken from my original suggestions for how an Extension element should look, I suppose the name will be ExtensionPoint instead of
ExtensibleContent:
An ExtensibleContent area is an element in the understood format document that contains another format not related to the overall document format.
The contents of the ExtensibleContent area can be further specified by those doing the extending via attributes on the element itself.
The attributes I propose are
ExtensionID - same semantics as schemeID
extensionAgencyID - same semantics as schemeAgencyID for Extensions
extensionAgencySchemeID - same semantics as schemeAgencySchemeID
extensionAgencySchemeAgencyID - same semantics as schemeAgencySchemeAgencyID
extensionReason - a codelist, I can think of
a. Legal - the extension contains information required by in an area
covering the extending body for documents of the type being sent.
b. ReceiverRequested - the extension contains information that the
receiver has requested be provided.
c. ProvisionalTest - the extension is currently passing information that
is being considered for inclusion into the next version of UBL, this would presume some sort of public repository of currently considered extensions.
The sender is testing how the extension works in their system with trading partners. I'm not very wedded to this particular reason, as I'm not sure if it is something I would describe as a 'reason'.
d. Application - the extension is a vendor specific extension
mustUnderstand - a Boolean, only allowed in contexts of the extensionReason being legal, the sending party is claiming that in order for their document to be received validly the receiving party must understand it. I realize of course that this raises the spectre of balkanization again, but it seems to me that this would only be used when actually required by law, given that who in their right mind would send a document and require someone to understand it if it meant that by not understanding the receiving party could refuse it.
extensionAgencyControllerID - in the context of the Danish UBL project the Danish Government ministry in charge of the technical wing of the project would be the Controller for any official extensions.
extensionAgencyURI - a dereferenceable uri where information about the extension can be found.
extensionDomain - the problem domain that the extender considers the extension to cover.
Some evident domains -
a. Presentation, handled via SVG, XHTML?
b. Calculation, handled via MathML?
Of course these are more evidently application extensions than semantics extensions.
ExtensionDomainSchemeURI: a dereferenceable uri that will define the domain.
-----------------------------------------------------------------------------
---------------------------------------------
Do these seem like reasonable attributes of such an area?
Cheers,
Bryan Rasmussen
-----Oprindelig meddelelse-----
Fra: Bryan Rasmussen
Sendt: 20. april 2006 12:46
Til: 'Grimley Michael J NPRI'
Cc: 'jon.bosak@sun.com'
Emne: SV: [ubl] Extension Element Action item SV: [ubl] Minutes of Atlantic UBL TC call 5 April 2006
Hi Mike,
Here is my stab at what the NDR should say for allowing xsd:any:
5.2.7 XSD:Any Element
UBL allows the use of xsd:any under controlled circumstances, because this
feature permits the introduction of
potentially unknown elements into an XML instance the processContents
attribute of the element must always be set to skip as this will remove
possible errors in the validation layer. The xsd:any construct is
seen as aiding the requirements of interoperability and as mainly be useful
in cases where organizations that wish to use UBL are required by law to send
additional information not covered by the UBL document structure, thus
extending the UBL message. Since it is a priority that there can be
meaningful validation of the UBL
document instances xsd:any must be used sparingly, and only within UBL
defined elements meant for containing non-UBL elements that can be understood
to extend UBL. Any use of xsd:any must also only allow no more than one
element in the non-UBL namespace, this is to ease serialization of the
extending element as its own XML instance that can then be validated, if an
implementer wishes to do so, outside the UBL validation process.
[ELD9] The xsd:any element can be used, with processContents set to 'skip'
and minOccurs=1, maxOccurs=1.
I've cc'ed Jon but haven't posted to the list yet.
Seem reasonable for the NDR requirements?
Cheers,
Bryan Rasmussen
-----Oprindelig meddelelse-----
Fra: Bryan Rasmussen [mailto:BRS@itst.dk]
Sendt: 19. april 2006 12:46
Til: jon.bosak@sun.com; ubl@lists.oasis-open.org
Emne: [ubl] Extension Element Action item SV: [ubl] Minutes of Atlantic
UBL TC call 5 April 2006
> 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.)
Due to various issues around vacations and work schedules Peter and I haven't
had an opportunity to talk together.
It was my understanding that this Action Item was actually to be split into
two, that is to say how should xsd:any be allowed in the Naming and Design
Rules (which was the part that Mike Grimley volunteered to read over), and an
item on how the element should look. Is this correct?
I had planned on doing the NDR item over my vacation, but as it was a
capoiera workshop where I ended up training 7+ hrs per day and dancing all
night as part of the workshop's social obligations I ended up only being able
to do about 3 hours of the work I'd intended to do over my vacation, and none
of that was on the NDR (yet strangely, I am quite happy ). However I figure I
can have the NDR part of the item later on this week, if that is in fact
still part of the action item.
Sorry for the inconvenience,
Bryan Rasmussen
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]