[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] SBS and Restricted Data Types
Also, to use datatype restriction, if you want to comply with UBL's use of CCTS and still only use W3C Schema but don't mind changing the namespace (a key factor), then there is the CCTS standard (for those not aware it is part of ISO 15000) way to do it. You have to create your own 'Qualified Datatypes'(QDTs) in a QDT Schema module (in UBL's case). Then point the elements you want to change to use those datatypes - somehow using, probably substitution goups as the W3C Schema mechanism for derivation which allows a change of namespace (if you want to reuse and not recreate the UBL document schemas). If you don't want to change the namespaces from those of UBL (that might be important in some supply chain or other implementations where you want to use the benefits those namespaces provide) then there are W3C Schema ways with redefine (I think you can actually do this with UBL 1.0 too, having seen a way Mike Grimley demonstrated even though not every element in UBL 1.0 is global). However, if you prefer to avoid the confusion this might cause (I'm not sure UBL would end up calling a major redefine of UBL like this with the same namespaces as UBL and publicly available 'compliant' and it might contravene a thing or two - I'd just suggest seriously looking into it first, perhaps with OASIS too), maybe take Ken's advice and use Schematron or the like instead. It might be safer. ********************************************************** That's an opinion and I have to disclaim against liability if anything goes wrong - after all I'm rushing these answers out voluntarily. I hope we eventually get a good set of guidelines out in UBL 2 or later. ********************************************************** All the best Steve Quoting stephen.green@systml.co.uk: > 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]