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