[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
Apologies if this has already be clarified in a later posting (still catching up here), wanted to capture the thought: <Quote> I think redefine works similarly where you redefine the context to use my:Name instead of cbc:Name just in that document context </Quote> Since redefine is for data types, it would have to be done on cbc:Name's data type, which is cbc:NameType - which causes the ripple effect that we have been referring to (all references to cbc:Name would be affected). Another potential redefine approach "attempt" (that will not work) would be to redefine a data type that includes the cbc:Name element - one example being cac:PartyNameType - to use my:Name instead of cbc:Name. However, in this case, we would still have the same ripple effect problem, as all references to element cac:PartyName will reflect the My:Name element instead of the cbc:Name element. I believe substitution groups are still an option. 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 [mailto:stephen_green@bristol-city.gov.uk] Sent: Thursday, May 11, 2006 7:04 AM To: gkholman@CraneSoftwrights.com; ubl-dev@lists.oasis-open.org 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/ --------------------------------------------------------------------- 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]