Re: [ubl] Namespace URI string implications

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

At 2006-06-06 18:15 +0200, roberto@javest.com wrote:
>I am sorry when I assert something or make a questions please understand I
>could miss something from past discussions, I am new to this.

No apology necessary!  Thank you for contributing to the discussion!

>I think the namespaceURI is the right way to identify a new version or a
>new information item, but about keeping the documentElement namespaceURI
>across UBL versions I get a little worried.

I understand your worry ... these are discussions of a foundational nature.

>The filter-before-validation is a good solution to let the previous scene
>work but I understand it works on new items only, what about overridden
>ones (changed version) ?

I need to understand what you mean by "overridden ones (changed 
version)".  I am anticipating a revision, say UBL 2.1, to add to the 
available children of a UBL 2.0 element, and those new children would 
be identified by the new namespace ... but the namespace URI string 
for the UBL 2.0 element doesn't change.  The filter-before-validation 
step would remove the new 2.1 children in an established system that 
is only validating against UBL 2.0.

Doing this means that an established UBL 2.0 deployment can still 
accept an instance with UBL 2.1 constructs inside without needing a 
single change to any line of running code or validating schemata 
because the filter-before-validation step means the class of 
instances it is processing and validating hasn't changed.  And 
because the changes are identified by namespace URI strings, even the 
filter logic doesn't change.  All established deployments are 
protected from any changes introduced by the central committee.  Only 
those deployments where the new constructs are significant need to be 
updated to accommodate the new constructs.  If we change the 
namespace URI on the entire document, then all systems would have to 
change (program code and validation) to accommodate instances with 
the new URI and the filter-before-validation isn't needed and doesn't 
provide any benefit.

Could you describe for me where you see an "overridden" information 
item to trigger a concern?

>I understand that an UBL cross-version compatibility could be nice the
>price should not be the complexity.

Agreed.  But there are those who claim that having to change their 
entire program to accommodate *all* of a document's information items 
with new URI strings is more complex, and they complain that to have 
to do this every time that UBL changes the namespace URI string for 
information that is not of interest to them would be a waste.

If filter-before-validation can be accepted as a practice, then I 
think the complexity is in understanding why we resorted to this 
practice, rather than how it is implemented.

>I remember UBL promise is to be a simpler, stronger solution than past B2B
>standards, I think complexity could exclude both little softwarehouses and
>customers.

I agree deployment complexity might scare away small programming 
shops and customers.  I've recently been told by a number of 
stakeholders in UBL and in the NES (a proposed UBL subset called the 
North European Subset) that where programmers need to interface with 
XML, there has to be a simple XSD interface that will allow them to 
work with XML without knowing XML.

The filter-before-validation achieves this by removing from the 
stream those new information items that would trigger problems in 
their interface that is geared to the old information items.

>I still think the best way is to give the instruments to easyly upgrade
>UBL versions (XSLT) and have a precise namespaceURI for each document.

Thank you for having considered and shared your opinion.  Your 
arguments have not alleviated concerns that I have about deployment 
where two parties have each implemented UBL, they have not 
established an explicit relationship between them, yet one wishes to 
send the other a UBL document for processing.

>When business partners agreements are configured with a precise UBL
>version why they have to change? They should upgrate both to a newer
>version I think.

While the scenario you describe here of business partners being in 
agreement supports the argument to have precise UBL versions for the 
entire document, this takes away the opportunity for blind 
interchange between two parties who do not have an agreement.

With filter-before-validation and persistent namespace URI strings 
for information items at a given version of UBL, and new namespace 
URI strings only for the new information items being added to UBL, 
then the two trading partners supporting different versions of UBL 
can still effect blind interchange because their respective 
implementations of filter-before-validation prepare the instances 
from the other party that each receive for the programs they have written.

>Thank you, it is just my opinion.

And I thank you for sharing it!  Your perspective has given me ideas 
about what to include in my paper to address the concerns that you 
have, that I am sure others would have as well.

I hope you have found the discussion worthwhile.

. . . . . . . . . . . . . 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