[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
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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]