[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: RE:[ubl-dev]DatatypeMethodologyRE:[ubl-dev]SBSandRestrictedData Types
Plus a reminder that for these to work properly one needs
UBL 2 (globally defined elements)
Steve
Quoting stephen.green@systml.co.uk:
> Maybe, since this does keep the same namespace, it
> should only be something the UBL TC does - perhaps
> to provide UBL for particular contexts. Where then
> would xsi:type fit in?
>
> Maybe customisations outside of the UBL TC * should *
> only do this with a change of namespace (using
> xsd:import rather than xsd:include). So xsi:type
> might then not apply and the problem would be that
> both the derived and the standard types would be
> valid in an instance: so maybe not much use for
> restricting xsd or CCTS datatypes I suppose.
>
> All the best and thanks Joe
>
> Steve
>
>
>
> Quoting stephen.green@systml.co.uk:
>
>> Hi Joe
>>
>> I've checked this and
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
>> elementFormDefault="qualified" attributeFormDefault="unqualified"
>> targetNamespace="urn:oasis:names:specification:ubl:schema:xsd:Invoice-1.0"
>> xmlns:in="urn:oasis:names:specification:ubl:schema:xsd:Invoice-1.0">
>> <xs:include schemaLocation="UBL-Invoice-1.0.xsd"/>
>> <xs:element name="MyInvoice" type="in:MyInvoiceType"
>> substitutionGroup="in:Invoice">
>> <xs:annotation>
>> <xs:documentation>This example does nothing more than change the
>> name of the
>> root element I guess</xs:documentation>
>> </xs:annotation>
>> </xs:element>
>> <xs:complexType name="MyInvoiceType">
>> <xs:complexContent>
>> <xs:extension base="in:InvoiceType"></xs:extension>
>> </xs:complexContent>
>> </xs:complexType>
>> </xs:schema>
>>
>> this seems to be valid with the tool I use.
>>
>> In that case I accept that this is one sort of thing one might wish to do
>> to customise UBL. I'm not sure how this will be viewed by the UBL TC of
>> course regarding how this would sit with any customisation guidelines UBL
>> might provide to supplement UBL 2. We'll see hopefully.
>>
>> All the best
>>
>> Steve
>>
>>
>>
>>
>> Quoting Chiusano Joseph <chiusano_joseph@bah.com>:
>>
>>> I don't believe there is such a restriction with substitution groups
>>> (can anyone clarify that there is one?). The reason I feel comfortable
>>> saying that is because the W3C Schema 1.0 Primer example from below
>>> shows element "shipComment" as substitutable for element "ipo:comment",
>>> and in the instance example it shows shipComment as "ipo:shipComment",
>>> which shows that "shipComment" is in the same namespace as "ipo:comment"
>>> - and therefore xsd:include must have been used.
>>>
>>> However, there is always the chance that the Primer example assumed
>>> (without stipulating) that the schema in which the substitution group
>>> declaration appeared had no target namespace, and namespace coersion
>>> occurred for the "shipComment" element because the schema was
>>> subsequently imported into another schema whose target namespace was the
>>> IPO namespace. Hmmmm....
>>>
>>> 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: stephen.green@systml.co.uk [mailto:stephen.green@systml.co.uk]
>>> Sent: Friday, May 12, 2006 6:33 PM
>>> To: Chiusano Joseph
>>> Cc: ubl-dev@lists.oasis-open.org
>>> 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/Na
>>>>>>>>>>>>> m
>>>>>>>>>>>>> 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/
>>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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]