[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: RE: [ubl-dev]DatatypeMethodologyRE:[ubl-dev]SBSandRestrictedData Types
Sorry, my later posting crossed with yours Joe, so it doesn't follow on from this. I thought substitution groups could only be used with xsd:import and not with xsd:include. Is that correct? Hence the need to have a new namespace. All the best Steve Quoting Chiusano Joseph <chiusano_joseph@bah.com>: > That's ok Steve - I don't feel pressed at all.:) > > It wouldn't entail any rewrites whatsoever of the UBL schemas, or any > changes to them. Here's what I believe someone using UBL who decided to > create substitutions would need to do - let's assume that they are using > the same namespace as UBL: > > - Create a new schema that includes a UBL schema; > > - Declare the CBC namespace as the target namespace, which means that > any global elements in the new schema (including substitution elements) > are in the CBC namespace; > > - Specify the substitution in the new schema - for example: > > <element name="CarrierName" type="qdt:StringMax35Type" > substitutionGroup="cbc:Name"/> > > The "CarrierName" element does not need to be declared separately, as > its inclusion in the substitution group declaration above serves as its > declaration (as evidenced by the requirement for a type). Also, > CarrierName would be in the CBC namespace because it doesn't have a > namespace prefix - which is why we cannot call it "Name". If you declare > a "custom" namespace in the new schema and put a prefix such as "cst:" > in front of CarrierName, that would place it in the "custom" namespace. > In this case, you could use the same element name as the head element > (i.e. cst:Name), since the elements are in different namespaces. > > 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 6:01 PM > To: Chiusano Joseph > Cc: ubl-dev@lists.oasis-open.org > Subject: RE: RE: [ubl-dev] > DatatypeMethodologyRE:[ubl-dev]SBSandRestrictedData Types > > Joe > > Very sorry to press you on this: but the approach you envisage, if it > were to keep the same namespaces as in standard UBL, what would it > entail? Would it mean rewriting the UBL standard schemas at all and if > so would it involve any publishing of new schemas with unchanged UBL > namespaces? > > Of course there is the question: Is that valid for UBL? > But the question I'm really thinking is: How do you do that? > and: would you actually want to do that? > > So the schemas have substitution groups in them and the same namespaces > as UBL: Is that even possible? And is it likely? > > All the best > > Steve > > > > > Quoting Chiusano Joseph <chiusano_joseph@bah.com>: > >> I don't believe it's a requirement to do so for W3C Schema (my >> research has not uncovered anything to that effect). Whether it's best > >> to do so would be a choice, I believe. >> >> Specific to UBL, I am not sure if there is a policy regarding >> namespaces that would require importing the UBL into a schema with a >> new namespace in order to use substitution groups. >> >> 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 5:47 PM >> To: ubl-dev@lists.oasis-open.org >> Subject: RE: RE: [ubl-dev] Datatype >> MethodologyRE:[ubl-dev]SBSandRestrictedData Types >> >> But if one wanted to use substitution groups with UBL wouldn't one >> have to import the UBL schemas into a schema with a new namespace? >> >> Steve >> >> >> Quoting Chiusano Joseph <chiusano_joseph@bah.com>: >> >>> Actually, with substitution groups you're not required to change the >>> namespace, though you could. That is, the substituting and head >>> elements may be in the same namespace, or different namespaces. >>> >>> Here is the example from the W3C Schema 1.0 Primer, where element >>> "ipo:shipComment" can substitute for head element "ipo:comment": >>> >>> <element name="shipComment" type="string" >>> substitutionGroup="ipo:comment"/> <element >>> name="customerComment" type="string" >>> substitutionGroup="ipo:comment"/> >>> >>> And the corresponding XML instance example: >>> >>> .... >>> <items> >>> <item partNum="833-AA"> >>> <productName>Lapis necklace</productName> >>> <quantity>1</quantity> >>> <USPrice>99.95</USPrice> >>> <ipo:shipComment> >>> Use gold wrap if possible >>> </ipo:shipComment> >>> <ipo:customerComment> >>> Want this for the holidays! >>> </ipo:customerComment> >>> <shipDate>1999-12-05</shipDate> >>> </item> >>> </items> >>> .... >>> >>> 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 5:14 PM >>> To: Chiusano Joseph >>> Cc: ubl-dev@lists.oasis-open.org >>> Subject: RE: RE: [ubl-dev] Datatype >>> MethodologyRE:[ubl-dev]SBSandRestricted Data Types >>> >>> Hey - but then you have to change the namespace - and is the benefit >>> (is there a clear one?) worth that? However, with Schematron together > >>> with the original schemas one doesn't have to change the namespace >>> and >> >>> there are more options of what one can call valid or invalid or >>> anything in between (as with the SBS where UBL/non-subset elements >>> are >> >>> still valid but flagged). >>> >>> All the best >>> >>> Steve >>> >>> >>> Quoting Chiusano Joseph <chiusano_joseph@bah.com>: >>> >>>> Ah - now the bottom line. I believe I may have talked myself out of >>>> substitution groups as a preferred approach - at least using >>>> substitution groups alone. Instead I've relegated them to being a >>>> "possible" approach. The only (or at least primary) reason for this >>>> is >>> >>>> the issue we have been mentioning, which is that there is no >>>> facility >> >>>> within W3C Schema to control which occurrences of a head element can > >>>> be substituted with the new element. So one needs to enforce this >>>> outside of W3C Schema, which can be done using Schematron > assertions. >>>> However, using substitution groups along with Schematron assertions >>>> might not be such a bad thing. >>>> >>>> So bottom line, substitution groups may be risky to use without >>>> additional verification abilities, which can be provided by >>> Schematron. >>>> >>>> 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 4:27 PM >>>> To: Chiusano Joseph >>>> Cc: ubl-dev@lists.oasis-open.org >>>> Subject: RE: RE: [ubl-dev] Datatype Methodology >>>> RE:[ubl-dev]SBSandRestricted Data Types >>>> >>>> Joe, >>>> >>>> Any chance you could say how substitution groups might be useful in >>>> your situation? >>>> >>>> All the best >>>> >>>> Steve >>>> >>>> >>>> Quoting Chiusano Joseph <chiusano_joseph@bah.com>: >>>> >>>>> Oops, meant to answer the rest of the questions: >>>>> >>>>> <Quote> >>>>> If redefine were used, how useful would xsi:type be? Not very I >>>>> suspect, if again the schema doesn't enforce the restriction but >>>>> if, >> >>>>> despite an instance using the redefined schema as the schema >>>>> location, >>>> >>>>> the onus is on the instance producer to decide whether the >>>>> restricted >>> >>>>> datatype is >>>>> used: after all it is the receiving system which wants the >>>> restriction. >>>>> </Quote> >>>>> >>>>> I believe xsi:type is required for redefine, not optional - so I >>>>> believe it's beyond the question of it being useful (though >>>>> opinions >> >>>>> on this are valid of course). The onus indeed is on the instance >>>>> producer to decide whether the restricted datatype is used - which >>>>> of >>> >>>>> course adds additional complexity to producing the instance (and a >>>>> margin for error by specifying the incorrect xsi:type value). >>>>> >>>>> <Quote> >>>>> How about just redeclaring everything in a new schema, almost >>>>> exactly >>> >>>>> the same as the original but with the restrictions - with or >>>>> without >> >>>>> the same namespaces? >>>>> </Quote> >>>>> >>>>> Always an option - not necessarily good for interoperability, IMO, >>>>> but >>>> >>>>> in some cases it may be the best resort. For us (the initiative I >>>>> am >> >>>>> working on), I see other options such as substitution groups or > CAM. >>>>> For adding additional elements, there is also the combination of >>>>> substitution groups and NVDL (if the additional elements are in a >>>>> separate namespace), or CAM. >>>>> >>>>> 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 3:41 PM >>>>> To: Chiusano Joseph >>>>> Cc: ubl-dev@lists.oasis-open.org >>>>> Subject: RE: RE: [ubl-dev] Datatype Methodology RE: >>>>> [ubl-dev]SBSandRestricted Data Types >>>>> >>>>> Hi Joe >>>>> >>>>> Yep I admit it - I was trying to use xsi:type with substitution >>>> groups. >>>>> Ooops. Still, the problem remains then that one can't actually use >>>>> the >>>> >>>>> substitution group to restrict the datatype since there is no >>>> 'abstract' >>>>> declaration in the original schema and no way to prevent the >>>>> unrestricted cbc:Name being valid in an instance. Is that correct? >>>>> >>>>> If redefine were used, how useful would xsi:type be? Not very I >>>>> suspect, if again the schema doesn't enforce the restriction but >>>>> if, >> >>>>> despite an instance using the redefined schema as the schema >>>>> location, >>>> >>>>> the onus is on the instance producer to decide whether the >>>>> restricted >>> >>>>> datatype is >>>>> used: after all it is the receiving system which wants the >>>> restriction. >>>>> >>>>> How about just redeclaring everything in a new schema, almost >>>>> exactly >>> >>>>> the same as the original but with the restrictions - with or >>>>> without >> >>>>> the same namespaces? >>>>> >>>>> Many thanks >>>>> >>>>> Steve >>>>> >>>>> >>>>> >>>>> >>>>> Quoting Chiusano Joseph <chiusano_joseph@bah.com>: >>>>> >>>>>> Steve, >>>>>> >>>>>> Both datatypes - "cst:MyNameType" and "cbc:Name" - would be valid >>>>>> in >>> >>>>>> an instance, only in that the elements declared to be of those >>>>>> datatypes in the example below ("cst:CarrierName" and "cbc:Name") >>>>>> can >>>> >>>>>> both appear in instances, and "cst:CarrierName" can be substituted > >>>>>> for >>>>> "cbc:Name" >>>>>> wherever "cbc:Name" appears. Is that what you meant by both >>>>>> datatypes >>>> >>>>>> would be valid in an instance? >>>>>> >>>>>> Unless my recent posting was incorrect, xsi:type is not used with >>>>>> substitution groups - which is why you may have been having the >>>>>> problems with tools that you mentioned below, unless you meant >>>>>> that >> >>>>>> you have had problems using xsi:type with redefined datatypes and >>>>> abstract datatypes. >>>>>> >>>>>> 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 3:30 AM >>>>>> To: Chiusano Joseph >>>>>> Cc: ubl-dev@lists.oasis-open.org >>>>>> 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/Nam >>>>>>>>>> e >>>>>>>>>> >>>>>>>>>> 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/ >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> --------------------------------------------------------------------- >>> 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]