[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] SBS and Restricted Data Types
Joe Do you wish it to be CCTS compliant (ISO 15000-5) ? All the best Steve Quoting Chiusano Joseph <chiusano_joseph@bah.com>: > <Quote> > How would you like to use W3C Scehema to restrict UBL? > </Quote> > > Just like this (using a generic element name): > > <xsd:element name="SomeElement"> > <simpleType name> > <restriction base="string"> > <maxLength value="30"/> > </restriction> > </simpleType> > </xsd:element> > > This restricts the unlimited-in-length "xsd:string" to a max of 30 > characters. > > :) > > 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: stephen.green@systml.co.uk [mailto:stephen.green@systml.co.uk] > Sent: Thursday, May 04, 2006 3:50 PM > To: ubl-dev@lists.oasis-open.org > Subject: RE: [ubl-dev] SBS and Restricted Data Types > > Joe > > Back again :-) Sorry, lots of emails recently! > > I think you don't really disagree. Just that you aren't convinced as we > are, re: >> believe that one should be forced to use Schematron in addition to W3C > >> Schema if they don't have to. > that "... they DO have to." > > We have spent years looking at all this from maybe not all but certainly > many angles. I expect you could look back over the emails on the ubl > lists and ubl-dev and xml-dev. We've consulted experts galore, spent > endless hours and yet we came to the conclusion - which is the bit I > think you might actually not so much disagree with as not be convinced > of - the conclusion that "they have to": > That they have to use Schematron in addition to W3C Schema. > >> 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. > > Not that we are 'restricting users' as you say. > Indeed we are presently providing the best advice we can (Jon Bosak is > hopefully going to start us off with a strawman on this) including > details of UBL's extension points for extensions and details on how to > restrict as cleanly as possible. > > How would you like to use W3C Scehema to restrict UBL? If you consider > UBL 1.0 there may be more complexity and limitations than with UBL 2, I > think. > I did endless prototypes of sets of UBL 1.0 (and UBL 2 prototype) to > demonstrate problems and successes with using the W3C Schema derivation > mechanisms to extend and restrict types and maybe datatypes (not sure > what I did about the latter). All of it is available on the public lists > and a google on 'oasis ubl prototype' > or even 'stephen green ubl datatype' should bring get them. I think they > were around Feb last year. > Then Marty Burns, Tony Coates and Ken and to some extent myself and > particularly Mike Grimley did similar work on extending and restricting > codelists, as did a few kind helpers on xml-dev. In the end we came the > conclusions that W3C Schema couldn't be used to meet requirements of > business relating to restricting and extending enumerations. > If you can find a way then great. We concluded we would turn to > Schematron as many had already advised. So Ken and others worked on a > mechanism how to do this. > > We also concluded that the UBL 1.0 use of a mix of W3C Schema local and > global declarations would not allow some types of use of W3C Schema > derivation so rather than scrap use of W3C Schema we decided to make the > next version of UBL (UBL 2) a major version just so that we could make > every element and type global just to allow customisers and maybe minor > version UBL crafters to use W3C Schema derivation. The extra documents > and modeling work came later. > > So there is great scope with UBL 2 to use W3C derivation to extend and > restrict custom versions of UBL or even to do so without changing the > namespace but for that we probably recommend (inexplicitly so far at > least) use of our existing subsetting mechanism. That's because there > are implications to beware of in using redefine which doesn't change the > namespace, whereas Ken's guidelines in previous emails (thanks > Ken) adequately explain how to avoid pitfalls if you don't like the idea > of departing from the UBL namespace. Plus we are introducing in UBL 2 a > way to keep the namespace and yet extend (using planned extension points > - again a W3C Schema mechanism - xsd:any). > > Hope this helps > > Steve > > > > Quoting Chiusano Joseph <chiusano_joseph@bah.com>: > >> 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/ >> >> > > > > > --------------------------------------------------------------------- > 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]