[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS andRestricted Data Types
I believe I can clarify something here: <Quote> There is a problem in that one would have to use xsi:type to guide tools towards the restricted datatype and if this isn't supported then both the unrestricted and the restricted datatypes are valid (as far as I know). </Quote> Subtitution groups do not require use of xsi:type - while redefine does. So substitution groups could be used to restrict datatypes in UBL 2. Please read on only if you don't know (but care) about why subtitution groups do not require use of xsi:type, and redefine does: The reason that subtitution groups do not require (meaning don't need) use of xsi:type is that there cannot be a non-deterministic situation for a schema processer, as when it encounters the "substitutable" element it knows that element's declaration (assuming everything that is supposed to happen happens). With redefine, there may be non-determinism depending on how the redefined version of a datatype relates to its original version - for example, if the redefined version added several optional elements beyond those in the original version, and those optional elements did not appear in an XML document, without xsi:type the schema processor would be dealing with a non-deterministic situation, as it could not be sure which datatype was "in play" - the original or the redefined. 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 11, 2006 3:40 PM To: ubl-dev@lists.oasis-open.org Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS andRestricted Data Types Looking now at restricting datatypes using substitution groups in UBL 2: There is a problem in that one would have to use xsi:type to guide tools towards the restricted datatype and if this isn't supported then both the unrestricted and the restricted datatypes are valid (as far as I know). [The use of the 'abstract' W3C Schema attribute requires a change to the original schemas - no use here, I gather.] So I wouldn't want to use substitution groups to restrict datatypes in UBL 2 (and one cannot with UBL 1.0). They may be good for extensions though but UBL 2 adds extension points to allow that in another way (using xsd:any). That's my opinion at present. So the remaining ways to restrict datatypes in UBL, while complying with CCTS, and not requiring that each and every document context for a particular datatype be affected, seem to be other than with W3C XML Schema mechanisms (except for defining new documents reusing much of UBL but changing much to use new qualified). More options are available if one is content to have the restrictions apply wherever the datatype is used. All the best Stephen Green Quoting stephen.green@systml.co.uk: > I've looked at this today and I've concluded provisionally that > redefine does indeed force the datatype restriction to be used > wherever the datatype occurs in the documents and it seems to be a > little at odds with the design principle in UBL of creating a > qualified datatype to restrict an unqualified datatype and having > these in a separate schema module. > > An alternative for UBL 1.0 is to create new documents as similar to > the UBL documents but with restrictions of certain elements only. > (see attached) This forces a change of namespace and the instances > valid against the reuse schema are different from the standard UBL > instances sufficiently to not be valid since they have different > namespaces included wherever the changes apply. > > Substitution groups are my next study relating to datatype restriction. > Can they be used in UBL 1.0 at all? In UBL 2, at least, can they be > used to limit the use of the restricted datatype to just a single > element (document context) with the other elements based on the > datatype being still based on the unrestricted version? > > All the best > > Steve > > > > Quoting Stephen Green <stephen_green@bristol-city.gov.uk>: > >> Another point about this I'd like to look at is whether the >> undermentioned can work using redefine with UBL 1.0. >> I'm more confident that using susbtitution groups won't work like >> this with UBL 1.0 generally (there might be some exceptions) since >> there are non-global elements such as IDs and Codes in UBL 1.0 which >> cause problems for substitution groups, I think. This was why we >> changed the design and used all global declarations in UBL 2 >> (actually the reason to make it a major version change). >> >> All the best >> >> Steve >> >>>>> <stephen.green@systml.co.uk> 11/05/06 12:14:48 >>> >> Of course though, if the document context only applies to a >> particular occorrance deep in the structure then everything 'above' >> it has to be redefined or substituted too but there may be a limit to >> how to restrict automatic reuse - that I'd have to try. It could be >> days or a few weeks before I can do this. >> I don't get the impression folk are queueing up to actually do this >> (it was a long time before anyone noticed the problem with it where >> not every element is global, which seems to suggest it isn't on many >> folks' priority list). >> >> All the best >> >> Steve >> >> >> >> Quoting Stephen Green <stephen_green@bristol-city.gov.uk>: >> >>> Hi Ken >>> >>> I think (not sure without trying) you can create my:Name and >>> substitute cbc:Name with it just in particular document contexts. I >>> think redefine works similarly where you redefine the context to use >>> my:Name instead of cbc:Name just in that document context. I >>> wouldn't say it is exactly trivial and might not be something >>> traders have access ready to (even with a decent IT department). >>> Hence doing >>> this once on behalf of many SMEs would seem appropriate but even >>> then I wouldn't want to do it if there were no reason to. >>> >>> All the best >>> >>> Steve >>> >>> >>>>>> "G. Ken Holman" <gkholman@CraneSoftwrights.com> 11/05/06 11:53:10 >>>>>> >>> >>> At 2006-05-11 11:24 +0100, Stephen Green wrote: >>>> >> Quoting Chiusano Joseph <chiusano_joseph@bah.com>: >>>> >> >>>> >>> P.S. Regarding xsd:redefine: A redefine of this element >>>> >>> (Carrier Name, >>>> >> >>>> >>> represented as cbc:Name) does not seem possible (unless my >>>> >>> dusting off >>>> >> >>>> >>> of the xsd:redefine feature brings misunderstanding with it), >>>> >>> as one would need to redefine its type, which is cbc:NameType, >>>> >>> to have a max of >>>> >>> 35 characters rather than an unlimited number. >>>> >>>> To summarise: the solution has been designed, so it seems to me at >>>> least, on the premise that you create a new datatype based on the >>>> existing datatype (or maybe based on the same xsd:datatype as the >>>> existing datatype, if that will work) and restrict that. >>>> >>>> So the cbc:Name might use the datatype udt:NameType which is based >>>> on xsd:string. >>>> You define a qualified datatype qdt:MyNameType with either >>>> >>>> <xsd:restriction base="xsd:string"> or >>>> <xsd:restriction base="udt:NameType"> >>>> >>>> Then restrict it >>>> >>>> <xsd:restriction base="xsd:string"> >>>> <xsd:minLength="1"/> >>>> <xsd:maxLength="35"/> >>>> </xsd:restriction> >>>> or >>>> >>>> <xsd:restriction base="udt:IndicatorType"> >>>> <xsd:minLength="1"/> >>>> <xsd:maxLength="35"/> >>>> </xsd:restriction> >>>> >>>> <Technical Note> >>>> I need to test which of these works at all (or best). >>> >>> Won't you get a "duplicate definition" on cbc:Name because the UBL >>> NDR forces all elements to be globally defined? >>> >>> Recognizing, of course, that *every* occurrence of cbc:Name will be >>> affected by this, but that might be just fine in this scenario. >>> >>> But (while I don't have the time to test it myself), my gut feel is >>> that the validator will complain that your new global definition of >>> cbc:Name conflicts with the existing global definition of cbc:Name >>> in the (read-only) UBL schemas, and it won't work. >>> >>> At least that is my recollection of my attempts with the UBL schemas >>> at redefinition. >>> >>>> An alternative is to completely rewrite the schemas, relying on >>>> some clever developers to ensure that there is full derivation-rule >>>> backwards compatibility with regard to instances and validation. I >>>> think that is the present >>>> ATG2 approach. >>> >>> Or (if I can find the time) by an exhaustion approach which, I >>> believe, will be definitive and programmatically provable. >>> >>>> Another alternative is Schematron second pass validation and prose >>>> or XML definition of the restrictions along the same lines as >>>> business rules and codelists. >>> >>> Yes, though I'm not fond of using Schematron for structural >>> constraints ... structural co-occurrence constraints yes, but not >>> just for simple structural constraints. >>> >>>> That's a bit about the 'how' but it doesn't really answer the >>>> 'which' or the 'whether'. >>> >>> Time and trial will tell. >>> >>> I'm anxious to see your results, Stephen. >>> >>> . . . . . . . . . . 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/ >> >> >> --------------------------------------------------------------------- >> 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]