[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
UBL doesn't yet have a definitive 'customisation' policy
on these things. Jon has been considering a strawman and
that will be further considered by the TC later, after the
next schema package is finished. Hence my zealousness in
following through on this discussion.
There are a few things that were decided in the UBL 1.0
timeframe but that was temporary with a view to completing
a fuller customisation methodology in the UBL 2 timeframe.
One step has been to decide to use extension points (xsd:any)
and there have been changes like the move to all global and
a change to the versioning design regarding namespaces and
a version element, UBLVersion. The guidelines beyond that are
open for discussion.
All the best
Steve
Quoting Chiusano Joseph <chiusano_joseph@bah.com>:
> <Quote>
> In other words, wouldn't one have to change or rewrite the actual UBL
> schemas to do that?
> </Quote>
>
> Oh, I don't believe so (someone please chime in if I am wrong). The UBL
> schemas would be included or imported to another schema created by the
> implementer, that contains the substitution group definition. Of course,
> as Sylvia pointed out UBL has a policy on using substitution groups so
> please consider my comments as speaking more generally about
> possibilities.
>
> 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:30 PM
> To: ubl-dev@lists.oasis-open.org
> Subject: RE: RE: [ubl-dev]
> DatatypeMethodologyRE:[ubl-dev]SBSandRestrictedData Types
>
> In other words, wouldn't one have to change or rewrite the actual UBL
> schemas to do that? I think that has a different implication than using
> a new schema with xsd:redefine which just xsd:includes the UBL schemas.
> If one is changing all the UBL schemas but keeping the same namespaces
> it looks to me like those schemas shouldn't be published.
> There is a difference if one imports or includes UBL schemas - that
> ensures an auditable verification that the schema integrity is
> preserved, I think. Or writing one's own schemas that reuse UBL schemas
> (intact) and with new namespaces for the new schemas - that preserves
> UBL schema integrity. But rewriting the UBL schemas to add something
> like subtitution groups but not changing the namespaces while changing
> the schemas - that seems distinctly dodgy. But does it work technically?
>
> I still prefer Schematron layered over the original standard UBL
> schemas.
> It sounds like quite a few voices here are saying the same.
>
> All the best
>
> Steve
>
>
>
>
> Quoting stephen.green@systml.co.uk:
>
>> Joe
>>
>> Very sorry to press you on this: but the approach you envisage, if it
>> were to keep the same namespaces as in standard UBL, what would it
>> entail? Would it mean rewriting the UBL standard schemas at all and if
>
>> so would it involve any publishing of new schemas with unchanged UBL
>> namespaces?
>>
>> Of course there is the question: Is that valid for UBL?
>> But the question I'm really thinking is: How do you do that?
>> and: would you actually want to do that?
>>
>> So the schemas have substitution groups in them and the same
>> namespaces as UBL: Is that even possible? And is it likely?
>>
>> All the best
>>
>> Steve
>>
>>
>>
>>
>> Quoting Chiusano Joseph <chiusano_joseph@bah.com>:
>>
>>> I don't believe it's a requirement to do so for W3C Schema (my
>>> research has not uncovered anything to that effect). Whether it's
>>> best to do so would be a choice, I believe.
>>>
>>> Specific to UBL, I am not sure if there is a policy regarding
>>> namespaces that would require importing the UBL into a schema with a
>>> new namespace in order to use substitution groups.
>>>
>>> Joe
>>>
>>> Joseph Chiusano
>>> Associate
>>> Booz Allen Hamilton
>>>
>>> 700 13th St. NW, Suite 1100
>>> Washington, DC 20005
>>> O: 202-508-6514
>>> C: 202-251-0731
>>> Visit us online@ http://www.boozallen.com
>>>
>>> -----Original Message-----
>>> From: stephen.green@systml.co.uk [mailto:stephen.green@systml.co.uk]
>>> Sent: Friday, May 12, 2006 5:47 PM
>>> To: ubl-dev@lists.oasis-open.org
>>> Subject: RE: RE: [ubl-dev] Datatype
>>> MethodologyRE:[ubl-dev]SBSandRestrictedData Types
>>>
>>> But if one wanted to use substitution groups with UBL wouldn't one
>>> have to import the UBL schemas into a schema with a new namespace?
>>>
>>> Steve
>>>
>>>
>>> Quoting Chiusano Joseph <chiusano_joseph@bah.com>:
>>>
>>>> Actually, with substitution groups you're not required to change the
>
>>>> namespace, though you could. That is, the substituting and head
>>>> elements may be in the same namespace, or different namespaces.
>>>>
>>>> Here is the example from the W3C Schema 1.0 Primer, where element
>>>> "ipo:shipComment" can substitute for head element "ipo:comment":
>>>>
>>>> <element name="shipComment" type="string"
>>>> substitutionGroup="ipo:comment"/> <element
>>>> name="customerComment" type="string"
>>>> substitutionGroup="ipo:comment"/>
>>>>
>>>> And the corresponding XML instance example:
>>>>
>>>> ....
>>>> <items>
>>>> <item partNum="833-AA">
>>>> <productName>Lapis necklace</productName>
>>>> <quantity>1</quantity>
>>>> <USPrice>99.95</USPrice>
>>>> <ipo:shipComment>
>>>> Use gold wrap if possible
>>>> </ipo:shipComment>
>>>> <ipo:customerComment>
>>>> Want this for the holidays!
>>>> </ipo:customerComment>
>>>> <shipDate>1999-12-05</shipDate>
>>>> </item>
>>>> </items>
>>>> ....
>>>>
>>>> Joe
>>>>
>>>> Joseph Chiusano
>>>> Associate
>>>> Booz Allen Hamilton
>>>>
>>>> 700 13th St. NW, Suite 1100
>>>> Washington, DC 20005
>>>> O: 202-508-6514
>>>> C: 202-251-0731
>>>> Visit us online@ http://www.boozallen.com
>>>>
>>>> -----Original Message-----
>>>> From: stephen.green@systml.co.uk [mailto:stephen.green@systml.co.uk]
>>>> Sent: Friday, May 12, 2006 5:14 PM
>>>> To: Chiusano Joseph
>>>> Cc: ubl-dev@lists.oasis-open.org
>>>> Subject: RE: RE: [ubl-dev] Datatype
>>>> MethodologyRE:[ubl-dev]SBSandRestricted Data Types
>>>>
>>>> Hey - but then you have to change the namespace - and is the benefit
>
>>>> (is there a clear one?) worth that? However, with Schematron
>>>> together with the original schemas one doesn't have to change the
>>>> namespace and
>>>
>>>> there are more options of what one can call valid or invalid or
>>>> anything in between (as with the SBS where UBL/non-subset elements
>>>> are
>>>
>>>> still valid but flagged).
>>>>
>>>> All the best
>>>>
>>>> Steve
>>>>
>>>>
>>>> Quoting Chiusano Joseph <chiusano_joseph@bah.com>:
>>>>
>>>>> Ah - now the bottom line. I believe I may have talked myself out of
>
>>>>> substitution groups as a preferred approach - at least using
>>>>> substitution groups alone. Instead I've relegated them to being a
>>>>> "possible" approach. The only (or at least primary) reason for this
>
>>>>> is
>>>>
>>>>> the issue we have been mentioning, which is that there is no
>>>>> facility
>>>
>>>>> within W3C Schema to control which occurrences of a head element
>>>>> can be substituted with the new element. So one needs to enforce
>>>>> this outside of W3C Schema, which can be done using Schematron
> assertions.
>>>>> However, using substitution groups along with Schematron assertions
>
>>>>> might not be such a bad thing.
>>>>>
>>>>> So bottom line, substitution groups may be risky to use without
>>>>> additional verification abilities, which can be provided by
>>>> Schematron.
>>>>>
>>>>> Joe
>>>>>
>>>>> Joseph Chiusano
>>>>> Associate
>>>>> Booz Allen Hamilton
>>>>>
>>>>> 700 13th St. NW, Suite 1100
>>>>> Washington, DC 20005
>>>>> O: 202-508-6514
>>>>> C: 202-251-0731
>>>>> Visit us online@ http://www.boozallen.com
>>>>>
>>>>> -----Original Message-----
>>>>> From: stephen.green@systml.co.uk
>>>>> [mailto:stephen.green@systml.co.uk]
>>>>> Sent: Friday, May 12, 2006 4:27 PM
>>>>> To: Chiusano Joseph
>>>>> Cc: ubl-dev@lists.oasis-open.org
>>>>> Subject: RE: RE: [ubl-dev] Datatype Methodology
>>>>> RE:[ubl-dev]SBSandRestricted Data Types
>>>>>
>>>>> Joe,
>>>>>
>>>>> Any chance you could say how substitution groups might be useful in
>
>>>>> your situation?
>>>>>
>>>>> All the best
>>>>>
>>>>> Steve
>>>>>
>>>>>
>>>>> Quoting Chiusano Joseph <chiusano_joseph@bah.com>:
>>>>>
>>>>>> Oops, meant to answer the rest of the questions:
>>>>>>
>>>>>> <Quote>
>>>>>> If redefine were used, how useful would xsi:type be? Not very I
>>>>>> suspect, if again the schema doesn't enforce the restriction but
>>>>>> if,
>>>
>>>>>> despite an instance using the redefined schema as the schema
>>>>>> location,
>>>>>
>>>>>> the onus is on the instance producer to decide whether the
>>>>>> restricted
>>>>
>>>>>> datatype is
>>>>>> used: after all it is the receiving system which wants the
>>>>> restriction.
>>>>>> </Quote>
>>>>>>
>>>>>> I believe xsi:type is required for redefine, not optional - so I
>>>>>> believe it's beyond the question of it being useful (though
>>>>>> opinions
>>>
>>>>>> on this are valid of course). The onus indeed is on the instance
>>>>>> producer to decide whether the restricted datatype is used - which
>
>>>>>> of
>>>>
>>>>>> course adds additional complexity to producing the instance (and a
>
>>>>>> margin for error by specifying the incorrect xsi:type value).
>>>>>>
>>>>>> <Quote>
>>>>>> How about just redeclaring everything in a new schema, almost
>>>>>> exactly
>>>>
>>>>>> the same as the original but with the restrictions - with or
>>>>>> without
>>>
>>>>>> the same namespaces?
>>>>>> </Quote>
>>>>>>
>>>>>> Always an option - not necessarily good for interoperability, IMO,
>
>>>>>> but
>>>>>
>>>>>> in some cases it may be the best resort. For us (the initiative I
>>>>>> am
>>>
>>>>>> working on), I see other options such as substitution groups or
> CAM.
>>>>>> For adding additional elements, there is also the combination of
>>>>>> substitution groups and NVDL (if the additional elements are in a
>>>>>> separate namespace), or CAM.
>>>>>>
>>>>>> Joe
>>>>>>
>>>>>> Joseph Chiusano
>>>>>> Associate
>>>>>> Booz Allen Hamilton
>>>>>>
>>>>>> 700 13th St. NW, Suite 1100
>>>>>> Washington, DC 20005
>>>>>> O: 202-508-6514
>>>>>> C: 202-251-0731
>>>>>> Visit us online@ http://www.boozallen.com
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: stephen.green@systml.co.uk
>>>>>> [mailto:stephen.green@systml.co.uk]
>>>>>> Sent: Friday, May 12, 2006 3:41 PM
>>>>>> To: Chiusano Joseph
>>>>>> Cc: ubl-dev@lists.oasis-open.org
>>>>>> Subject: RE: RE: [ubl-dev] Datatype Methodology RE:
>>>>>> [ubl-dev]SBSandRestricted Data Types
>>>>>>
>>>>>> Hi Joe
>>>>>>
>>>>>> Yep I admit it - I was trying to use xsi:type with substitution
>>>>> groups.
>>>>>> Ooops. Still, the problem remains then that one can't actually use
>
>>>>>> the
>>>>>
>>>>>> substitution group to restrict the datatype since there is no
>>>>> 'abstract'
>>>>>> declaration in the original schema and no way to prevent the
>>>>>> unrestricted cbc:Name being valid in an instance. Is that correct?
>>>>>>
>>>>>> If redefine were used, how useful would xsi:type be? Not very I
>>>>>> suspect, if again the schema doesn't enforce the restriction but
>>>>>> if,
>>>
>>>>>> despite an instance using the redefined schema as the schema
>>>>>> location,
>>>>>
>>>>>> the onus is on the instance producer to decide whether the
>>>>>> restricted
>>>>
>>>>>> datatype is
>>>>>> used: after all it is the receiving system which wants the
>>>>> restriction.
>>>>>>
>>>>>> How about just redeclaring everything in a new schema, almost
>>>>>> exactly
>>>>
>>>>>> the same as the original but with the restrictions - with or
>>>>>> without
>>>
>>>>>> the same namespaces?
>>>>>>
>>>>>> Many thanks
>>>>>>
>>>>>> Steve
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Quoting Chiusano Joseph <chiusano_joseph@bah.com>:
>>>>>>
>>>>>>> Steve,
>>>>>>>
>>>>>>> Both datatypes - "cst:MyNameType" and "cbc:Name" - would be valid
>
>>>>>>> in
>>>>
>>>>>>> an instance, only in that the elements declared to be of those
>>>>>>> datatypes in the example below ("cst:CarrierName" and "cbc:Name")
>
>>>>>>> can
>>>>>
>>>>>>> both appear in instances, and "cst:CarrierName" can be
>>>>>>> substituted for
>>>>>> "cbc:Name"
>>>>>>> wherever "cbc:Name" appears. Is that what you meant by both
>>>>>>> datatypes
>>>>>
>>>>>>> would be valid in an instance?
>>>>>>>
>>>>>>> Unless my recent posting was incorrect, xsi:type is not used with
>
>>>>>>> substitution groups - which is why you may have been having the
>>>>>>> problems with tools that you mentioned below, unless you meant
>>>>>>> that
>>>
>>>>>>> you have had problems using xsi:type with redefined datatypes and
>>>>>> abstract datatypes.
>>>>>>>
>>>>>>> Joe
>>>>>>>
>>>>>>> Joseph Chiusano
>>>>>>> Associate
>>>>>>> Booz Allen Hamilton
>>>>>>>
>>>>>>> 700 13th St. NW, Suite 1100
>>>>>>> Washington, DC 20005
>>>>>>> O: 202-508-6514
>>>>>>> C: 202-251-0731
>>>>>>> Visit us online@ http://www.boozallen.com
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: stephen.green@systml.co.uk
>>>>>>> [mailto:stephen.green@systml.co.uk]
>>>>>>> Sent: Friday, May 12, 2006 3:30 AM
>>>>>>> To: Chiusano Joseph
>>>>>>> Cc: ubl-dev@lists.oasis-open.org
>>>>>>> Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev]
>>>>>>> SBSandRestricted Data Types
>>>>>>>
>>>>>>> Hi Joe
>>>>>>>
>>>>>>> But doesn't substitution groups mean that * both * datatypes
>>>>>>> would be
>>>>>
>>>>>>> valid in an instance? I so far haven't been able to get the
>>>>>>> xsi:type
>>>>
>>>>>>> method to work well with the tools I use.
>>>>>>>
>>>>>>> All the best
>>>>>>>
>>>>>>> Steve
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Quoting Chiusano Joseph <chiusano_joseph@bah.com>:
>>>>>>>
>>>>>>>> Thanks Steve. Regarding the following:
>>>>>>>>
>>>>>>>> <Quote>
>>>>>>>> The derivation looks workable: base an element on the qualified
>>>>>>>> rather
>>>>>>>
>>>>>>>> than unqualified datatype using redefine or a substitution
> group.
>>>>>>>> </Quote>
>>>>>>>>
>>>>>>>> I don't believe redefine will work here, but substitution groups
>>>>>> will.
>>>>>>>> Here's my train of though (please tell me of any derailment:)t:
>>>>>>>>
>>>>>>>> - As you mentioned, we would create a qualified data type - it
>>>>>>>> would
>>>>>
>>>>>>>> look as follows (based on cbc:NameType):
>>>>>>>>
>>>>>>>> <xsd:simpleType name="MyNameType">
>>>>>>>> <xsd:restriction base="cbc:NameType">
>>>>>>>> <xsd:maxLength value="35"/>
>>>>>>>> </xsd:restriction>
>>>>>>>> </xsd:simpleType>
>>>>>>>>
>>>>>>>> - At this point, we need to create a new element that is of
>>>>>>>> "MyNameType". I don't believe we can use redefine here, as (as
>>>>>>>> you
>>>>>>>> know) redefine means to redefine a data type. What data type
>>>>>>>> would
>>>
>>>>>>>> we
>>>>>>
>>>>>>>> redefine? If we redefined the "udt:NameType" or "cbc:NameType"
>>>>>>>> data
>>>>
>>>>>>>> types, we would have the same issue that I referred to earlier
>>>>>>>> (a ripple effect).
>>>>>>>>
>>>>>>>> - However, we could use substitution groups, as you pointed out
>>>>>>>> (but
>>>>>
>>>>>>>> knowing the dangers of using this approach, as highlighted in
>>>>>>>> the long
>>>>>>>
>>>>>>>> threads between XML-DEV and UBL-DEV X months ago asking for
>>>>>>>> input on
>>>>>
>>>>>>>> usage of substitution groups). Here is an example in which a new
>
>>>>>>>> element named "CarrierName", which is of data type
>>> "cst:MyNameType"
>>>>>>>> ("cst:" for "custom" namespace) can substitute for the head
>>>>>>>> element
>>>>>>> "cbc:Name"):
>>>>>>>>
>>>>>>>> <element name="CarrierName" type="cst:MyNameType"
>>>>>>>> substitutionGroup="cbc:Name"/>
>>>>>>>>
>>>>>>>> So "cst:CarrierName" can appear in XML documents in place of
>>>>>> cbc:Name.
>>>>>>>
>>>>>>>> I am also wondering if one can use the same name for the
>>>>>>>> substituting
>>>>>>
>>>>>>>> and head elements but different namespaces (i.e. instead of
>>>>>>>> "CarrierName", use "Name" which would be in the "custom"
>>>>>>>> namespace
>>>>>>>> -
>>>>>
>>>>>>>> I
>>>>>>>
>>>>>>>> have never tried this (will test it out).
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Joe
>>>>>>>>
>>>>>>>> Kind Regards,
>>>>>>>> Joseph Chiusano
>>>>>>>> Associate
>>>>>>>> Booz Allen Hamilton
>>>>>>>>
>>>>>>>> 700 13th St. NW, Suite 1100
>>>>>>>> Washington, DC 20005
>>>>>>>> O: 202-508-6514
>>>>>>>> C: 202-251-0731
>>>>>>>> Visit us online@ http://www.boozallen.com
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: stephen.green@systml.co.uk
>>>>>>>> [mailto:stephen.green@systml.co.uk]
>>>>>>>> Sent: Thursday, May 11, 2006 2:51 AM
>>>>>>>> To: ubl-dev@lists.oasis-open.org
>>>>>>>> Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev]
>>>>>>>> SBS andRestricted Data Types
>>>>>>>>
>>>>>>>> Joe
>>>>>>>>
>>>>>>>> Hi. Regarding the technicality of whether W3C XML Schema
>>>>>>>> derivation
>>>>
>>>>>>>> can be used to restrict the datatypes in UBL, it seems more
>>>>>>>> plausible,
>>>>>>>
>>>>>>>> looking at the examples below, that it might be allowed. The
>>>>>>>> correct
>>>>>
>>>>>>>> way to do it, I think, is to create a qualified datatype in
>>>>>>>> one's own
>>>>>>
>>>>>>>> qualified datatype schema module. I have an action item to try
>>>>>>>> this
>>>>
>>>>>>>> sort of thing as part of the quality control of the next set of
>>>>>>>> draft
>>>>>>
>>>>>>>> schemas, either during or after the coming plenary meeting in
>>>>>>> Brussels.
>>>>>>>> The derivation looks workable: base an element on the qualified
>>>>>>>> rather
>>>>>>>
>>>>>>>> than unqualified datatype using redefine or a substitution
> group.
>>>>>>>> It looks workable depending perhaps on how the qualified
>>>>>>>> datatype is
>>>>>
>>>>>>>> based on the unqualified datatype it restricts; whether it uses
>>>>>>>>
>>>>>>>>
>>>>>>>> <xsd:simpleType name="MyIndicatorType">
>>>>>>>> <xsd:restriction base="xsd:boolean">
>>>>>>>> <xsd:pattern value="true"/>
>>>>>>>> </xsd:restriction>
>>>>>>>> </xsd:simpleType>
>>>>>>>>
>>>>>>>> or
>>>>>>>>
>>>>>>>> <xsd:simpleType name="MyIndicatorType">
>>>>>>>> <xsd:restriction base="udt:IndicatorType">
>>>>>>>> <xsd:pattern value="true"/>
>>>>>>>> </xsd:restriction>
>>>>>>>> </xsd:simpleType>
>>>>>>>>
>>>>>>>> All the best
>>>>>>>>
>>>>>>>> Stephen Green
>>>>>>>>
>>>>>>>> Quoting stephen.green@systml.co.uk:
>>>>>>>>
>>>>>>>>> Hi Joe,
>>>>>>>>>
>>>>>>>>> For example in UBL 1.0 we have the unqualified datatype
>>>>> 'AmountType'
>>>>>>>>>
>>>>>>>>> <xsd:complexType name="AmountType">
>>>>>>>>> <xsd:simpleContent>
>>>>>>>>> <xsd:restriction base="cct:AmountType">
>>>>>>>>> <xsd:attribute
> name="amountCurrencyID"
>>>>>>>> type="xsd:normalizedString"
>>>>>>>>> use="required"/>
>>>>>>>>> <xsd:attribute
>>>>>>>> name="amountCurrencyCodeListVersionID"
>>>>>>>>> type="xsd:normalizedString" use="optional"/>
>>>>>>>>> </xsd:restriction>
>>>>>>>>> </xsd:simpleContent>
>>>>>>>>> </xsd:complexType>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> and a corresponding restriction of that UBLAmount which, since
>>>>>>>>> it
>>>
>>>>>>>>> is
>>>>>>
>>>>>>>>> based on the unqualified datatype and a restriction of the
>>>>>>>>> same, would
>>>>>>>>
>>>>>>>>> now be called a 'qualified datatype' but was, in UBL 1.0, then
>>>>>>>>> called
>>>>>>>
>>>>>>>>> a 'specialized datatype'
>>>>>>>>>
>>>>>>>>> <xsd:complexType name="UBLAmountType">
>>>>>>>>> <xsd:simpleContent>
>>>>>>>>> <xsd:restriction base="udt:AmountType">
>>>>>>>>> <xsd:attribute
> name="amountCurrencyID"
>>>>>>>> type="cur:CurrencyCodeContentType"
>>>>>>>>> use="required"/>
>>>>>>>>> <xsd:attribute
>>>>>>>> name="amountCurrencyCodeListVersionID"
>>>>>>>>> type="xsd:normalizedString" use="optional" fixed="0.3"/>
>>>>>>>>> </xsd:restriction>
>>>>>>>>> </xsd:simpleContent>
>>>>>>>>> </xsd:complexType>
>>>>>>>>>
>>>>>>>>> In this case the main restriction is that the amountCurrencyID
>>>>>>>>> is
>>>
>>>>>>>>> limited to the one codelist (which is the ISO currency
>>>>>>>>> codelist) but
>>>>>>
>>>>>>>>> the value of the amountCurrencyCodeListVersionID attribute is
>>>>>>>>> also
>>>>>>>> restricted to '0.3'.
>>>>>>>>>
>>>>>>>>> [At the risk of confusing folk, I'd note that in UBL 2 the
>>>>>>>>> Amount
>>>
>>>>>>>>> is
>>>>>>
>>>>>>>>> itself restricted to having the ISO currency codelist as
>>>>>>>>> implemented
>>>>>>
>>>>>>>>> by CEFACT's ATG2 so there is no need for the qualified
>>>>>>>>> datatype.]
>>>>>>>>>
>>>>>>>>> A simpler example, though fictional, would be that if there was
>
>>>>>>>>> a
>>>
>>>>>>>>> need
>>>>>>>>
>>>>>>>>> for a boolean that could only be true, one would have to
>>>>>>>>> restrict
>>>
>>>>>>>>> the
>>>>>>>
>>>>>>>>> unqualified Indicator datatype which has a restriction to
> 'true'
>>>>>>>>> and
>>>>>>>> 'false'
>>>>>>>>> and base the new datatype on that Indicator, giving it new name
>
>>>>>>>>> perhaps (though it would get a new namespace anyway) and
>>>>>>>>> restricting
>>>>>>
>>>>>>>>> it to 'true' only.
>>>>>>>>> In UBL 2 prd there is the ATG2 schema
>>>>>>>> 'UnqualifiedDataTypeSchemaModule-2.xsd'
>>>>>>>>> with an Indicator type
>>>>>>>>>
>>>>>>>>> <xsd:simpleType name="IndicatorType">
>>>>>>>>> <!-- documentation removed -->
>>>>>>>>> <xsd:restriction base="xsd:boolean">
>>>>>>>>> <xsd:pattern value="false"/>
>>>>>>>>> <xsd:pattern value="true"/>
>>>>>>>>> </xsd:restriction>
>>>>>>>>> </xsd:simpleType>
>>>>>>>>>
>>>>>>>>> A corresponding, restricted, qualified datatype might therefore
>
>>>>>>>>> be
>>>>>>>>>
>>>>>>>>> <xsd:simpleType name="MyIndicatorType">
>>>>>>>>> <xsd:restriction base="xsd:boolean">
>>>>>>>>> <xsd:pattern value="true"/>
>>>>>>>>> </xsd:restriction>
>>>>>>>>> </xsd:simpleType>
>>>>>>>>>
>>>>>>>>> or
>>>>>>>>>
>>>>>>>>> <xsd:simpleType name="MyIndicatorType">
>>>>>>>>> <xsd:restriction base="udt:IndicatorType">
>>>>>>>>> <xsd:pattern value="true"/>
>>>>>>>>> </xsd:restriction>
>>>>>>>>> </xsd:simpleType>
>>>>>>>>>
>>>>>>>>> (I'm not yet certain which of the above is most correct -
>>>>>>>>> perhaps
>>>
>>>>>>>>> it
>>>>>>
>>>>>>>>> is a matter of interpretation of the CCTS.)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> All the best
>>>>>>>>>
>>>>>>>>> Steve
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Quoting Chiusano Joseph <chiusano_joseph@bah.com>:
>>>>>>>>>
>>>>>>>>>> Thanks Steve. Please remind me again what a "qualified"
>>>>>>>>>> datatype
>>>
>>>>>>>>>> would be? Would it be, for example, a data type whose name
>>>>>>>>>> (and
>>>>>>>>>> definition) reflects the restriction that we are speaking of?
>>>>>>>>>> So
>>>
>>>>>>>>>> for
>>>>>>>
>>>>>>>>>> example, instead of the unqualified "IdentifierType", we would
>
>>>>>>>>>> have
>>>>>>
>>>>>>>>>> an identifier type that has a pattern restriction and it would
>
>>>>>>>>>> be
>>>>
>>>>>>>>>> called "SSNIdentifierType"?
>>>>>>>>>>
>>>>>>>>>> Joe
>>>>>>>>>>
>>>>>>>>>> Joseph Chiusano
>>>>>>>>>> Associate
>>>>>>>>>> Booz Allen Hamilton
>>>>>>>>>>
>>>>>>>>>> 700 13th St. NW, Suite 1100
>>>>>>>>>> Washington, DC 20005
>>>>>>>>>> O: 202-508-6514
>>>>>>>>>> C: 202-251-0731
>>>>>>>>>> Visit us online@ http://www.boozallen.com
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: stephen.green@systml.co.uk
>>>>>>>>>> [mailto:stephen.green@systml.co.uk]
>>>>>>>>>> Sent: Wednesday, May 10, 2006 5:38 PM
>>>>>>>>>> To: ubl-dev@lists.oasis-open.org
>>>>>>>>>> Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev]
>>>>>>>>>> SBS
>>>>
>>>>>>>>>> and
>>>>>>>>
>>>>>>>>>> Restricted Data Types
>>>>>>>>>>
>>>>>>>>>> Hi Joe
>>>>>>>>>>
>>>>>>>>>> Absolutely. Sorry, I'd forgotten this and it isn't all that
>>>>>> obvious.
>>>>>>>>>> The thing is that the datatypes UBL uses are mostly what the
>>>>>>>>>> CCTS
>>>>
>>>>>>>>>> calls unqualified. To redefine them one really (as,
>>>>>>>>>> thankfully, Mark
>>>>>>>
>>>>>>>>>> Crawford explained earlier) has to create new datatypes based
>>>>>>>>>> on
>>>
>>>>>>>>>> them
>>>>>>>>
>>>>>>>>>> which are called qualified datatypes. The element based at
>>>>>>>>>> present
>>>>>
>>>>>>>>>> on
>>>>>>>>
>>>>>>>>>> the unqualified datatype would have to somehow be replaced, I
>>>>>>>>>> think,
>>>>>>>
>>>>>>>>>> not being able to see how to do it any other way, with a new
>>>>>>>>>> element
>>>>>>>
>>>>>>>>>> based on the restricted qualified datatype. To my mind it
>>>>>>>>>> needs a
>>>>
>>>>>>>>>> new
>>>>>>>>
>>>>>>>>>> element and a restricting out of the old element, rather than
>>>>>>>>>> a redefine of the old element. I can't see how to do the
>>>>>>>>>> latter with
>>>>>>>> XSD derivation.
>>>>>>>>>> If an element was based on a UBL-qualified datatype then
>>>>>>>>>> maybe, since
>>>>>>>>
>>>>>>>>>> it would be under UBL control as it were, one could use XSD
>>>>>>>>>> redefine
>>>>>>>
>>>>>>>>>> to restrict it. That is interesting. It may mean that
>>>>>>>>>> restriction
>>>>
>>>>>>>>>> is
>>>>>>>
>>>>>>>>>> limited by use of an unqualified datatype, especially when
>>>>>>>>>> CCTS (and
>>>>>>>>>> UBL) compliance is required.
>>>>>>>>>> I think the same applies to the XSD substitution group method.
>>>>>>>>>>
>>>>>>>>>> All the best
>>>>>>>>>>
>>>>>>>>>> Stephen Green
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Quoting Chiusano Joseph <chiusano_joseph@bah.com>:
>>>>>>>>>>
>>>>>>>>>>> P.S. Regarding xsd:redefine: A redefine of this element
>>>>>>>>>>> (Carrier
>>>>
>>>>>>>>>>> Name,
>>>>>>>>>>
>>>>>>>>>>> represented as cbc:Name) does not seem possible (unless my
>>>>>>>>>>> dusting
>>>>>>
>>>>>>>>>>> off
>>>>>>>>>>
>>>>>>>>>>> of the xsd:redefine feature brings misunderstanding with it),
>
>>>>>>>>>>> as
>>>>
>>>>>>>>>>> one
>>>>>>>>
>>>>>>>>>>> would need to redefine its type, which is cbc:NameType, to
>>>>>>>>>>> have
>>>
>>>>>>>>>>> a
>>>>>
>>>>>>>>>>> max of
>>>>>>>>>>> 35 characters rather than an unlimited number.
>>>>>>>>>>>
>>>>>>>>>>> However, this would cause a ripple effect across all other
>>>>>>>>>>> references to the cbc:Name element within the Despatch Advice
>
>>>>>>>>>>> schema
>>>>>>>>
>>>>>>>>>>> (through references within the Common Aggregate Components
>>>>>>>>>>> schema),
>>>>>>>
>>>>>>>>>>> which would
>>>>>>>>>>
>>>>>>>>>>> in effect cause all other cbc:Name elements to be a max of 35
>
>>>>>>>>>>> characters. This may or may not be the desired outcome - even
>
>>>>>>>>>>> if
>>>>
>>>>>>>>>>> by
>>>>>>>
>>>>>>>>>>> chance all should be 35 characters, this of course will not
>>>>>>>>>>> always
>>>>>>
>>>>>>>>>>> be the case.
>>>>>>>>>>>
>>>>>>>>>>> So unless I am missing something (which someone will tell me
>>>>>>>>>>> I am
>>>>>
>>>>>>>>>>> sure:), the xsd:redefine feature will not work in this case.
>>>>>>>>>>> All
>>>>
>>>>>>>>>>> the
>>>>>>>>
>>>>>>>>>>> more reason we need alternate approaches.
>>>>>>>>>>>
>>>>>>>>>>> Joe
>>>>>>>>>>>
>>>>>>>>>>> Joseph Chiusano
>>>>>>>>>>> Associate
>>>>>>>>>>> Booz Allen Hamilton
>>>>>>>>>>>
>>>>>>>>>>> 700 13th St. NW, Suite 1100
>>>>>>>>>>> Washington, DC 20005
>>>>>>>>>>> O: 202-508-6514
>>>>>>>>>>> C: 202-251-0731
>>>>>>>>>>> Visit us online@ http://www.boozallen.com
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
>>>>>>>>>>> Sent: Wednesday, May 10, 2006 3:41 PM
>>>>>>>>>>> To: David RR Webber (XML); Stephen Green
>>>>>>>>>>> Cc: ubl-dev@lists.oasis-open.org
>>>>>>>>>>> Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev]
>
>>>>>>>>>>> SBS
>>>>>
>>>>>>>>>>> and Restricted Data Types
>>>>>>>>>>>
>>>>>>>>>>> David,
>>>>>>>>>>>
>>>>>>>>>>> Thinking more about CAM here: How efficient and
>>>>>>>>>>> straightforward
>>>
>>>>>>>>>>> would it be to restrict the data type of - picking a schema
>>>>>>>>>>> and
>>>
>>>>>>>>>>> element completely at random here - the Carrier Name element
>>>>>>>>>>> in
>>>
>>>>>>>>>>> the
>>>>>>>
>>>>>>>>>>> UBL 2.0 Despatch Advice schema to, say, a maximum of 35
>>>>>> characters?
>>>>>>>>>>>
>>>>>>>>>>> Here is the path to that element:
>>>>>>>>>>> DespatchAdvice/Shipment/Consignment/CarrierParty/PartyName/Na
>>>>>>>>>>> me
>>>>>>>>>>>
>>>>>>>>>>> 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]