Re: [ubl] Namespace URI string implications

[roberto@javest.com]

Hello,
please to meet you,
my name is Roberto Cisternino (ITLSC chair).
I woult like to give my opinion about this matter.

One of the main reasons UBL is better than past EDI formats is the
validation which is made possible using a precise WXS Schema based on
unique namespaces aware of UBL versions.

e.g. urn:oasis:names:specification:ubl:schema:xsd:Invoice-1.0

I think an UBL document "instance" should be based on a precise namespace
URI, then inside the schema there could be a sofisticated re-use of
components by choosing from 1 or more component collections still
versioned and identified by a precise namespaceURI.

In a different way I think it could be hard or impossible to make generic
software able to deal with different UBL versions and to transform them
successfully in case of a technology update.

Maybe there could be a sort of deprecation system, this way an UBL 2.0
interface could be able to read UBL 1.0 automatically by following
deprecation instructions... just an idea (could be heavy)

We had versions using EDIFact or X12 but the translation between versions
was hard as documents were often invalid.

Now I think the real problem to be solved is to find a way to keep
corporates updates with latest UBL versions with a minimal effort.

XSLT transformation is a possibility, but maybe a free UBL update service
(web service) could be a "must".

Sincerely

ITLSC
Chair
Roberto Cisternino



> Further to tonight's teleconference, I brought up a concern of a
> decision Paul Thorpe and I heard in Brussels that we didn't realize
> was in the works and that has critical deployment ramifications that
> I feel the committee should discuss.
>
> But I gather from Jon's comments in the call, this is a
> long-hashed-out issue and I run the risk of angering a number of
> members by bringing this up.  But I don't believe I had been party to
> the discussion earlier as this was a surprise to me, so belatedly
> I'll bring up the issue that Paul raised and an issue that I've
> determined from documenting my proposed subsetting and extension
> methodologies.
>
> I don't want to put words into Paul's mouth, so I'll invite him to
> comment himself, but I guess that perhaps this hadn't been widely
> known since it was news to him as well.
>
> Paul and I believe that *any* change to the document models
> *requires* the namespace URI string to be different ... even for
> minor changes because a 2.1 document model will have more information
> items than a 2.0 instance ... keeping the namespace URI strings the
> same and embedding version information will have major deployment
> problems with respect to validation.
>
> We cannot have the same namespace string identifying the vocabularies
> for UBL 2.0 and a modified UBL 2.1 for the following reasons
> (probably among others but these are show-stoppers), based on the
> premise that W3C validation associates the namespace URI string to
> the structures of the document through the targetNamespace= property
> in the document element of the schema ... thus, there is a strict
> association between what the string says and the document model,
> producing the following issues:
>
> (1) Deployment of a heterogeneous system
>   - there is no way we can shut down global UBL usage of a 2.0,
> deploy 2.1, and start the world up again
>   - a system that has upgraded to 2.1 will forward what they consider
> to be a UBL valid instance, since it validates in their system
> against the published 2.1 schemas, to a 2.0 system, and the 2.0
> system will reject it for non-compliance to the UBL schemas they are
> using that are
>   - I'm told there is a parallel with ASN.1 ... Paul has customers
> with networks of thousands of users of heterogeneous implementations
> of the ASN.1 equivalent of a document model and they must be uniquely
> identified for the high-speed algorithms in the interface chips to
> accurately accept and reject properly-formed ASN.1 messages
>
> (2) The front-line interface to many programs is validation
>   - one comment in Brussels was that the version information is to be
> found inside the instance
>   - there are program interfaces to XML that "pre-compile" the W3C
> Schema expression into artefacts such as Java classes and C# data
> structures
>   - I understand such interfaces are keyed on the namespace URI
> strings based on the targetNamespace= property ... perhaps someone
> can tell me otherwise, but if I compile a cac:Party into a C# data
> structure and the data stream arrives with a matching target
> namespace but more information items that my data structures can
> support, can someone tell me what the program does with the extra
> information items?
>   - the premise of blind XML document interchange is that the
> receiver validates what the sender sends so that the receiver's
> program knows what the sender is sending is acceptable ... if we
> expect programs to go into an XML document and examine the version
> information item, an instance won't even get past the gatekeeper of
> W3C Schema Validation if a 2.1 instance is sent to a 2.0
> implementation because the 2.1 namespace is interpreted as having the
> 2.0 document model and the presence of the 2.1 information items
> kills the data flow before the program even sees the instance
>
> A possible mitigation as I write this is to use a 2.1 namespace URI
> string but us it *only on the elements that are new to version 2.1*
> and not on the document element.  But this will mean we must
> introduce a namespace-based exorcism step in the deployment of UBL
> applications where a "filter" step that is engaged after receipt of a
> message will preserve information items in the UBL namespaces that
> are supported by a given deployment, and elide the information items
> that are not supported.  Then, schema validation will proceed without
> "tripping" over the information items that are not expected, and it
> will be able to find the version information in the structure because
> the filtered structure will have passed validation.
>
> But it means that we still need to introduce new namespace URI
> strings in order to distinguish the new information items of 2.1 from
> the old information items of 2.0.
>
> Paul and I heard of the decision and when we tried to bring it up on
> the Friday there was insufficient time to talk about it before I and
> others had to leave for the airport.
>
> If UBL members still believe that we can have one namespace URI
> string for two different document structure declarations, could you
> please help us understand how the two issues above are addressed.
>
> Paul, could you please add your own spin on this?
>
> I've written this very quickly in order to get the debate started ...
> I apologize if I've missed something obvious.  On the call it seemed
> important that this be discussed quickly.
>
> Thanks!
>
> . . . . . . . . . . . . Ken
>
> --
> Registration open for XSLT/XSL-FO training: Wash.,DC 2006-06-12/16
> Also for XSL-FO/XSLT/XML training:    Birmingham, UK 2006-07-04/13
> Also for XSL-FO/XSLT training:    Minneapolis, MN 2006-07-31/08-04
> Also for XML/XSLT/XSL-FO/UBL training: Varo,Denmark 06-09-25/10-06
> World-wide corporate, govt. & user group UBL, XSL, & XML 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
>
>
> ---------------------------------------------------------------------
> 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
>


Roberto Cisternino