[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBSandRestricted Data Types
Got it - thanks Steve (will do my best). I've taken the liberty of changing this for every posting in this thread (and the thread that began this one) - I'll resend to the list shortly. Just kidding:) 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: Friday, May 12, 2006 10:17 AM To: ubl-dev@lists.oasis-open.org Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBSandRestricted Data Types Hi Joe Just to request that we try to refer to W3C Schema built-in types and CCTS's qualified and unqualified datatypes as 'datatypes' but call other things like cac:PartyNameType just 'types'. For example there is a complex type called cac:PartyNameType and a complex type called cbc:NameType but there is also a CCTS 'datatype' called udt:NameType and that is based on a W3C XML Schema 'datatype' called xsd:string. It does get confusing but all along in this thread I've been only refering to the udt:NameType and qdt:NameType and xsd:string as datatypes. So redefine is for any type or datatype but we'd be constrained in UBL by CCTS to just use it for types which aren't 'datatypes' and use the reuse in a qualified datatypes schema module (qdt) for 'datatypes'. The same would go for substitution groups. All the best Steve Quoting Chiusano Joseph <chiusano_joseph@bah.com>: > 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/ > > --------------------------------------------------------------------- > 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]