[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: RE:[ubl-dev]DatatypeMethodologyRE:[ubl-dev]SBSandRestrictedData Types
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/
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]