[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 and Restricted Data Types
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]