Re: [ubl-dev] UBL Code Data Types

["Stephen Green" <stephen_green@seventhproject.co.uk>]

The impression I get is that there are less attributes needed for Measure
and less still for
Quantity because, like Amount, which is bound to the ISO currency codelist
and therefore
only has to provide for metadata about the particular version of the
codelist used, these
datatypes are already associated with fixed values for codelist etc and so
have less scope
for variation than the much more general Code datatype.

Last time I looked, this was all documented in the UN/CEFACT CCTS
specification
(sorry I can't provide a link off hand).

The Amount datatype is particularly interesting  - perhaps it means I'm just
'sad' to find it
interesting :-)
- since
1) it has a 'unqualified' (ATG2 term) or 'unspecialised' (the corresponding
UBL
term) datatype corresponding to the Amount 'core component type' which
limits the
codelist allowed to just the ISO currency codelist but allows variation of
the version
of the currency codelist and therefore has a codelistVersionID (or, in UBL
1.0
an called the 'currencyCodelistVersionID' - expect alignment of the names in
UBL 2.0).
2) UBL has further specialized the unspecialized Amount datatype to only
allow a
single version of the ISO currency codelist (version 0.3) in UBL 1.0
UBL has still provided a metadata attribute to specifiy the codelist version
but has a fixed
value for it.

The Measure and Quantity datatypes are similar to the above but are less
developed in UBL since there
is no further specialization of them as 'specialized datatypes' (the UBL
term equivalent to ATG2's
'qualified datatypes'). Still it is necessary to understand the fact that
these datatypes in the
CCTS spec have restricted allowed values for metadata and so do not provide
all the
metadata attributes (so-called 'supplementary component' attributes)
provided for the less
specialized Code datatype.

Hope this doesn't confuse things

Stephen Green

----- Original Message ----- 
From: "Tim McGrath" <tmcgrath@portcomm.com.au>
To: <ddobbing@attglobal.net>
Cc: <ubl-dev@lists.oasis-open.org>
Sent: Tuesday, May 03, 2005 8:45 AM
Subject: Re: [ubl-dev] UBL Code Data Types


> hi dave,
>
> the attributes of UBL data types are taken from the ebXML Core Component
> Technical Specification so the question is better aimed at UN/CEFACT.
>
> however, you are quite correct that there are (or should be)
> relationships between these attributes. the attached class diagram is
> one that UBL de-constructed from the ebXML specifications.  it may help
> clarify the architecture used.
>
> NB since UBL 1.0 was released UN/CEFACT's ATG2 group have drafted their
> own set of schemas for Core Component types.  Whilst these follow the
> same principles and structure as the UBL 1.0 ones, there are some subtle
> differences. our plan is to adopt the ATG2 schemas when we publish UBL
> 2.0.  i mention this because  it reinforces the fact the UBL is not in
> the business of re-inventing  common data types for XML schemas. from a
> UBL perspective we hope that by adopting the same ebXML data type
> schemas as UN/CEFACT and others (such as OAGIS) we can promote greater
> interoperability between document implementations.
>
>
> David Dobbing wrote:
>
> >Relatively new to UBL. A question. Was there any particular reason for
the
> >list of attributes for the CC Data Types "MeasureType" and "QuantityType"
> >not having a similar attribute structure to that of "CodeType"?.  To my
way
> >of thinking units of measure and quantity types are all basically codes
and
> >depending on their implementation could be sourced from different code
> >maintenance agencies, with different versions, etc, etc. As a consequence
> >possibly they should have the same attribute structure (in addition to
the
> >code unit value) as "CodeType"???
> >
> >Below is an extract from the V1.0 UBL CC Types schema.
> >
> ><xsd:complexType name="CodeType">
> >
> >   <xsd:simpleContent>
> >
> >      <xsd:extension base="xsd:normalizedString">
> >
> >         <xsd:attribute name="codeListID" type="xsd:normalizedString"
> >use="optional"/>
> >         <xsd:attribute name="codeListAgencyID"
type="xsd:normalizedString"
> >use="optional"/>
> >         <xsd:attribute name="codeListAgencyName" type="xsd:string"
> >use="optional"/>
> >         <xsd:attribute name="codeListName" type="xsd:string"
> >use="optional"/>
> >         <xsd:attribute name="codeListVersionID"
type="xsd:normalizedString"
> >use="optional"/>
> >         <xsd:attribute name="name" type="xsd:string" use="optional"/>
> >
> >         <xsd:attribute name="languageID" type="xsd:language"
> >use="optional"/>
> >         <xsd:attribute name="codeListURI" type="xsd:anyURI"
> >use="optional"/>
> >         <xsd:attribute name="codeListSchemeURI" type="xsd:anyURI"
> >use="optional"/>
> >      </xsd:extension>
> >
> >   </xsd:simpleContent>
> >
> ></xsd:complexType>
> >
> >
> >
> ><xsd:complexType name="MeasureType">
> >
> >   <xsd:simpleContent>
> >
> >      <xsd:extension base="xsd:decimal">
> >
> >         <xsd:attribute name="measureUnitCode"
type="xsd:normalizedString"
> >use="optional"/>
> >         <xsd:attribute name="measureUnitCodeListVersionID"
> >type="xsd:normalizedString" use="optional"/>
> >      </xsd:extension>
> >
> >   </xsd:simpleContent>
> >
> ></xsd:complexType>
> >
> >
> >
> ><xsd:complexType name="QuantityType">
> >
> >   <xsd:simpleContent>
> >
> >      <xsd:extension base="xsd:decimal">
> >
> >         <xsd:attribute name="quantityUnitCode"
type="xsd:normalizedString"
> >use="optional"/>
> >         <xsd:attribute name="quantityUnitCodeListID"
> >type="xsd:normalizedString" use="optional"/>
> >         <xsd:attribute name="quantityUnitCodeListAgencyID"
> >type="xsd:normalizedString" use="optional"/>
> >         <xsd:attribute name="quantityUnitCodeListAgencyName"
> >type="xsd:string" use="optional"/>
> >      </xsd:extension>
> >
> >   </xsd:simpleContent>
> >
> ></xsd:complexType>
> >
> >
> >
> >Thanks in advance for any clarification.
> >
> >Regards
> >
> >--- David Dobbing, Data Logistics, ddobbing@attglobal.net
> >
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> >For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
> >
> >
> >
>
> -- 
> regards
> tim mcgrath
> phone: +618 93352228
> postal: po box 1289   fremantle    western australia 6160
>
> DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business
Informatics and Web Services
> (coming soon from MIT Press)
>
http://mitpress.mit.edu/catalog/item/default.asp?sid=632C40AB-4E94-4930-A94E-22FF8CA5641F&ttype=2&tid=10476
>
>
>


----------------------------------------------------------------------------
----






----------------------------------------------------------------------------
----


> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org