[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'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]