[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] SBS and Restricted Data Types
Joe, If we look at several major US Gov projects using schema to define an uber-structure across agencies we see that these only work up to a point - explicitly because you cannot manage context and role (we won't mention versioning will we...!). Example - several elements are marked as optional - that for specific agencies are required. Result - errors - rejections, re-transmissions and confusion amongst users. Example - elements become overloaded - semantics confused - "Federal Identifier" for one agency accepts a completely different value from another agency (format, length, content mask, usage). Example - code values - globally defined values do not map well to specific agency / community usage - e.g. "Competing Continuation" has no equivalence so forced to use "Re-submission" and "Change" selections. Result - baffled end users. I could go on, and on! This is exactly why we are saying mixing structural mechanism (aka XSD) with use patterns is a bad thing - and its perfectly OK - nay - inevitable - that you need a second mechanism - that is context and role sensitive to overlay on that the actual use pattern. It's *not* that schema is failed - its mostly that it was *never designed* to do what people are trying to do with it - otherwise it would have been engineered completely differently... There are reasons why CAM templates have five sections and schema only has one!!! e.g. : <CAM> <Header> <!-- define context / role variables / version / owner --> <AssemblyStructure> <BusinessUseContext> <ContentReference> <DataValidations> </CAM> DW -------- Original Message -------- Subject: RE: [ubl-dev] SBS and Restricted Data Types From: "Chiusano Joseph" <chiusano_joseph@bah.com> Date: Thu, May 04, 2006 3:01 pm To: "G. Ken Holman" <gkholman@CraneSoftwrights.com>, <ubl-dev@lists.oasis-open.org> Ken, Respectfully: It's not that you're not getting your points across - you are. I just don't agree with them. There's a difference.:) I don't believe that one should be forced to use Schematron in addition to W3C Schema if they don't have to. Having requirements for an initiative is not equivalent to "imposing two trading partners' limits on the whole user community of UBL.". Restricting users from being able to define restrictions for data types is, I believe, imposing a standard's limits on the whole user community that might implement it. 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:37 PM To: ubl-dev@lists.oasis-open.org 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 --------------------------------------------------------------------- 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/ --------------------------------------------------------------------- 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]