[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] Re: [ubl] Minutes of Atlantic UBL TC call 13 May 2009
Well, if it were merely a matter of the technical issues (politics aside) it would seem to be a really bad idea to store the version information in then namespace: In my opinion (and others' I think) this is because the namespace is very hard to change (and as Ken points out very course grained). All the more so when the version will need maximum flexibility as it does (I think) with the codes like currency code. If I understand your view, Mark, it is that a version change for the currency code, etc should have to wait for a version change of UBL. Now, if we add to that the need for being able to handle both versions in the same UBL version, it would mean improving on the schema design built into the UBL 2.0 NDR which mixes some of the CEFACT features with non-CEFACT (non-ATG2) features. But following what I think you are saying, Mark, about trying to merge the two schema designs by UBL following more the ATG2 design then it would lead to a need for not only the currency codes version introduction waiting for the UBL version change but on top of that the UBL version change waiting for ATG2 to meet the said requirements with an improvement in the ATG2 design (to allow multiple versions of codelists to be used with the same set of schemas - the same set of schemas to be able to support multiple versions of the same codelists for currency code, etc). Plus there is no hint that ATG2 would even go that way. This would be dire for those countries waiting to use their new currency codes alongside the existing ones without having to keep on supporting two sets of schema versions in order to do so. What do they get in return? Or is that just getting into the political issues? Best Steve 2009/5/20 Crawford, Mark <mark.crawford@sap.com>: > Stephen, > > First - the idea of using the namespaces for the supplementary components was not Gunthers. Second, UBL is of course free to plot its own course to deviate from the solution of UN/CEFACT. It is however dissapointing in that the editors of the UBL NDR worked closely with UN/CEFACT on version 3, never raised any objection to this aspect, and agreed to adopt it for UBL going forward. As for real world requirements, we will have to agree to disagree. Given the broad scope of the participants in the UN/CEFACT NDR - in terms of numbers of standards bodies, global software companies, and others - it is rather difficult to believe that they don't also represent real world requirements. Rather than have the much larger community change, I would suggest that it is UBL that should align to the UN/CEFACT solution as they continually assert that they are willing to do so. If not, that is fine. However UBL should be forthright in stating that it has no intention of finishing the alignment process, and should ensure that its potential users understand that with UBL they are getting a solution that is only partially aligned to the UN/CEFACT common methodologies. > > Kind Regards, > > Mark > > > > -----Original Message----- > From: Stephen Green [mailto:stephengreenubl@gmail.com] > Sent: Monday, May 18, 2009 9:54 PM > To: G. Ken Holman > Cc: ubl-dev@lists.oasis-open.org > Subject: Re: [ubl-dev] Re: [ubl] Minutes of Atlantic UBL TC call 13 May 2009 > > NOTHING OTHER THAN MY OWN OPINION: > > I remember myself raising objections in UBL TC when Gunther first > put forward the idea of using the namespace to carry the codelist > version information. That was before Gunther took the idea into > CEFACT. It back then seemed to be heading for trouble because > it would hardwire the schema to the code. Now it seems history > may be proving my misgivings correct. It seemed to me then and > it seems to me all the more so now that the idea hadn't been > thought through thoroughly enough for cementing into a standard. > I guess that is now a legacy hard to get around. I hope Ken and the > others in UBL and in CEFACT can find a way to bring back into the > standard enough flexibility to support the real world user requirements. > Maybe they can do so without a branching of the approaches but I'm > not holding my breath. It seems best to me for Mark to admit that the > requirements cannot be met by the namespace approach and that > UBL just has to diverge a bit from it, at least from reliance on it as a > means of holding version metadata, to meet the user requirements. > To me it seems the choice is between users and standards bodies. > There a millions of users but only a few folk in standards bodies who > need this to go one way or another. I can't see how it could affect > the implementations themselves though in that shifting the placement > of metadata from the XML namespace back to the XML attribute must > be quite a trival bit of development. So why not just back down and try > supporting the real users with their requirements, otherwise it makes > CEFACT look like an oligarchy again. > > AGAIN A DISCLAIMER - ON UBL-DEV - THIS IS JUST MY OWN > OPINION > > Best regards > > Steve > > 2009/5/18 G. Ken Holman <gkholman@cranesoftwrights.com>: >> Please remember that on UBL-Dev I am speaking for myself and my own views >> and not, necessarily, the views of other members of the UBL committee or the >> committee as a whole. I'll let them share their own thoughts on this. >> >> At 2009-05-18 16:14 -0400, Crawford, Mark wrote: >>> >>> This requirement is addressed through the namespace declaration for the >>> currency code list. >> >> Sorry, I fail to see how the namespaces help. They are a schema mechanism >> used by UN/CEFACT to support enumerations that does not meet all the cited >> use cases. >> >> Allow me to explain myself again so that you can teach me what I do not see >> regarding how behind-the-scenes mechanics with namespaces can address the >> use cases I related. >> >> To restate the requirement, a UBL 2.1 system needs to support the following >> five use cases, where the first four need to succeed: >> >> [1] <cbc:TaxAmount currencyID="TRL">17.50</cbc:TaxAmount> >> [2] <cbc:TaxAmount currencyID="TRY">17.50</cbc:TaxAmount> >> [3] <cbc:TaxAmount currencyID="TRL" >> currencyCodeListVersionID="2001">17.50</cbc:TaxAmount> >> [4] <cbc:TaxAmount currencyID="TRY" >> currencyCodeListVersionID="2009">17.50</cbc:TaxAmount> >> >> ... while at the same time this fifth invalid combination must be rejected: >> >> [5] <cbc:TaxAmount currencyID="TRL" >> currencyCodeListVersionID="2009">17.50</cbc:TaxAmount> >> >> At 2009-05-18 16:14 -0400, Crawford, Mark wrote: >>> >>> Each of the 7 code lists used by the UDT schema are >>> updated with each release of the directory. >> >> And how would this at all support the need for a UBL 2.1 system to support a >> UBL 2.0 instance? The updated release of currency codes does not have "TRL" >> because the Turkish Lira is satisfied with "TRK". Thus your suggestion >> loses the requirement for simultaneous and backward-compatible support of >> UBL 2.0 instances by UBL 2.1 systems. >> >> All new constructs in UBL 2.1 are optional in order for a UBL 2.0 instance >> to not violate any structural constraints. >> >> If, as you suggest, UBL 2.1 uses yet another UN/CEFACT UDT schema with >> baked-in hardwired codes for the updated currency values, then an instance >> of UBL 2.0 from Turkey will not validate with UBL 2.1 schemas. Your cited >> approach would not address use cases [1] and [3], as these instances would >> be improperly rejected because the new UN/CEFACT schema won't have "TRL" as >> a valid enumerated value. >> >>> As such, there is no requirement for the supplementary component. >> >> The supplementary component is needed so that use cases [3], [4] and [5] can >> be successfully addressed. >> >> For code lists where the semantics of codes change with different releases >> of the code list (as I cited before has happened in the past), a user can >> choose to explicitly indicate the semantics desired by citing the release of >> the code list through the supplementary component. And the rejection is >> available should such a citation be invalid. >> >>> So let me make sure I >>> understand this - UBL had deliberately chosen to deviate from the >>> UN/CEFACT code list approach, and as a result, must also deviate from >>> the UN/CEFACT representation of supplementary components. Is that >>> correct? >> >> Your words, not mine. I sure don't agree with the bit about supplementary >> components. We sure cannot meet our user requirements with the current >> UN/CEFACT code list approach. We can if we take out the code list >> enumerations and we add in the UN/CEFACT standard supplementary components >> from the CCL08B_17FEB09.xls spreadsheet that are not in the current UDT >> schema. >> >> Please forgive me for not being able to explain myself any clearer to >> illustrate the user requirements that would lead you to your >> misunderstanding. >> >> I think citing the namespaces issue is disingenuous and can lead readers of >> the archive away from the true situation. Namespaces in this context are >> only used in W3C mechanisms for grouping enumerations in different sets. At >> no time do the code list namespaces get exposed in XML instances. Thus >> someone creating an instance based on UN/CEFACT core components cannot cite >> XML namespaces as part of their solution. >> >> I accept that users of UN/CEFACT schemas who are not interested in backward >> compatibility, not interested in longevity of schemas or instances, and >> interested only in closed systems that work with static schemas would >> probably be willing to accept the cost and time of reworking their >> investment in existing instances of old systems in order to work with new >> systems with new schemas. >> >> I'm interested in creating a UBL 2.1 system that supports UBL 2.0 instances. >> I cannot see how "Each of the 7 code lists used by the UDT schema are >> updated with each release" would enable such a UBL 2.1 system. >> >> Even if I chose to use a new namespace for a new enumeration set, and even >> if I chose to use W3C Schema mechanisms to create a union in the schema data >> type of the two enumerations, I would probably be able to cover use cases >> [1] and [2]. And then even if I could simultaneously add the supplementary >> components with a union of values associated with the code lists (not sure >> W3C Schema would let me do that), that would happen to cover use cases [3] >> and [4]. But because W3C Schema 1.0 validation does not support >> co-occurrence constraints, I would not be able to cover use case [5]. >> >> Yes, I suspect with conditional data types in W3C Schema 1.1 this might be >> able to be done, but perhaps only with one supplemental component and not >> necessarily with a combination, and anyway we don't have W3C Schema 1.1 to >> work with. >> >> I look forward to hearing opinions from others on this list. If I am >> missing something or being misleading, it would help me to hear from others >> who can show me how to meet all of the stated use cases. >> >> . . . . . . . . . . . . . . Ken >> >> -- >> XSLT/XQuery/XSL-FO hands-on training - Los Angeles, USA 2009-06-08 >> Crane Softwrights Ltd. http://www.CraneSoftwrights.com/u/ >> Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video >> Video lesson: http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18 >> Video overview: http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18 >> G. Ken Holman mailto:gkholman@CraneSoftwrights.com >> Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/u/bc >> Legal business disclaimers: http://www.CraneSoftwrights.com/legal >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org >> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]