MHonArc v2.5.0b2 -->
ubl message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ubl] Namespace URI string implications
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]