[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
Steve, I don't believe you've yet received an answer to your question below: <Quote> 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? </Quote> Since substitution groups can be used only with global elements (i.e. the head element must be declared as a global element), as you've pointed out in recent postings substitution groups will not work with all UBL 1.0 elements, as some are local. To your second question: If by "to just a single element" you mean "to just a single occurrence of a given element", I believe the answer would be no. Once you declare an element as "substitutable" for another element, that means that element can replace the head element wherever the head element occurs. There is no facility within W3C Schema for controlling which occurrences of the head element the substitutable element can replace - it would need to be enforced outside W3C Schema. 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 1:32 PM To: ubl-dev@lists.oasis-open.org Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS andRestricted Data Types 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/ > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]