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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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


Subject: Re: [ubl-dev] Using Extensions on V2pr2


At 2006-09-01 17:51 +0100, Loureiro, Gil wrote:
>I'm evaluating the creation/use of an extension.

Excellent ... we need to see how palatable this is to implementers.

>But I've some doubts how to do it, do some one 
>have already used it, that can help? (maybe an example?

Have you reviewed the documentation I prepared 
for the NDR committee?  It is found at:

   http://lists.oasis-open.org/archives/ubl/200607/msg00099.html

Extension meta data is not required, but it is 
there to help recipients understand the source of the extension.

The <ext:ExtensionContent> element has *one* 
child element, recommended not to be in any UBL 
namespace so it should be a foreign namespace of 
your own choosing, and that one element can have 
any number of children or descendants you wish.

The design of the extension element allows for 
the child of <ext:ExtensionContent> to be deleted 
as part of a pipelined process of massaging UBL 
instances, thus a process can remove unwanted 
extension content while retaining the meta data 
for that unwanted extension.  This will 
streamline validation and downstream processing.

The location of the extension element is at the 
very start of all UBL instances so that a 
processing application implementing a serial 
interface for XML (such as SAX - Simple API for 
XML) can detect the presence of all extensions 
before encountering any standardized content.  Of 
course this is not an issue for tree-based interfaces such as XSLT.

Correlating extension content with standardized 
content may be a challenge for some, and I 
anticipate different techniques will come to 
light.  I envision possibly correlating the 
ordinal position of standardized components with 
an identical number of extension components (thus 
requiring empty extension components when no 
extension applies to a standardized 
component).  Alternatively, one might implement 
XML concepts of ID/IDREF and put an ID on the 
standardized component and an IDREF on the extension component.

Due to the time pressures in finalizing and 
releasing UBL 2.0 I have not had the time to 
prepare running examples of UBL extensions, but I 
am endeavouring to have this in time for our next 
delivery of our hands-on UBL training class in 
Denmark October 3, 2006 (please see our home page for details).

As of the end of September I plan on our company 
issuing all invoices in XML using UBL 2.0 with 
Crane's custom extensions documented on our web 
site, and we will be able to print PDF copies of 
our UBL 2.0 invoices for those customers of ours that do not understand UBL.

I hope this helps for now ... I would be 
interested to hear if anyone else has attempted 
to implement the new extensions element.

. . . . . . . . Ken

--
UBL/XML/XSLT/XSL-FO training: Vårø, Denmark 2006-10-02/06,11-20/24
UBL International 2006  2006-11-13/17 http://www.ublconference.com
World-wide corporate, govt. & user group UBL, XSL, & XML training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/u/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal



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