OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: RE: [ubl-dev] DatatypeMethodologyRE:[ubl-dev]SBSandRestrictedData Types


As Sylvia points out there are rules in UBL's NDR relating to
what the UBL TC itself does in defining UBL standard schemas.

It's the customisations by others of those schemas that isn't
yet guided or the like by the UBL Naming and Design Rules (NDR)

Thanks

Steve



Quoting Sylvia Webb <swebb@gefeg.com>:

> If we are talking about what can be done in UBL today and not what might be
> done in the future, the following NDR from the current UBL 2.0 draft
> document dated February 20, 2006 applies:
>
> 7.3 xsd:substitutionGroup
> 1897 The xsd:substitutionGroup feature enables a type definition to identify
> substitution
> 1898 elements in a group. Although a useful feature in document centric XML
> applications,
> 1899 this feature is not used by UBL.
> 1900 [GXS5] The xsd:substitutionGroup feature MUST NOT be used.
>
> As Mark Crawford correctly stated in an earlier email, the proper way to
> restrict UBL datatypes is to use content and supplementary component
> restrictions from CCTS. The rules for doing this already exist in the UBL
> NDR.
>
> There are at least two possible ways for achieving this, one at the schema
> level using the qDT schema module, the other at the data model level, using
> the qDT spreadsheet, or data modeling tool that supports CCTS.
>
> Sylvia
>
> GEFEG US
> 310-370-3410 - Voice
> 310-370-5614 - Fax
> www.gefeg.com -  Internet
>
>
>
> -----Original Message-----
> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> Sent: Friday, May 12, 2006 2:53 PM
> To: stephen.green@systml.co.uk; ubl-dev@lists.oasis-open.org
> Subject: RE: RE: [ubl-dev] Datatype
> MethodologyRE:[ubl-dev]SBSandRestrictedData Types
>
> 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/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/
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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]