Re: [ubl-dev] ExtensibleContent

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

At 2007-10-31 19:39 +0100, Kristian Berge Nessa wrote:
>It seems like the UBLExtensions structure fit our needs perfectly, even more
>so than the original ExtensibleContent, as we will most probably need to:
>(1) receive, store and pass on any <UBLExtension> elements provided by the
>client, and
>(2) add our own <UBLExtension> content as the document progresses through
>various processes.

Very interesting!  Yes, and I would use different meta data and a 
different apex namespace to distinguish those extension elements that 
are interchanged from those extension elements that are internally 
generated as a result of process.

> >   (1) - an extension item of a global nature relative to the entire
> > document and standardized information stands alone under the extension
> > point
> >
> >   (2a) - the item stands alone under the extension point and references
> >          the line entry through some mechanism of document referencing
> >          - possibly ID/IDREF
> >          - possibly contextual ancestry (suitable for XPath processing)
> >        - pro: no duplication of information
> >        - con: referencing/de-referencing needs extra work
>
>For our use, a combination of (1) and (2a) sounds just right.

Consider how one might extend an invoice line item with more information:

Looking closer at (2a - i), the ID/IDREF-like approach, you would 
place an ID element on the line item, and then reference that from 
the extension by using the identifier.  UBL, however, has the problem 
that elements don't have an ID-type attribute, and the naming and 
design rules don't provide for creating an element with an IDREF-type 
attribute ... so you would just be mimicking ID/IDREF through 
elements ... which isn't really a problem.

So, using elements the scenario would be as follows:

   - the line item would look like:

   <cac:InvoiceLine><cac:OrderLineReference><cbc:LineID>ABC123</cbc:LineID>...

   - the extension would look like:

   <ext:LineItemInformationExtension>
      <ext:LineReferenceID>ABC123</cbc:LineReferenceID>
      <this>
        <stuff>
          <here/>
        </stuff>
      </this>
   </LineItemInformationExtension>

   - the XPath to reach, say, the cac:OrderLineReference child of the 
cac:InvoiceLine element would read:

   <xsl:key name="LineIDs" match="cbc:LineID" use="."/>
   ...
   <xsl:variable name="line" select="key('LineIDs',ext:LineReferenceID)/.."/>

One comment I've heard about this approach is that mimicking ID/IDREF 
may be inappropriate because of the semantics of the ID element 
defined by UBL.  The argument went along the lines that it was that 
an identifier being used in UBL to identify a line item for the 
business purpose of a unique reference, that shouldn't simultaneously 
be used for a document purpose of the mechanics of processing, 
because that's not the semantic for which it was defined.

I disagree, as I believe that for whatever reason I put an ID element 
on a portion of the document, regardless of the background semantic, 
that I should be able to reference it for mechanical or for business purposes.

But, thinking about your "supplemental information added by 
processes" scenario, I can see a problem with this approach:  what if 
the incoming instance doesn't have a <cbc:ID> on the line item, and 
you need to reference the line item in your supplemental 
information?  I think you would treat the incoming UBL bits as 
sacrosanct, and you wouldn't touch those, so you then miss out on the 
opportunity to reference the line.

So, looking closer at contextual ancestry, this approach allows you 
to reference information in the UBL bits without having to add 
anything to the UBL bits.

Consider this invoice that arrives without any <cbc:LineID> elements:

   <in:Invoice>
     <cac:InvoiceLine><cac:OrderLineReference>...
                      <cac:OrderLineReference>...
                      <cac:OrderLineReference>...
     <cac:InvoiceLine><cac:OrderLineReference>...
                      <cac:OrderLineReference>...
                      <cac:OrderLineReference>...this one needs extension...
                      <cac:OrderLineReference>...
                      <cac:OrderLineReference>...
     <cac:InvoiceLine><cac:OrderLineReference>...
                      <cac:OrderLineReference>...
   </in:Invoice>

An extension could reference a particular order line reference as follows:

   <ext:OrderLineReferenceExtension>
      <ext:InvoiceLineNumber>2</ext:InvoiceLineNumber>
      <ext:OrderLineReference>3</ext:OrderLineReference>
      <this>
        <stuff>
          <here/>
        </stuff>
      </this>
   </ext:OrderLineReferenceExtension>

Then in XPath you could have something along the lines of:

    <xsl:variable name="lineNum" select="ext:InvoiceLineNumber"/>
    <xsl:variable name="refNum" select="ext:OrderLineReference"/>
    <xsl:variable name="line" select="/in:Invoice/
                                       cac:InvoiceLine[$lineNum]/
                                       cac:OrderLineRef[$refNum]"/>

It looks a bit awkward, but it is unambiguous and it doesn't have to 
touch the UBL parts by adding anything.  And though I've given the 
XPath, I would think that this approach would be very simple for a 
programmer to understand and implement.

> > I hope this is considered helpful.  I hope that others will chime in
> > with their own ideas on this issue.
>
>Helpful indeed!
>Thank you very much for a swift and Extensive (pun intended...) reply.

Ha!  Very droll!  :{)}

BTW, all of this is only my personal opinion and does not reflect any 
kind of consensus on the part of the UBL Technical Committee.

These and the alternative techniques are just the ways I've been 
looking at these things based on my own approach and what I've heard 
from others.

I hope that others with opinions or suggestions will chime in to this 
discussion ... then I'll get to learn more about this too!

Thank you for taking the time to bring this to the list today.

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


--
Comprehensive in-depth XSLT2/XSL-FO1.1 classes: Austin TX,Jan-2008
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds:     publicly-available developer resources and 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 Jul'07  http://www.CraneSoftwrights.com/u/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal