[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
Hi Joe But doesn't substitution groups mean that * both * datatypes would be valid in an instance? I so far haven't been able to get the xsi:type method to work well with the tools I use. All the best Steve Quoting Chiusano Joseph <chiusano_joseph@bah.com>: > Thanks Steve. Regarding the following: > > <Quote> > The derivation looks workable: base an element on the qualified rather > than unqualified datatype using redefine or a substitution group. > </Quote> > > I don't believe redefine will work here, but substitution groups will. > Here's my train of though (please tell me of any derailment:)t: > > - As you mentioned, we would create a qualified data type - it would > look as follows (based on cbc:NameType): > > <xsd:simpleType name="MyNameType"> > <xsd:restriction base="cbc:NameType"> > <xsd:maxLength value="35"/> > </xsd:restriction> > </xsd:simpleType> > > - At this point, we need to create a new element that is of > "MyNameType". I don't believe we can use redefine here, as (as you know) > redefine means to redefine a data type. What data type would we > redefine? If we redefined the "udt:NameType" or "cbc:NameType" data > types, we would have the same issue that I referred to earlier (a ripple > effect). > > - However, we could use substitution groups, as you pointed out (but > knowing the dangers of using this approach, as highlighted in the long > threads between XML-DEV and UBL-DEV X months ago asking for input on > usage of substitution groups). Here is an example in which a new element > named "CarrierName", which is of data type "cst:MyNameType" ("cst:" for > "custom" namespace) can substitute for the head element "cbc:Name"): > > <element name="CarrierName" type="cst:MyNameType" > substitutionGroup="cbc:Name"/> > > So "cst:CarrierName" can appear in XML documents in place of cbc:Name. I > am also wondering if one can use the same name for the substituting and > head elements but different namespaces (i.e. instead of "CarrierName", > use "Name" which would be in the "custom" namespace - I have never tried > this (will test it out). > > Thanks, > Joe > > Kind Regards, > 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: Thursday, May 11, 2006 2:51 AM > To: ubl-dev@lists.oasis-open.org > Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS > andRestricted Data Types > > Joe > > Hi. Regarding the technicality of whether W3C XML Schema derivation can > be used to restrict the datatypes in UBL, it seems more plausible, > looking at the examples below, that it might be allowed. The correct way > to do it, I think, is to create a qualified datatype in one's own > qualified datatype schema module. I have an action item to try this sort > of thing as part of the quality control of the next set of draft > schemas, either during or after the coming plenary meeting in Brussels. > The derivation looks workable: base an element on the qualified rather > than unqualified datatype using redefine or a substitution group. > It looks workable depending perhaps on how the qualified datatype is > based on the unqualified datatype it restricts; whether it uses > > > <xsd:simpleType name="MyIndicatorType"> > <xsd:restriction base="xsd:boolean"> > <xsd:pattern value="true"/> > </xsd:restriction> > </xsd:simpleType> > > or > > <xsd:simpleType name="MyIndicatorType"> > <xsd:restriction base="udt:IndicatorType"> > <xsd:pattern value="true"/> > </xsd:restriction> > </xsd:simpleType> > > All the best > > Stephen Green > > Quoting stephen.green@systml.co.uk: > >> Hi Joe, >> >> For example in UBL 1.0 we have the unqualified datatype 'AmountType' >> >> <xsd:complexType name="AmountType"> >> <xsd:simpleContent> >> <xsd:restriction base="cct:AmountType"> >> <xsd:attribute name="amountCurrencyID" > type="xsd:normalizedString" >> use="required"/> >> <xsd:attribute > name="amountCurrencyCodeListVersionID" >> type="xsd:normalizedString" use="optional"/> >> </xsd:restriction> >> </xsd:simpleContent> >> </xsd:complexType> >> >> >> and a corresponding restriction of that UBLAmount which, since it is >> based on the unqualified datatype and a restriction of the same, would > >> now be called a 'qualified datatype' but was, in UBL 1.0, then called >> a 'specialized datatype' >> >> <xsd:complexType name="UBLAmountType"> >> <xsd:simpleContent> >> <xsd:restriction base="udt:AmountType"> >> <xsd:attribute name="amountCurrencyID" > type="cur:CurrencyCodeContentType" >> use="required"/> >> <xsd:attribute > name="amountCurrencyCodeListVersionID" >> type="xsd:normalizedString" use="optional" fixed="0.3"/> >> </xsd:restriction> >> </xsd:simpleContent> >> </xsd:complexType> >> >> In this case the main restriction is that the amountCurrencyID is >> limited to the one codelist (which is the ISO currency codelist) but >> the value of the amountCurrencyCodeListVersionID attribute is also > restricted to '0.3'. >> >> [At the risk of confusing folk, I'd note that in UBL 2 the Amount is >> itself restricted to having the ISO currency codelist as implemented >> by CEFACT's ATG2 so there is no need for the qualified datatype.] >> >> A simpler example, though fictional, would be that if there was a need > >> for a boolean that could only be true, one would have to restrict the >> unqualified Indicator datatype which has a restriction to 'true' and > 'false' >> and base the new datatype on that Indicator, giving it new name >> perhaps (though it would get a new namespace anyway) and restricting >> it to 'true' only. >> In UBL 2 prd there is the ATG2 schema > 'UnqualifiedDataTypeSchemaModule-2.xsd' >> with an Indicator type >> >> <xsd:simpleType name="IndicatorType"> >> <!-- documentation removed --> >> <xsd:restriction base="xsd:boolean"> >> <xsd:pattern value="false"/> >> <xsd:pattern value="true"/> >> </xsd:restriction> >> </xsd:simpleType> >> >> A corresponding, restricted, qualified datatype might therefore be >> >> <xsd:simpleType name="MyIndicatorType"> >> <xsd:restriction base="xsd:boolean"> >> <xsd:pattern value="true"/> >> </xsd:restriction> >> </xsd:simpleType> >> >> or >> >> <xsd:simpleType name="MyIndicatorType"> >> <xsd:restriction base="udt:IndicatorType"> >> <xsd:pattern value="true"/> >> </xsd:restriction> >> </xsd:simpleType> >> >> (I'm not yet certain which of the above is most correct - perhaps it >> is a matter of interpretation of the CCTS.) >> >> >> All the best >> >> Steve >> >> >> >> >> >> >> >> >> Quoting Chiusano Joseph <chiusano_joseph@bah.com>: >> >>> Thanks Steve. Please remind me again what a "qualified" datatype >>> would be? Would it be, for example, a data type whose name (and >>> definition) reflects the restriction that we are speaking of? So for >>> example, instead of the unqualified "IdentifierType", we would have >>> an identifier type that has a pattern restriction and it would be >>> called "SSNIdentifierType"? >>> >>> 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: Wednesday, May 10, 2006 5:38 PM >>> To: ubl-dev@lists.oasis-open.org >>> Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS and > >>> Restricted Data Types >>> >>> Hi Joe >>> >>> Absolutely. Sorry, I'd forgotten this and it isn't all that obvious. >>> The thing is that the datatypes UBL uses are mostly what the CCTS >>> calls unqualified. To redefine them one really (as, thankfully, Mark >>> Crawford explained earlier) has to create new datatypes based on them > >>> which are called qualified datatypes. The element based at present on > >>> the unqualified datatype would have to somehow be replaced, I think, >>> not being able to see how to do it any other way, with a new element >>> based on the restricted qualified datatype. To my mind it needs a new > >>> element and a restricting out of the old element, rather than a >>> redefine of the old element. I can't see how to do the latter with > XSD derivation. >>> If an element was based on a UBL-qualified datatype then maybe, since > >>> it would be under UBL control as it were, one could use XSD redefine >>> to restrict it. That is interesting. It may mean that restriction is >>> limited by use of an unqualified datatype, especially when CCTS (and >>> UBL) compliance is required. >>> I think the same applies to the XSD substitution group method. >>> >>> All the best >>> >>> Stephen Green >>> >>> >>> >>> >>> >>> 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. >>>> >>>> However, this would cause a ripple effect across all other >>>> references to the cbc:Name element within the Despatch Advice schema > >>>> (through references within the Common Aggregate Components schema), >>>> which would >>> >>>> in effect cause all other cbc:Name elements to be a max of 35 >>>> characters. This may or may not be the desired outcome - even if by >>>> chance all should be 35 characters, this of course will not always >>>> be the case. >>>> >>>> So unless I am missing something (which someone will tell me I am >>>> sure:), the xsd:redefine feature will not work in this case. All the > >>>> more reason we need alternate approaches. >>>> >>>> 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: Chiusano Joseph [mailto:chiusano_joseph@bah.com] >>>> Sent: Wednesday, May 10, 2006 3:41 PM >>>> To: David RR Webber (XML); Stephen Green >>>> Cc: ubl-dev@lists.oasis-open.org >>>> Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS >>>> and Restricted Data Types >>>> >>>> David, >>>> >>>> Thinking more about CAM here: How efficient and straightforward >>>> would it be to restrict the data type of - picking a schema and >>>> element completely at random here - the Carrier Name element in the >>>> UBL 2.0 Despatch Advice schema to, say, a maximum of 35 characters? >>>> >>>> Here is the path to that element: >>>> DespatchAdvice/Shipment/Consignment/CarrierParty/PartyName/Name >>>> >>>> Thanks, >>>> 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: David RR Webber (XML) [mailto:david@drrw.info] >>>> Sent: Wednesday, May 10, 2006 11:03 AM >>>> To: Stephen Green >>>> Cc: ubl-dev@lists.oasis-open.org >>>> Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS >>>> and Restricted Data Types >>>> >>>> Stephen, >>>> >>>> I follow your thoughts here. >>>> >>>> We're actively re-visiting on which pieces of the CAM template >>>> should be required and which non-normative / extensible. >>>> >>>> Right now the <DataValidation> and <ExternalMapping> are optional. >>>> Also in jCAM Martin has implemented Maven with these so they are >>>> fully >>> >>>> extensible - but obviously that is then non-normative - but I have >>>> not >>> >>>> yet updated the spec' to reflect that change. It's a critical >>>> direction >>>> - the realization that you cannot perscribe everything for everyone >>>> - and that instead - you provide normative tools for those parts >>>> people expect the standard to - while giving flexiblity - but in a >>>> known and predictable and re-usable way - for those peices they >>>> traditionally expect to have control over. >>>> >>>> The other normative sections are of course tailorable to match the >>>> particular implementors vision and can include only those feartures >>>> and parts that suit (it's just XML markup!). >>>> >>>> What I would expect is that the CAM template would be a base-line >>>> one >>>> - that implementors could then refine and extend to their own local >>> needs. >>>> This I think is inline with the notion of SBS - having a jump-start >>>> kit that people can quickly use by default - and then refine and >>>> extend in practice. Use of <include> is critical to provide >>>> separation between such base-line templates and local extensions. >>>> And then context is vital for people to understand the use model for > >>>> each >>> template. >>>> >>>> DW >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: Re: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS >>>> and Restricted Data Types >>>> From: "Stephen Green" <stephen_green@bristol-city.gov.uk> >>>> Date: Wed, May 10, 2006 10:35 am >>>> To: <ubl-dev@lists.oasis-open.org> >>>> >>>> This makes me think UBL might be benefitted from CAM templates based > >>>> on a profile of CAM which covers the gaps. Maybe one profile without > >>>> the 'context' bit (CCTS concept of it, not CL methodology concept of > >>>> document context) and one with (so one doesn't have to implement a >>>> full-scale CCTS context-sensitive system unless there is a need to). >>>> There may be other bits of CAM not needed in such UBL >>>> implementations too, or parts which UBL duplicates which could be > profiled-out. >>>> >>>> Stephen Green >>>> >>>>>>> "David RR Webber (XML)" <david@drrw.info> 05/10/06 15:02 PM >>> >>>> Chin, >>>> >>>> I was trying to not get into nitty-gritty angle bracket stuff - but >>>> here's a 20,000 foot view. >>>> >>>> The CAM template consists of 5 sections: >>>> >>>> <Header> >>>> <AssemblyStructure> >>>> <BusinessUseContext> >>>> <DataValidations> >>>> <ExternalMapping> >>>> >>>> We can equate the two <AssemblyStructure> and <BusinessUseContext> >>>> to the layering approach - where UBL provides the structure >>>> definition - and the context section then exposes the delta between >>>> the generic and >>> >>>> subset. You can use <include> in the structure section to reference > >>>> a >>> >>>> particular UBL sample. >>>> >>>> Basically if you look in the <BusinessUseContext> section and you >>>> see nothing - then you know people are using that included UBL >>>> sample >>> as-is! >>>> >>>> >>>> Otherwise - the Header can come into play next - because that is >>>> where >>> >>>> you define your global context variables that you might need - for >>>> example boolean $export_order. >>>> >>>> So - in the context section you can have default rules - I would >>>> expect you to have these normally - as these apply to all context >>>> instances and use - these are identified in the XML by - >>>> >>>> <Rules><default><context> <!-- default rules --> >>>> </context>/default> .... >>>> >>>> After that - you have specific context rules - here is where you >>>> would >>> >>>> put the typical refinements and crosschecks (e.g. if $export_order >>>> then <export_manifest> required mandatory element, etc) associated >>>> with your use case - these can reference global $ variables - or be >>>> value driven within the data stream - e.g. : >>>> >>>> <context >>>> condition="PHS398_ResearchPlan:TypeOfApplication='Resubmission'"> >>>> <constraint action="makeMandatory(//RR_SF424:FederalID)" /> >>>> <constraint action="setLength(//RR_SF424:FederalID,15)" /> >>>> </context> </Rules> >>>> >>>> So you can see the deltas are explicitly called out and labelled by >>>> context - and you can find them quickly without having to grope >>>> through the XML structure itself line-by-line. >>>> >>>> CAM also provides you with a library of 30+ functions - so you can >>>> manipulate the structure tree - pruning or selecting, changing from >>>> optional to mandatory, etc, rule driven. I like to say that XSD >>>> schema provides you with a picture map of all the possible >>>> structural varients that you may encounter - whereas CAM restricts >>>> this to the exact structure layout that you need for your particular > >>>> context and >>> usage. >>>> >>>> DW >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS and >>>> Restricted Data Types >>>> From: Chin Chee-Kai <cheekai@softml.net> >>>> Date: Tue, May 09, 2006 9:21 pm >>>> To: UBL-Dev <ubl-dev@lists.oasis-open.org> >>>> >>>> Hi David, >>>> >>>> Very much so, certain level of semantics processing that is common >>>> may >>> >>>> be extracted and stored away as what you call sub-component > templates. >>>> >>>> You mentioned that CAM already handles the deltas by making them >>>> explicit so business users can readily inspect them. It sounds >>>> good, but in what manner does CAM store and manifest the deltas? >>>> Let's say we use the string length restriction from infinite to > 30-char >>>> for example. How does CAM indicate this delta? (Sorry for asking >>>> something so simple relative to CAM as I haven't much exposure to >>>> CAM yet). If he way CAM does it is usable, there may be something >>>> which UBL customisation could incorporate. >>>> >>>> >>>> Best Regards, >>>> Chin Chee-Kai >>>> SoftML >>>> Tel: +65-6820-2979 >>>> Fax: +65-6820-2979 >>>> Email: cheekai@SoftML.Net >>>> http://SoftML.Net/ >>>> >>>> >>>> On Tue, 9 May 2006, David RR Webber (XML) wrote: >>>> >>>>>> Chin, >>>>>> >>>>>> ... >>>>>> >>>>>> Another tool here is <include> statements. Where a template >>>>>> fragment is created that handles default processing of common >>>>>> blocks >>> >>>>>> of XML content (address is an obvious one). Being able to create >>>>>> sub-components templates - breaking the overall processing down >>>>>> into >>> >>>>>> smaller more manageable chunks is another notion that helps to >>>>>> implement concepts such as SBS. >>>>>> >>>>>> DW >>>>>> >>>> >>>> >>>> -------------------------------------------------------------------- >>>> - 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/ >>>> >>>> -------------------------------------------------------------------- >>>> - 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/ >> >> > > > > > --------------------------------------------------------------------- > 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]