OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS andRestricted Data Types


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/
>





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]