[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] SBS and Restricted Data Types
<Quote> At 2006-05-04 11:31 -0400, Chiusano Joseph wrote: >The same would apply for data type restrictions - if there were some >overriding, unavoidable reason that a trading partner could not honor a >length for a description of (say) 30 characters, and they instead sent >you 100, then there needs to be requirements for handling this >situation (e.g. is it ok to truncate the characters beyond the 30th?). Then put that in a business rule (i.e. asserted using Schematron), don't change the constraints of the expression of the information in the document vocabulary. </Quote> Recognizing the high value of Schematron and its capabilities beyond those of W3C Schema, why should someone be forced to used Schematron in addition to W3C Schema when W3C Schema already has facilities for this requirement? (e.g. xsd:minLength, xsd:maxLength, xsd:Length) I'm very sorry if I am not seeing the intended value. Joe Joseph Chiusano Associate Booz Allen Hamilton 700 13th St. NW, Suite 1100 Washington, DC 20005 O: 202-508-6514 C: 202-251-0731 Visit us online@ http://www.boozallen.com -----Original Message----- From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com] Sent: Thursday, May 04, 2006 12:03 PM To: ubl-dev@lists.oasis-open.org Subject: RE: [ubl-dev] SBS and Restricted Data Types At 2006-05-04 11:31 -0400, Chiusano Joseph wrote: >The same would apply for data type restrictions - if there were some >overriding, unavoidable reason that a trading partner could not honor a >length for a description of (say) 30 characters, and they instead sent >you 100, then there needs to be requirements for handling this >situation (e.g. is it ok to truncate the characters beyond the 30th?). Then put that in a business rule (i.e. asserted using Schematron), don't change the constraints of the expression of the information in the document vocabulary. >What has happened to the notion of contract-based interoperabilty, >where trading partners adhered to a technical contract to the greatest >degree feasible and possible? Why leave data type restrictions (such as >string >length) out in the cold? I really don't understand what the issue is >here (please note that that is not a criticism of your perspective). > >So with all due respect, and for what it may be worth, I completely >differ with your views on interoperability as expressed below. That is >not to say in any way that they are incorrect - I just have a very >different perspective on interoperability, and the possibilities that >can be realized. > >Please correct my thinking if needed - I want to be told I am wrong if >you or anyone else believes I am. Who is to say what is "correct" Joe when dealing with perspectives? For my two cents (Canadian), implementation constraints such as string length have no role in XML vocabularies. XML vocabularies are used to express user's information so that users can convey what they need to do their business. If an implementation chooses to constrain a user's use of a vocabulary, that is up to the implementation, not to the abstract definitions expressed in the vocabulary. Implementations of standards differentiate themselves by how well they work with the standards and which features they offer to their users. If in my business I absolutely need to use 100 characters for my description, then I'm going to go out there looking for an implementation that supports me. If I can't find one, then I'll have other decisions to make, but I would have had that if the "standard" arbitrarily restricted me. But I don't have to make those decisions if there are applications that support me. I don't think implementations should arbitrarily constrain users of XML vocabularies ... that is the tail wagging the dog. If I enter into a trading agreement with a trading partner and we mutually agree that our use of UBL will require that a given string be constrained to 30 characters, that is a business/technical decision between me and my partner, it is not a constraint on the document vocabulary, and I'll express that constraint as an assertion that can be tested after structural integrity has been tested. . . . . . . . . . . . . . Ken -- Registration open for XSLT/XSL-FO training: Wash.,DC 2006-06-12/16 Also for XSLT/XSL-FO training: Minneapolis, MN 2006-07-31/08-04 Also for XML/XSLT/XSL-FO training:Birmingham,England 2006-05-22/25 Also for XSLT/XSL-FO training: Copenhagen,Denmark 2006-05-08/11 World-wide on-site corporate, govt. & user group XML/XSL training. G. Ken Holman mailto:gkholman@CraneSoftwrights.com Crane Softwrights Ltd. http://www.CraneSoftwrights.com/u/ Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995) Male Cancer Awareness Aug'05 http://www.CraneSoftwrights.com/u/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal --------------------------------------------------------------------- This publicly archived list supports open discussion on implementing the UBL OASIS Standard. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Alternately, using email: list-[un]subscribe@lists.oasis-open.org List archives: http://lists.oasis-open.org/archives/ubl-dev/ Committee homepage: http://www.oasis-open.org/committees/ubl/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php Join OASIS: http://www.oasis-open.org/join/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]