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] UBL 2.1 Invoice and Utility Statement

At 2013-06-19 10:17 +0000, =?iso-8859-2?Q?Matija_Tu=B9ek?= wrote:
I have successfully created UBL 2.1 Invoice and Utility Statement as supplement to that Invoice.

How can I extend UBL Invoice 2.1 with Utility Statement to have one master schema with Invoice and it's supplement? - - Do I need to fill parts in Utility Statement like Sender/Receiver/Copy Indicator/Issue Date/Customer etc - because I already have them in main Invoice? - - The main part that I need from Utility Statement is - Subscriber Consumption and I've mapped everything I needed.
The main idea is to send to our partner UBL 2.1 Invoice with Utility Statement supplement and attached invoice pdf.

I've appreciated this discussion and Matija's starting of it; thank you Matija.

At 2013-06-20 09:17 +0200, Roberto wrote:
you could embed just the details of the UtilityStatement inside an UBLExtension, anyway I would embed the whole UtilityStatement and fill it accordingly.

At 2013-06-20 15:54 +0800, Tim McGrath wrote:
yes, thanks for raising that. Ken suggested something similar to me. i suspect that for validation purposes this would work best.

At 2013-06-20 10:00 +0100, Stephen D Green wrote:
I don't think
there is anything technically wrong with combining two bits of the advice
from the others to your question and sending the UBL 2.1 Invoice with
just the subscriber consumption part of the utility statement inside a UBL
extension in the invoice.

I see there is wide agreement regarding using the UBL Extension point, and so I've been thinking about the schema ramifications of this. Using the extension point was the first thing to come to my mind because then the XML of the statement is addressable and not compressed and opaque inside of a base64-binary component.

This is how I see the issues for candidate users (and I hope others will look for faults in my reasoning):

- using UBL 2.0 we don't get any extension validation because of
  process="skip" in the extension content data type

- using UBL 2.1 we do get extension validation of those elements
  from the common library that are used because of process="lax"
  in the extension content data type

- we do not get extension validation of the "top level" of a UBL
  document that is under an extension because, say, the Invoice
  schema does not include a declaration for the UtilityStatement
  apex element, even though we do get validation of descendants
  of UtilityStatement found in the common library

Thus, the suggestions to put only subscriber details under the extension point are currently already supported in out-of-the-box UBL 2.1: simply create an apex element of your own design and constrain it to contain the Library ABIE (as an ASBIE) elements and BBIE elements from the UBL common library. I think everything will be validated (I'll test this later when I get more time; I wanted to comment while the discussion was ongoing).

So it works out-of-the-box for <cac:SubscriberConsumption>.

But what if one wants to embed a Document ABIE, say <UtilityStatement>, under the extension point? The children of <UtilityStatement> will individually be validated because the constraints are already loaded into memory from the common library. But as it stands as delivered without changes, <UtilityStatement> *itself* will not be validated, so its children may be out of order.

To address this, I think all the user needs to do is simply add to mod/common/UBL-ExtensionContentDataType-2.1.xsd an <xsd:import> pointing to the Utility Statement XSD, and then the presence of <UtilityStatement> gets validated itself.

It is expected that users will change mod/common/UBL-ExtensionContentDataType-2.1.xsd to accommodate user-defined extensions, so this is not a problem.

I'm not convinced this is a change we should do at the committee level: I don't think we import all 65 document schemas into the out-of-the-box extension module. That is a heavy processing penalty when very few communities need it. We'll just let communities do this if they need it, and it gets done in the one module that the community is allowed to change for itself.

I'll do a full suite of structured tests as soon as I get the time, and then I'll report my findings here. Please send me scenario suggestions either on-list or off-list.

Would readers of the list feel that a published Committee Note regarding this topic would be a useful resource?

Again, please let me know if you see any faults in my reasoning before I take the time for the tests.

Thank you, again, Matija!

. . . . . . . . . . Ken

Contact us for world-wide XML consulting and instructor-led training |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/u/ |
G. Ken Holman                   mailto:gkholman@CraneSoftwrights.com |
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |

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