[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: RE: [ubl-dev] DatatypeMethodologyRE:[ubl-dev]SBSandRestrictedData Types
In other words, wouldn't one have to change or rewrite the
actual UBL schemas to do that? I think that has a different implication
than using a new schema with xsd:redefine which just xsd:includes the
UBL schemas. If one is changing all the UBL schemas but keeping the
same namespaces it looks to me like those schemas shouldn't be published.
There is a difference if one imports or includes UBL schemas - that
ensures an auditable verification that the schema integrity is preserved,
I think. Or writing one's own schemas that reuse UBL schemas (intact)
and with new namespaces for the new schemas - that preserves UBL schema
integrity. But rewriting the UBL schemas to add something like subtitution
groups but not changing the namespaces while changing the schemas - that
seems distinctly dodgy. But does it work technically?
I still prefer Schematron layered over the original standard UBL schemas.
It sounds like quite a few voices here are saying the same.
All the best
Steve
Quoting stephen.green@systml.co.uk:
> 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/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/
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]