[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]