[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: RE: [ubl-dev] Datatype MethodologyRE:[ubl-dev]SBSandRestrictedData Types
But if one wanted to use substitution groups with UBL
wouldn't one have to import the UBL schemas into a
schema with a new namespace?
Steve
Quoting Chiusano Joseph <chiusano_joseph@bah.com>:
> Actually, with substitution groups you're not required to change the
> namespace, though you could. That is, the substituting and head elements
> may be in the same namespace, or different namespaces.
>
> Here is the example from the W3C Schema 1.0 Primer, where element
> "ipo:shipComment" can substitute for head element "ipo:comment":
>
> <element name="shipComment" type="string"
> substitutionGroup="ipo:comment"/>
> <element name="customerComment" type="string"
> substitutionGroup="ipo:comment"/>
>
> And the corresponding XML instance example:
>
> ....
> <items>
> <item partNum="833-AA">
> <productName>Lapis necklace</productName>
> <quantity>1</quantity>
> <USPrice>99.95</USPrice>
> <ipo:shipComment>
> Use gold wrap if possible
> </ipo:shipComment>
> <ipo:customerComment>
> Want this for the holidays!
> </ipo:customerComment>
> <shipDate>1999-12-05</shipDate>
> </item>
> </items>
> ....
>
> Joe
>
> Joseph Chiusano
> Associate
> Booz Allen Hamilton
>
> 700 13th St. NW, Suite 1100
> Washington, DC 20005
> O: 202-508-6514
> C: 202-251-0731
> Visit us online@ http://www.boozallen.com
>
> -----Original Message-----
> From: stephen.green@systml.co.uk [mailto:stephen.green@systml.co.uk]
> Sent: Friday, May 12, 2006 5:14 PM
> To: Chiusano Joseph
> Cc: ubl-dev@lists.oasis-open.org
> Subject: RE: RE: [ubl-dev] Datatype
> MethodologyRE:[ubl-dev]SBSandRestricted Data Types
>
> Hey - but then you have to change the namespace - and is the benefit (is
> there a clear one?) worth that? However, with Schematron together with
> the original schemas one doesn't have to change the namespace and there
> are more options of what one can call valid or invalid or anything in
> between (as with the SBS where UBL/non-subset elements are still valid
> but flagged).
>
> All the best
>
> Steve
>
>
> Quoting Chiusano Joseph <chiusano_joseph@bah.com>:
>
>> Ah - now the bottom line. I believe I may have talked myself out of
>> substitution groups as a preferred approach - at least using
>> substitution groups alone. Instead I've relegated them to being a
>> "possible" approach. The only (or at least primary) reason for this is
>
>> the issue we have been mentioning, which is that there is no facility
>> within W3C Schema to control which occurrences of a head element can
>> be substituted with the new element. So one needs to enforce this
>> outside of W3C Schema, which can be done using Schematron assertions.
>> However, using substitution groups along with Schematron assertions
>> might not be such a bad thing.
>>
>> So bottom line, substitution groups may be risky to use without
>> additional verification abilities, which can be provided by
> Schematron.
>>
>> Joe
>>
>> Joseph Chiusano
>> Associate
>> Booz Allen Hamilton
>>
>> 700 13th St. NW, Suite 1100
>> Washington, DC 20005
>> O: 202-508-6514
>> C: 202-251-0731
>> Visit us online@ http://www.boozallen.com
>>
>> -----Original Message-----
>> From: stephen.green@systml.co.uk [mailto:stephen.green@systml.co.uk]
>> Sent: Friday, May 12, 2006 4:27 PM
>> To: Chiusano Joseph
>> Cc: ubl-dev@lists.oasis-open.org
>> Subject: RE: RE: [ubl-dev] Datatype Methodology
>> RE:[ubl-dev]SBSandRestricted Data Types
>>
>> Joe,
>>
>> Any chance you could say how substitution groups might be useful in
>> your situation?
>>
>> All the best
>>
>> Steve
>>
>>
>> Quoting Chiusano Joseph <chiusano_joseph@bah.com>:
>>
>>> Oops, meant to answer the rest of the questions:
>>>
>>> <Quote>
>>> If redefine were used, how useful would xsi:type be? Not very I
>>> suspect, if again the schema doesn't enforce the restriction but if,
>>> despite an instance using the redefined schema as the schema
>>> location,
>>
>>> the onus is on the instance producer to decide whether the restricted
>
>>> datatype is
>>> used: after all it is the receiving system which wants the
>> restriction.
>>> </Quote>
>>>
>>> I believe xsi:type is required for redefine, not optional - so I
>>> believe it's beyond the question of it being useful (though opinions
>>> on this are valid of course). The onus indeed is on the instance
>>> producer to decide whether the restricted datatype is used - which of
>
>>> course adds additional complexity to producing the instance (and a
>>> margin for error by specifying the incorrect xsi:type value).
>>>
>>> <Quote>
>>> How about just redeclaring everything in a new schema, almost exactly
>
>>> the same as the original but with the restrictions - with or without
>>> the same namespaces?
>>> </Quote>
>>>
>>> Always an option - not necessarily good for interoperability, IMO,
>>> but
>>
>>> in some cases it may be the best resort. For us (the initiative I am
>>> working on), I see other options such as substitution groups or CAM.
>>> For adding additional elements, there is also the combination of
>>> substitution groups and NVDL (if the additional elements are in a
>>> separate namespace), or CAM.
>>>
>>> Joe
>>>
>>> Joseph Chiusano
>>> Associate
>>> Booz Allen Hamilton
>>>
>>> 700 13th St. NW, Suite 1100
>>> Washington, DC 20005
>>> O: 202-508-6514
>>> C: 202-251-0731
>>> Visit us online@ http://www.boozallen.com
>>>
>>> -----Original Message-----
>>> From: stephen.green@systml.co.uk [mailto:stephen.green@systml.co.uk]
>>> Sent: Friday, May 12, 2006 3:41 PM
>>> To: Chiusano Joseph
>>> Cc: ubl-dev@lists.oasis-open.org
>>> Subject: RE: RE: [ubl-dev] Datatype Methodology RE:
>>> [ubl-dev]SBSandRestricted Data Types
>>>
>>> Hi Joe
>>>
>>> Yep I admit it - I was trying to use xsi:type with substitution
>> groups.
>>> Ooops. Still, the problem remains then that one can't actually use
>>> the
>>
>>> substitution group to restrict the datatype since there is no
>> 'abstract'
>>> declaration in the original schema and no way to prevent the
>>> unrestricted cbc:Name being valid in an instance. Is that correct?
>>>
>>> If redefine were used, how useful would xsi:type be? Not very I
>>> suspect, if again the schema doesn't enforce the restriction but if,
>>> despite an instance using the redefined schema as the schema
>>> location,
>>
>>> the onus is on the instance producer to decide whether the restricted
>
>>> datatype is
>>> used: after all it is the receiving system which wants the
>> restriction.
>>>
>>> How about just redeclaring everything in a new schema, almost exactly
>
>>> the same as the original but with the restrictions - with or without
>>> the same namespaces?
>>>
>>> Many thanks
>>>
>>> Steve
>>>
>>>
>>>
>>>
>>> Quoting Chiusano Joseph <chiusano_joseph@bah.com>:
>>>
>>>> Steve,
>>>>
>>>> Both datatypes - "cst:MyNameType" and "cbc:Name" - would be valid in
>
>>>> an instance, only in that the elements declared to be of those
>>>> datatypes in the example below ("cst:CarrierName" and "cbc:Name")
>>>> can
>>
>>>> both appear in instances, and "cst:CarrierName" can be substituted
>>>> for
>>> "cbc:Name"
>>>> wherever "cbc:Name" appears. Is that what you meant by both
>>>> datatypes
>>
>>>> would be valid in an instance?
>>>>
>>>> Unless my recent posting was incorrect, xsi:type is not used with
>>>> substitution groups - which is why you may have been having the
>>>> problems with tools that you mentioned below, unless you meant that
>>>> you have had problems using xsi:type with redefined datatypes and
>>> abstract datatypes.
>>>>
>>>> Joe
>>>>
>>>> Joseph Chiusano
>>>> Associate
>>>> Booz Allen Hamilton
>>>>
>>>> 700 13th St. NW, Suite 1100
>>>> Washington, DC 20005
>>>> O: 202-508-6514
>>>> C: 202-251-0731
>>>> Visit us online@ http://www.boozallen.com
>>>>
>>>> -----Original Message-----
>>>> From: stephen.green@systml.co.uk [mailto:stephen.green@systml.co.uk]
>>>> Sent: Friday, May 12, 2006 3:30 AM
>>>> To: Chiusano Joseph
>>>> Cc: ubl-dev@lists.oasis-open.org
>>>> Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev]
>>>> SBSandRestricted Data Types
>>>>
>>>> Hi Joe
>>>>
>>>> But doesn't substitution groups mean that * both * datatypes would
>>>> be
>>
>>>> valid in an instance? I so far haven't been able to get the xsi:type
>
>>>> method to work well with the tools I use.
>>>>
>>>> All the best
>>>>
>>>> Steve
>>>>
>>>>
>>>>
>>>> Quoting Chiusano Joseph <chiusano_joseph@bah.com>:
>>>>
>>>>> Thanks Steve. Regarding the following:
>>>>>
>>>>> <Quote>
>>>>> The derivation looks workable: base an element on the qualified
>>>>> rather
>>>>
>>>>> than unqualified datatype using redefine or a substitution group.
>>>>> </Quote>
>>>>>
>>>>> I don't believe redefine will work here, but substitution groups
>>> will.
>>>>> Here's my train of though (please tell me of any derailment:)t:
>>>>>
>>>>> - As you mentioned, we would create a qualified data type - it
>>>>> would
>>
>>>>> look as follows (based on cbc:NameType):
>>>>>
>>>>> <xsd:simpleType name="MyNameType">
>>>>> <xsd:restriction base="cbc:NameType">
>>>>> <xsd:maxLength value="35"/>
>>>>> </xsd:restriction>
>>>>> </xsd:simpleType>
>>>>>
>>>>> - At this point, we need to create a new element that is of
>>>>> "MyNameType". I don't believe we can use redefine here, as (as you
>>>>> know) redefine means to redefine a data type. What data type would
>>>>> we
>>>
>>>>> redefine? If we redefined the "udt:NameType" or "cbc:NameType" data
>
>>>>> types, we would have the same issue that I referred to earlier (a
>>>>> ripple effect).
>>>>>
>>>>> - However, we could use substitution groups, as you pointed out
>>>>> (but
>>
>>>>> knowing the dangers of using this approach, as highlighted in the
>>>>> long
>>>>
>>>>> threads between XML-DEV and UBL-DEV X months ago asking for input
>>>>> on
>>
>>>>> usage of substitution groups). Here is an example in which a new
>>>>> element named "CarrierName", which is of data type "cst:MyNameType"
>>>>> ("cst:" for "custom" namespace) can substitute for the head element
>>>> "cbc:Name"):
>>>>>
>>>>> <element name="CarrierName" type="cst:MyNameType"
>>>>> substitutionGroup="cbc:Name"/>
>>>>>
>>>>> So "cst:CarrierName" can appear in XML documents in place of
>>> cbc:Name.
>>>>
>>>>> I am also wondering if one can use the same name for the
>>>>> substituting
>>>
>>>>> and head elements but different namespaces (i.e. instead of
>>>>> "CarrierName", use "Name" which would be in the "custom" namespace
>>>>> -
>>
>>>>> I
>>>>
>>>>> have never tried this (will test it out).
>>>>>
>>>>> Thanks,
>>>>> Joe
>>>>>
>>>>> Kind Regards,
>>>>> Joseph Chiusano
>>>>> Associate
>>>>> Booz Allen Hamilton
>>>>>
>>>>> 700 13th St. NW, Suite 1100
>>>>> Washington, DC 20005
>>>>> O: 202-508-6514
>>>>> C: 202-251-0731
>>>>> Visit us online@ http://www.boozallen.com
>>>>>
>>>>> -----Original Message-----
>>>>> From: stephen.green@systml.co.uk
>>>>> [mailto:stephen.green@systml.co.uk]
>>>>> Sent: Thursday, May 11, 2006 2:51 AM
>>>>> To: ubl-dev@lists.oasis-open.org
>>>>> Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS
>>>>> andRestricted Data Types
>>>>>
>>>>> Joe
>>>>>
>>>>> Hi. Regarding the technicality of whether W3C XML Schema derivation
>
>>>>> can be used to restrict the datatypes in UBL, it seems more
>>>>> plausible,
>>>>
>>>>> looking at the examples below, that it might be allowed. The
>>>>> correct
>>
>>>>> way to do it, I think, is to create a qualified datatype in one's
>>>>> own
>>>
>>>>> qualified datatype schema module. I have an action item to try this
>
>>>>> sort of thing as part of the quality control of the next set of
>>>>> draft
>>>
>>>>> schemas, either during or after the coming plenary meeting in
>>>> Brussels.
>>>>> The derivation looks workable: base an element on the qualified
>>>>> rather
>>>>
>>>>> than unqualified datatype using redefine or a substitution group.
>>>>> It looks workable depending perhaps on how the qualified datatype
>>>>> is
>>
>>>>> based on the unqualified datatype it restricts; whether it uses
>>>>>
>>>>>
>>>>> <xsd:simpleType name="MyIndicatorType">
>>>>> <xsd:restriction base="xsd:boolean">
>>>>> <xsd:pattern value="true"/>
>>>>> </xsd:restriction>
>>>>> </xsd:simpleType>
>>>>>
>>>>> or
>>>>>
>>>>> <xsd:simpleType name="MyIndicatorType">
>>>>> <xsd:restriction base="udt:IndicatorType">
>>>>> <xsd:pattern value="true"/>
>>>>> </xsd:restriction>
>>>>> </xsd:simpleType>
>>>>>
>>>>> All the best
>>>>>
>>>>> Stephen Green
>>>>>
>>>>> Quoting stephen.green@systml.co.uk:
>>>>>
>>>>>> Hi Joe,
>>>>>>
>>>>>> For example in UBL 1.0 we have the unqualified datatype
>> 'AmountType'
>>>>>>
>>>>>> <xsd:complexType name="AmountType">
>>>>>> <xsd:simpleContent>
>>>>>> <xsd:restriction base="cct:AmountType">
>>>>>> <xsd:attribute name="amountCurrencyID"
>>>>> type="xsd:normalizedString"
>>>>>> use="required"/>
>>>>>> <xsd:attribute
>>>>> name="amountCurrencyCodeListVersionID"
>>>>>> type="xsd:normalizedString" use="optional"/>
>>>>>> </xsd:restriction>
>>>>>> </xsd:simpleContent>
>>>>>> </xsd:complexType>
>>>>>>
>>>>>>
>>>>>> and a corresponding restriction of that UBLAmount which, since it
>>>>>> is
>>>
>>>>>> based on the unqualified datatype and a restriction of the same,
>>>>>> would
>>>>>
>>>>>> now be called a 'qualified datatype' but was, in UBL 1.0, then
>>>>>> called
>>>>
>>>>>> a 'specialized datatype'
>>>>>>
>>>>>> <xsd:complexType name="UBLAmountType">
>>>>>> <xsd:simpleContent>
>>>>>> <xsd:restriction base="udt:AmountType">
>>>>>> <xsd:attribute name="amountCurrencyID"
>>>>> type="cur:CurrencyCodeContentType"
>>>>>> use="required"/>
>>>>>> <xsd:attribute
>>>>> name="amountCurrencyCodeListVersionID"
>>>>>> type="xsd:normalizedString" use="optional" fixed="0.3"/>
>>>>>> </xsd:restriction>
>>>>>> </xsd:simpleContent>
>>>>>> </xsd:complexType>
>>>>>>
>>>>>> In this case the main restriction is that the amountCurrencyID is
>>>>>> limited to the one codelist (which is the ISO currency codelist)
>>>>>> but
>>>
>>>>>> the value of the amountCurrencyCodeListVersionID attribute is also
>>>>> restricted to '0.3'.
>>>>>>
>>>>>> [At the risk of confusing folk, I'd note that in UBL 2 the Amount
>>>>>> is
>>>
>>>>>> itself restricted to having the ISO currency codelist as
>>>>>> implemented
>>>
>>>>>> by CEFACT's ATG2 so there is no need for the qualified datatype.]
>>>>>>
>>>>>> A simpler example, though fictional, would be that if there was a
>>>>>> need
>>>>>
>>>>>> for a boolean that could only be true, one would have to restrict
>>>>>> the
>>>>
>>>>>> unqualified Indicator datatype which has a restriction to 'true'
>>>>>> and
>>>>> 'false'
>>>>>> and base the new datatype on that Indicator, giving it new name
>>>>>> perhaps (though it would get a new namespace anyway) and
>>>>>> restricting
>>>
>>>>>> it to 'true' only.
>>>>>> In UBL 2 prd there is the ATG2 schema
>>>>> 'UnqualifiedDataTypeSchemaModule-2.xsd'
>>>>>> with an Indicator type
>>>>>>
>>>>>> <xsd:simpleType name="IndicatorType">
>>>>>> <!-- documentation removed -->
>>>>>> <xsd:restriction base="xsd:boolean">
>>>>>> <xsd:pattern value="false"/>
>>>>>> <xsd:pattern value="true"/>
>>>>>> </xsd:restriction>
>>>>>> </xsd:simpleType>
>>>>>>
>>>>>> A corresponding, restricted, qualified datatype might therefore be
>>>>>>
>>>>>> <xsd:simpleType name="MyIndicatorType">
>>>>>> <xsd:restriction base="xsd:boolean">
>>>>>> <xsd:pattern value="true"/>
>>>>>> </xsd:restriction>
>>>>>> </xsd:simpleType>
>>>>>>
>>>>>> or
>>>>>>
>>>>>> <xsd:simpleType name="MyIndicatorType">
>>>>>> <xsd:restriction base="udt:IndicatorType">
>>>>>> <xsd:pattern value="true"/>
>>>>>> </xsd:restriction>
>>>>>> </xsd:simpleType>
>>>>>>
>>>>>> (I'm not yet certain which of the above is most correct - perhaps
>>>>>> it
>>>
>>>>>> is a matter of interpretation of the CCTS.)
>>>>>>
>>>>>>
>>>>>> All the best
>>>>>>
>>>>>> Steve
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Quoting Chiusano Joseph <chiusano_joseph@bah.com>:
>>>>>>
>>>>>>> Thanks Steve. Please remind me again what a "qualified" datatype
>>>>>>> would be? Would it be, for example, a data type whose name (and
>>>>>>> definition) reflects the restriction that we are speaking of? So
>>>>>>> for
>>>>
>>>>>>> example, instead of the unqualified "IdentifierType", we would
>>>>>>> have
>>>
>>>>>>> an identifier type that has a pattern restriction and it would be
>
>>>>>>> called "SSNIdentifierType"?
>>>>>>>
>>>>>>> Joe
>>>>>>>
>>>>>>> Joseph Chiusano
>>>>>>> Associate
>>>>>>> Booz Allen Hamilton
>>>>>>>
>>>>>>> 700 13th St. NW, Suite 1100
>>>>>>> Washington, DC 20005
>>>>>>> O: 202-508-6514
>>>>>>> C: 202-251-0731
>>>>>>> Visit us online@ http://www.boozallen.com
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: stephen.green@systml.co.uk
>>>>>>> [mailto:stephen.green@systml.co.uk]
>>>>>>> Sent: Wednesday, May 10, 2006 5:38 PM
>>>>>>> To: ubl-dev@lists.oasis-open.org
>>>>>>> Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS
>
>>>>>>> and
>>>>>
>>>>>>> Restricted Data Types
>>>>>>>
>>>>>>> Hi Joe
>>>>>>>
>>>>>>> Absolutely. Sorry, I'd forgotten this and it isn't all that
>>> obvious.
>>>>>>> The thing is that the datatypes UBL uses are mostly what the CCTS
>
>>>>>>> calls unqualified. To redefine them one really (as, thankfully,
>>>>>>> Mark
>>>>
>>>>>>> Crawford explained earlier) has to create new datatypes based on
>>>>>>> them
>>>>>
>>>>>>> which are called qualified datatypes. The element based at
>>>>>>> present
>>
>>>>>>> on
>>>>>
>>>>>>> the unqualified datatype would have to somehow be replaced, I
>>>>>>> think,
>>>>
>>>>>>> not being able to see how to do it any other way, with a new
>>>>>>> element
>>>>
>>>>>>> based on the restricted qualified datatype. To my mind it needs a
>
>>>>>>> new
>>>>>
>>>>>>> element and a restricting out of the old element, rather than a
>>>>>>> redefine of the old element. I can't see how to do the latter
>>>>>>> with
>>>>> XSD derivation.
>>>>>>> If an element was based on a UBL-qualified datatype then maybe,
>>>>>>> since
>>>>>
>>>>>>> it would be under UBL control as it were, one could use XSD
>>>>>>> redefine
>>>>
>>>>>>> to restrict it. That is interesting. It may mean that restriction
>
>>>>>>> is
>>>>
>>>>>>> limited by use of an unqualified datatype, especially when CCTS
>>>>>>> (and
>>>>>>> UBL) compliance is required.
>>>>>>> I think the same applies to the XSD substitution group method.
>>>>>>>
>>>>>>> All the best
>>>>>>>
>>>>>>> Stephen Green
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Quoting Chiusano Joseph <chiusano_joseph@bah.com>:
>>>>>>>
>>>>>>>> P.S. Regarding xsd:redefine: A redefine of this element (Carrier
>
>>>>>>>> Name,
>>>>>>>
>>>>>>>> represented as cbc:Name) does not seem possible (unless my
>>>>>>>> dusting
>>>
>>>>>>>> off
>>>>>>>
>>>>>>>> of the xsd:redefine feature brings misunderstanding with it), as
>
>>>>>>>> one
>>>>>
>>>>>>>> would need to redefine its type, which is cbc:NameType, to have
>>>>>>>> a
>>
>>>>>>>> max of
>>>>>>>> 35 characters rather than an unlimited number.
>>>>>>>>
>>>>>>>> However, this would cause a ripple effect across all other
>>>>>>>> references to the cbc:Name element within the Despatch Advice
>>>>>>>> schema
>>>>>
>>>>>>>> (through references within the Common Aggregate Components
>>>>>>>> schema),
>>>>
>>>>>>>> which would
>>>>>>>
>>>>>>>> in effect cause all other cbc:Name elements to be a max of 35
>>>>>>>> characters. This may or may not be the desired outcome - even if
>
>>>>>>>> by
>>>>
>>>>>>>> chance all should be 35 characters, this of course will not
>>>>>>>> always
>>>
>>>>>>>> be the case.
>>>>>>>>
>>>>>>>> So unless I am missing something (which someone will tell me I
>>>>>>>> am
>>
>>>>>>>> sure:), the xsd:redefine feature will not work in this case. All
>
>>>>>>>> the
>>>>>
>>>>>>>> more reason we need alternate approaches.
>>>>>>>>
>>>>>>>> Joe
>>>>>>>>
>>>>>>>> Joseph Chiusano
>>>>>>>> Associate
>>>>>>>> Booz Allen Hamilton
>>>>>>>>
>>>>>>>> 700 13th St. NW, Suite 1100
>>>>>>>> Washington, DC 20005
>>>>>>>> O: 202-508-6514
>>>>>>>> C: 202-251-0731
>>>>>>>> Visit us online@ http://www.boozallen.com
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
>>>>>>>> Sent: Wednesday, May 10, 2006 3:41 PM
>>>>>>>> To: David RR Webber (XML); Stephen Green
>>>>>>>> Cc: ubl-dev@lists.oasis-open.org
>>>>>>>> Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev]
>>>>>>>> SBS
>>
>>>>>>>> and Restricted Data Types
>>>>>>>>
>>>>>>>> David,
>>>>>>>>
>>>>>>>> Thinking more about CAM here: How efficient and straightforward
>>>>>>>> would it be to restrict the data type of - picking a schema and
>>>>>>>> element completely at random here - the Carrier Name element in
>>>>>>>> the
>>>>
>>>>>>>> UBL 2.0 Despatch Advice schema to, say, a maximum of 35
>>> characters?
>>>>>>>>
>>>>>>>> Here is the path to that element:
>>>>>>>> DespatchAdvice/Shipment/Consignment/CarrierParty/PartyName/Name
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Joe
>>>>>>>>
>>>>>>>> Joseph Chiusano
>>>>>>>> Associate
>>>>>>>> Booz Allen Hamilton
>>>>>>>>
>>>>>>>> 700 13th St. NW, Suite 1100
>>>>>>>> Washington, DC 20005
>>>>>>>> O: 202-508-6514
>>>>>>>> C: 202-251-0731
>>>>>>>> Visit us online@ http://www.boozallen.com
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: David RR Webber (XML) [mailto:david@drrw.info]
>>>>>>>> Sent: Wednesday, May 10, 2006 11:03 AM
>>>>>>>> To: Stephen Green
>>>>>>>> Cc: ubl-dev@lists.oasis-open.org
>>>>>>>> Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev]
>>>>>>>> SBS
>>
>>>>>>>> and Restricted Data Types
>>>>>>>>
>>>>>>>> Stephen,
>>>>>>>>
>>>>>>>> I follow your thoughts here.
>>>>>>>>
>>>>>>>> We're actively re-visiting on which pieces of the CAM template
>>>>>>>> should be required and which non-normative / extensible.
>>>>>>>>
>>>>>>>> Right now the <DataValidation> and <ExternalMapping> are
>> optional.
>>>>>>>> Also in jCAM Martin has implemented Maven with these so they are
>
>>>>>>>> fully
>>>>>>>
>>>>>>>> extensible - but obviously that is then non-normative - but I
>>>>>>>> have
>>>
>>>>>>>> not
>>>>>>>
>>>>>>>> yet updated the spec' to reflect that change. It's a critical
>>>>>>>> direction
>>>>>>>> - the realization that you cannot perscribe everything for
>>>>>>>> everyone
>>>>>>>> - and that instead - you provide normative tools for those parts
>
>>>>>>>> people expect the standard to - while giving flexiblity - but in
>
>>>>>>>> a
>>>
>>>>>>>> known and predictable and re-usable way - for those peices they
>>>>>>>> traditionally expect to have control over.
>>>>>>>>
>>>>>>>> The other normative sections are of course tailorable to match
>>>>>>>> the
>>>
>>>>>>>> particular implementors vision and can include only those
>>>>>>>> feartures
>>>>
>>>>>>>> and parts that suit (it's just XML markup!).
>>>>>>>>
>>>>>>>> What I would expect is that the CAM template would be a
>>>>>>>> base-line
>>
>>>>>>>> one
>>>>>>>> - that implementors could then refine and extend to their own
>>>>>>>> local
>>>>>>> needs.
>>>>>>>> This I think is inline with the notion of SBS - having a
>>>>>>>> jump-start
>>>>
>>>>>>>> kit that people can quickly use by default - and then refine and
>
>>>>>>>> extend in practice. Use of <include> is critical to provide
>>>>>>>> separation between such base-line templates and local
> extensions.
>>>>>>>> And then context is vital for people to understand the use model
>
>>>>>>>> for
>>>>>
>>>>>>>> each
>>>>>>> template.
>>>>>>>>
>>>>>>>> DW
>>>>>>>>
>>>>>>>>
>>>>>>>> -------- Original Message --------
>>>>>>>> Subject: Re: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev]
>>>>>>>> SBS
>>
>>>>>>>> and Restricted Data Types
>>>>>>>> From: "Stephen Green" <stephen_green@bristol-city.gov.uk>
>>>>>>>> Date: Wed, May 10, 2006 10:35 am
>>>>>>>> To: <ubl-dev@lists.oasis-open.org>
>>>>>>>>
>>>>>>>> This makes me think UBL might be benefitted from CAM templates
>>>>>>>> based
>>>>>
>>>>>>>> on a profile of CAM which covers the gaps. Maybe one profile
>>>>>>>> without
>>>>>
>>>>>>>> the 'context' bit (CCTS concept of it, not CL methodology
>>>>>>>> concept
>>
>>>>>>>> of
>>>>>
>>>>>>>> document context) and one with (so one doesn't have to implement
>
>>>>>>>> a
>>>
>>>>>>>> full-scale CCTS context-sensitive system unless there is a need
>>>> to).
>>>>>>>> There may be other bits of CAM not needed in such UBL
>>>>>>>> implementations too, or parts which UBL duplicates which could
>>>>>>>> be
>>>>> profiled-out.
>>>>>>>>
>>>>>>>> Stephen Green
>>>>>>>>
>>>>>>>>>>> "David RR Webber (XML)" <david@drrw.info> 05/10/06 15:02 PM
>>>>>>>>>>> >>>
>>>>>>>> Chin,
>>>>>>>>
>>>>>>>> I was trying to not get into nitty-gritty angle bracket stuff -
>>>>>>>> but
>>>>
>>>>>>>> here's a 20,000 foot view.
>>>>>>>>
>>>>>>>> The CAM template consists of 5 sections:
>>>>>>>>
>>>>>>>> <Header>
>>>>>>>> <AssemblyStructure>
>>>>>>>> <BusinessUseContext>
>>>>>>>> <DataValidations>
>>>>>>>> <ExternalMapping>
>>>>>>>>
>>>>>>>> We can equate the two <AssemblyStructure> and
>>>>>>>> <BusinessUseContext>
>>>
>>>>>>>> to the layering approach - where UBL provides the structure
>>>>>>>> definition - and the context section then exposes the delta
>>>>>>>> between
>>>>
>>>>>>>> the generic and
>>>>>>>
>>>>>>>> subset. You can use <include> in the structure section to
>>>>>>>> reference
>>>>>
>>>>>>>> a
>>>>>>>
>>>>>>>> particular UBL sample.
>>>>>>>>
>>>>>>>> Basically if you look in the <BusinessUseContext> section and
>>>>>>>> you
>>
>>>>>>>> see nothing - then you know people are using that included UBL
>>>>>>>> sample
>>>>>>> as-is!
>>>>>>>>
>>>>>>>>
>>>>>>>> Otherwise - the Header can come into play next - because that is
>
>>>>>>>> where
>>>>>>>
>>>>>>>> you define your global context variables that you might need -
>>>>>>>> for
>>>
>>>>>>>> example boolean $export_order.
>>>>>>>>
>>>>>>>> So - in the context section you can have default rules - I would
>
>>>>>>>> expect you to have these normally - as these apply to all
>>>>>>>> context
>>
>>>>>>>> instances and use - these are identified in the XML by -
>>>>>>>>
>>>>>>>> <Rules><default><context> <!-- default rules -->
>>>>>>>> </context>/default> ....
>>>>>>>>
>>>>>>>> After that - you have specific context rules - here is where you
>
>>>>>>>> would
>>>>>>>
>>>>>>>> put the typical refinements and crosschecks (e.g. if
>>>>>>>> $export_order
>>>
>>>>>>>> then <export_manifest> required mandatory element, etc)
>>>>>>>> associated
>>>
>>>>>>>> with your use case - these can reference global $ variables - or
>
>>>>>>>> be
>>>>
>>>>>>>> value driven within the data stream - e.g. :
>>>>>>>>
>>>>>>>> <context
>>>>>>>>
> condition="PHS398_ResearchPlan:TypeOfApplication='Resubmission'">
>>>>>>>> <constraint action="makeMandatory(//RR_SF424:FederalID)" />
>>>>>>>> <constraint action="setLength(//RR_SF424:FederalID,15)" />
>>>>>>>> </context> </Rules>
>>>>>>>>
>>>>>>>> So you can see the deltas are explicitly called out and labelled
>
>>>>>>>> by
>>>>
>>>>>>>> context - and you can find them quickly without having to grope
>>>>>>>> through the XML structure itself line-by-line.
>>>>>>>>
>>>>>>>> CAM also provides you with a library of 30+ functions - so you
>>>>>>>> can
>>>
>>>>>>>> manipulate the structure tree - pruning or selecting, changing
>>>>>>>> from
>>>>
>>>>>>>> optional to mandatory, etc, rule driven. I like to say that XSD
>
>>>>>>>> schema provides you with a picture map of all the possible
>>>>>>>> structural varients that you may encounter - whereas CAM
>>>>>>>> restricts
>>>
>>>>>>>> this to the exact structure layout that you need for your
>>>>>>>> particular
>>>>>
>>>>>>>> context and
>>>>>>> usage.
>>>>>>>>
>>>>>>>> DW
>>>>>>>>
>>>>>>>>
>>>>>>>> -------- Original Message --------
>>>>>>>> Subject: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS
>>>>>>>> and
>>
>>>>>>>> Restricted Data Types
>>>>>>>> From: Chin Chee-Kai <cheekai@softml.net>
>>>>>>>> Date: Tue, May 09, 2006 9:21 pm
>>>>>>>> To: UBL-Dev <ubl-dev@lists.oasis-open.org>
>>>>>>>>
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>> Very much so, certain level of semantics processing that is
>>>>>>>> common
>>>
>>>>>>>> may
>>>>>>>
>>>>>>>> be extracted and stored away as what you call sub-component
>>>>> templates.
>>>>>>>>
>>>>>>>> You mentioned that CAM already handles the deltas by making them
>
>>>>>>>> explicit so business users can readily inspect them. It sounds
>>>>>>>> good, but in what manner does CAM store and manifest the deltas?
>>>>>>>> Let's say we use the string length restriction from infinite to
>>>>> 30-char
>>>>>>>> for example. How does CAM indicate this delta? (Sorry for
>>> asking
>>>>>>>> something so simple relative to CAM as I haven't much exposure
> to
>>>>>>>> CAM yet). If he way CAM does it is usable, there may be
>>> something
>>>>>>>> which UBL customisation could incorporate.
>>>>>>>>
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>> Chin Chee-Kai
>>>>>>>> SoftML
>>>>>>>> Tel: +65-6820-2979
>>>>>>>> Fax: +65-6820-2979
>>>>>>>> Email: cheekai@SoftML.Net
>>>>>>>> http://SoftML.Net/
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, 9 May 2006, David RR Webber (XML) wrote:
>>>>>>>>
>>>>>>>>>> Chin,
>>>>>>>>>>
>>>>>>>>>> ...
>>>>>>>>>>
>>>>>>>>>> Another tool here is <include> statements. Where a template
>>>>>>>>>> fragment is created that handles default processing of common
>>>>>>>>>> blocks
>>>>>>>
>>>>>>>>>> of XML content (address is an obvious one). Being able to
>>>>>>>>>> create
>>>>
>>>>>>>>>> sub-components templates - breaking the overall processing
>>>>>>>>>> down
>>
>>>>>>>>>> into
>>>>>>>
>>>>>>>>>> smaller more manageable chunks is another notion that helps to
>
>>>>>>>>>> implement concepts such as SBS.
>>>>>>>>>>
>>>>>>>>>> DW
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ----------------------------------------------------------------
>>>>>>>> -
>>>>>>>> -
>>>>>>>> -
>>>>>>>> -
>>>>>>>> - This publicly archived list supports open discussion on
>>>>>>>> implementing the UBL OASIS Standard. To minimize spam in the
>>>>>>>> archives, you must subscribe before posting.
>>>>>>>>
>>>>>>>> [Un]Subscribe/change address:
>>>>>>>> http://www.oasis-open.org/mlmanage/
>>>>>>>> Alternately, using email:
>>>>>>>> list-[un]subscribe@lists.oasis-open.org
>>>>>>>> List archives: http://lists.oasis-open.org/archives/ubl-dev/
>>>>>>>> Committee homepage: http://www.oasis-open.org/committees/ubl/
>>>>>>>> List Guidelines:
>>>>>>>> http://www.oasis-open.org/maillists/guidelines.php
>>>>>>>> Join OASIS: http://www.oasis-open.org/join/
>>>>>>>>
>>>>>>>>
>>>>>>>> ----------------------------------------------------------------
>>>>>>>> -
>>>>>>>> -
>>>>>>>> -
>>>>>>>> -
>>>>>>>> - This publicly archived list supports open discussion on
>>>>>>>> implementing the UBL OASIS Standard. To minimize spam in the
>>>>>>>> archives, you must subscribe before posting.
>>>>>>>>
>>>>>>>> [Un]Subscribe/change address:
>>>>>>>> http://www.oasis-open.org/mlmanage/
>>>>>>>> Alternately, using email:
>>>>>>>> list-[un]subscribe@lists.oasis-open.org
>>>>>>>> List archives: http://lists.oasis-open.org/archives/ubl-dev/
>>>>>>>> Committee homepage: http://www.oasis-open.org/committees/ubl/
>>>>>>>> List Guidelines:
>>>>>>>> http://www.oasis-open.org/maillists/guidelines.php
>>>>>>>> Join OASIS: http://www.oasis-open.org/join/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ----------------------------------------------------------------
>>>>>>>> -
>>>>>>>> -
>>>>>>>> -
>>>>>>>> -
>>>>>>>> - This publicly archived list supports open discussion on
>>>>>>>> implementing the UBL OASIS Standard. To minimize spam in the
>>>>>>>> archives, you must subscribe before posting.
>>>>>>>>
>>>>>>>> [Un]Subscribe/change address:
>>>>>>>> http://www.oasis-open.org/mlmanage/
>>>>>>>> Alternately, using email:
>>>>>>>> list-[un]subscribe@lists.oasis-open.org
>>>>>>>> List archives: http://lists.oasis-open.org/archives/ubl-dev/
>>>>>>>> Committee homepage: http://www.oasis-open.org/committees/ubl/
>>>>>>>> List Guidelines:
>>>>>>>> http://www.oasis-open.org/maillists/guidelines.php
>>>>>>>> Join OASIS: http://www.oasis-open.org/join/
>>>>>>>>
>>>>>>>>
>>>>>>>> ----------------------------------------------------------------
>>>>>>>> -
>>>>>>>> -
>>>>>>>> -
>>>>>>>> -
>>>>>>>> - This publicly archived list supports open discussion on
>>>>>>>> implementing the UBL OASIS Standard. To minimize spam in the
>>>>>>>> archives, you must subscribe before posting.
>>>>>>>>
>>>>>>>> [Un]Subscribe/change address:
>>>>>>>> http://www.oasis-open.org/mlmanage/
>>>>>>>> Alternately, using email:
>>>>>>>> list-[un]subscribe@lists.oasis-open.org
>>>>>>>> List archives: http://lists.oasis-open.org/archives/ubl-dev/
>>>>>>>> Committee homepage: http://www.oasis-open.org/committees/ubl/
>>>>>>>> List Guidelines:
>>>>>>>> http://www.oasis-open.org/maillists/guidelines.php
>>>>>>>> Join OASIS: http://www.oasis-open.org/join/
>>>>>>>>
>>>>>>>> ----------------------------------------------------------------
>>>>>>>> -
>>>>>>>> -
>>>>>>>> -
>>>>>>>> -
>>>>>>>> - This publicly archived list supports open discussion on
>>>>>>>> implementing the UBL OASIS Standard. To minimize spam in the
>>>>>>>> archives, you must subscribe before posting.
>>>>>>>>
>>>>>>>> [Un]Subscribe/change address:
>>>>>>>> http://www.oasis-open.org/mlmanage/
>>>>>>>> Alternately, using email:
>>>>>>>> list-[un]subscribe@lists.oasis-open.org
>>>>>>>> List archives: http://lists.oasis-open.org/archives/ubl-dev/
>>>>>>>> Committee homepage: http://www.oasis-open.org/committees/ubl/
>>>>>>>> List Guidelines:
>>>>>>>> http://www.oasis-open.org/maillists/guidelines.php
>>>>>>>> Join OASIS: http://www.oasis-open.org/join/
>>>>>>>>
>>>>>>>> ----------------------------------------------------------------
>>>>>>>> -
>>>>>>>> -
>>>>>>>> -
>>>>>>>> -
>>>>>>>> - This publicly archived list supports open discussion on
>>>>>>>> implementing the UBL OASIS Standard. To minimize spam in the
>>>>>>>> archives, you must subscribe before posting.
>>>>>>>>
>>>>>>>> [Un]Subscribe/change address:
>>>>>>>> http://www.oasis-open.org/mlmanage/
>>>>>>>> Alternately, using email:
>>>>>>>> list-[un]subscribe@lists.oasis-open.org
>>>>>>>> List archives: http://lists.oasis-open.org/archives/ubl-dev/
>>>>>>>> Committee homepage: http://www.oasis-open.org/committees/ubl/
>>>>>>>> List Guidelines:
>>>>>>>> http://www.oasis-open.org/maillists/guidelines.php
>>>>>>>> Join OASIS: http://www.oasis-open.org/join/
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----------------------------------------------------------------
>>>>>>> -
>>>>>>> -
>>>>>>> -
>>>>>>> - This publicly archived list supports open discussion on
>>>>>>> implementing the UBL OASIS Standard. To minimize spam in the
>>>>>>> archives, you must subscribe before posting.
>>>>>>>
>>>>>>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>>>>>>> Alternately, using email: list-[un]subscribe@lists.oasis-open.org
>>>>>>> List archives: http://lists.oasis-open.org/archives/ubl-dev/
>>>>>>> Committee homepage: http://www.oasis-open.org/committees/ubl/
>>>>>>> List Guidelines:
>>>>>>> http://www.oasis-open.org/maillists/guidelines.php
>>>>>>> Join OASIS: http://www.oasis-open.org/join/
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------
>>>>>> -
>>>>>> -
>>>>>> - This publicly archived list supports open discussion on
>>>>>> implementing the UBL OASIS Standard. To minimize spam in the
>>>>>> archives, you must subscribe before posting.
>>>>>>
>>>>>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>>>>>> Alternately, using email: list-[un]subscribe@lists.oasis-open.org
>>>>>> List archives: http://lists.oasis-open.org/archives/ubl-dev/
>>>>>> Committee homepage: http://www.oasis-open.org/committees/ubl/
>>>>>> List Guidelines:
>>>>>> http://www.oasis-open.org/maillists/guidelines.php
>>>>>> Join OASIS: http://www.oasis-open.org/join/
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------------------------------------
>>>>> -
>>>>> - This publicly archived list supports open discussion on
>>>>> implementing the UBL OASIS Standard. To minimize spam in the
>>>>> archives, you must subscribe before posting.
>>>>>
>>>>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>>>>> Alternately, using email: list-[un]subscribe@lists.oasis-open.org
>>>>> List archives: http://lists.oasis-open.org/archives/ubl-dev/
>>>>> Committee homepage: http://www.oasis-open.org/committees/ubl/
>>>>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>>>>> Join OASIS: http://www.oasis-open.org/join/
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> This publicly archived list supports open discussion on implementing
> the UBL OASIS Standard. To minimize spam in the
> archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Alternately, using email: list-[un]subscribe@lists.oasis-open.org
> List archives: http://lists.oasis-open.org/archives/ubl-dev/
> Committee homepage: http://www.oasis-open.org/committees/ubl/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> Join OASIS: http://www.oasis-open.org/join/
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]