[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Proposed addition to 2.1 documented constraints - no schema location hints
I'm not sure these are necessarily issues of UBL per se. If UBL starts to include such as normative requirements it looks like meddling or 'nannying' the implementers. It would be OK if within the mandate (charter?) of UBL's scope but I don't think UBL's charter offically should include providing any 'best practice' guidelines for XML general use for data interchange. Doing so can surely be done by the same people that produce UBL, as a kind of 'lessons learned' about use of XML for data interchange but not as normative statements of requirements to be part of UBL specs since it is broader than UBL's scope. Is there anything special about UBL that means it needs a special implementation of XML? What is the difference between sending and receiving UBL messages and using XML in other ways. If it's the sending and receiving itself (interchange) then that is for a wider audience than UBL interchange and it should not be that just because it is UBL being used for that interchange then these perceived best practices MUST be implemented, whether one agrees with them or not. Best regards --- Stephen D Green 2009/10/16 G. Ken Holman <gkholman@cranesoftwrights.com>: > At 2009-10-16 19:48 +0200, JAVEST by Roberto Cisternino wrote: >> >> I am not aware of the requirement to use RELAX-NG, however the W3C XML >> Schema is a normative syntax for UBL. > > No, it is the normative schema. It is a set of constraints. The choice of > having done so has magically added support for these non-XML attributes for > every document that uses it. > >> Are we going to provide other normative syntaxes ? > > No, I expect not. > > But nor do we prohibit users from using any XML tools on UBL data either. > If someone wants to use RELAX-NG on their XML then they have to know that > because we do not prohibit xsi:* for platform portability that they have to > now accommodate that trading partners may be sending them documents with > these rogue attributes. > > My intent on suggesting this is to promote interoperability by recommending > that UBL documents meant for interchange not include platform-specific > attributes introduced by W3C Schema that are not part of the UBL vocabulary. > >> G. Ken Holman ha scritto: >>> >>> But I sincerely believe platform dependencies have no role in an >>> interchange document and can only introduce problems for recipients. >> >> I agree it is not related to the interchange of data, but within simple >> systems where a sophisticated xml catalog resolver is not available the xsi >> schemaLocation could provide precious information expecially for instances >> where the namespace URI do not provide full information about the XML Schema >> version/customization/profile. > > But your precious location information that you use in your UBL document on > your system may generate errors on my system if (for the same reasons you > cite) I'm obliged to use an XSD tool that respects the xsi:* values. > Without the prohibition then you send me your instance with your attribute > value and I now have to edit the document I receive from you before I can > work with it. > > With the prohibition then I don't see any of your private location > information that is meaningless to my system. > >> Instead, a simple system could be resolving the XML Schema location >> internally by just retrieving the schema name from the xsi:schemaLocation. >> In fact the schema name could be the original name used for that kind of >> customization or profile. > > That might be what it is on your system, but if my schemas are in different > directories or on different disks, then it isn't going to work. > >> So if the schema name is "UBL-Invoice-2.0-Watusi-Tall-1.0.xsd" the >> receiver could match this file locally on their system using just the name >> and ignoring the original path of the sender. > > How is the original path ignored? If I have to go into the file and hack > that attribute to make it work, then I'm not working with the instance as > received. And that isn't scalable if I'm getting thousands of documents. > >> I know this seems to be stupid or crazy, but implementations are very >> similar to my example around the world... :) > > Fine, then, I'm not supposed to worry about this issue. I see proper use of > XML catalogues in tools like Oxygen, but many years ago when I first looked > at XML Spy (I haven't looked at it in a long time), this attribute was > crucial for the correct behaviour of the editor. > > If a recipient has none of the problems I've anticipated when opening a file > from a sender that has a pointer to the sender's internal system, then my > worries are addressed. > > Thanks, Roberto, for bringing this to my attention. We have nothing, then, > to put into the documentation. Nevertheless, I'll still be including it in > my training material as I personally can think of the situations I've > described where the attribute gets in the way (and it isn't part of the UBL > vocabulary). > > . . . . . . . . . . Ken > > -- > Upcoming: hands-on code list, UBL, XSLT, XQuery and XSL-FO classes > in Copenhagen Denmark and Washington DC USA, October/November 2009 > Interested in other classes? http://www.CraneSoftwrights.com/o/i/ > Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/ > 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/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. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]