[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] SBS and Restricted Data Types
At 2006-05-04 12:07 -0400, Chiusano Joseph wrote: ><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. I'm very sorry I'm not getting my point across. I feel I keep repeating myself and doing so is taking an awful lot of time. If you put it in the schema, you are constraining the vocabulary. The vocabulary should be considered sacrosanct and untouchable. Throughout programming it is considered good technical practice to use layering (protocols, implementations, constraints, operating system user interfaces, etc.) where one combines solving different problems with different appropriate layered solutions rather than creating (and having to change) one monolithic solution that impacts on all users. Using Schematron one can layer on top of the schemas their own restrictive rules (business or technical). If you want to restrict the length of a description, Joe, that's fine ... go ahead and do it, just don't change the definition of UBL doing so, and the *only* normative component of UBL is the schema expression. Those files are really sacrosanct and untouchable. And it doesn't make sense to impose one implementation's limits on the whole user community of UBL. And it doesn't make sense to impose two trading partners' limits on the whole user community of UBL. UBL is defined so that everyone can use it ... why do you insist on trying to change it? If you have your own restrictions then implement your own restrictions without changing UBL as that changes it for everyone. I have said it many times and you keep asking me why again and again that I don't want to use W3C Schema facilities or make W3C Schema changes to the normative expressions , but I feel it is inappropriate to modify the W3C Schema expression since that is normatively described by the committee and, therefore, should not be touched. . . . . . . . . . . . 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]