Hi Tim, Mike,
Many thanks for your feedback and pointers, and in particular it would
appear that I need to take a closer look at the ATG2 datatypes. I will get
back to you over the next few days, a number of balls in air at the minute!
Regards
David
--- David Dobbing, Data Logistics,
On Tuesday, 3 May 2005 8:38 PM, Stephen Green wrote:
> I'd add to my last message:
>
> The ATG2 unqualified Amount doesn't
> (it seems to me) allow variation of the version of the
> codelist since it is bound to a particular version by the
> import of a particular CEFACT schema for the currency
> codelist. I take it that this CEFACT ATG2 schema corresponds
> to a particular version of the ISO currency codelist but the
> ATG2 unqualified Amount datatype does not, it seems, provide
> an attribute to designate this version. We'll see what
> happens in UBL 2.0 if these same ATG2 schemas are
> incorporated but this is a bit concerning for the Amount
> since I think it is
> *very* important legally *in a document* to be clear which
> version of a codelist for currency is being used. The
> provision of the imported schema may help but I'd find it a
> bit weak to rely on this schema not being substituted and
> would still like to see a version attribute added.
>
> Sorry this is a bit off topic but it's about the sort of
> considerations happening when these datatypes are modeled and
> eventually emerge as schemas. I'd say that there may be a
> danger that when binding the code in a datatype to a
> particular codelist and codelist version a rather, in my
> opinion, unhappy/costly loss of metadata may result by just
> dropping the then fixed metadata values from instances.
> I'd hope that there would be due vigilance in the merging of
> UBL and ATG2 datatypes but for now I'm happy that the meta
> data is there for the UBL 1.0 'UBLAmount' specialized
> datatype because UBL 1.0 still provides the version attribute
> (but fixes it). I'd say providing the attributes and maybe
> fixing in the schemas those which cannot be varied is far
> better than dropping those which can't be varied and assuming
> that auditors and legal reps in the future looking at a
> document either know or have access to the specs and schemas
> which document the missing metadata (not too good an
> assumption in my opinion) - perhaps due to some expensive
> archiving of metadata along with documents (why not just
> ensure all the necessary metadata is to be found in each
> document). However it might be better to provide the
> unvarying attributes in schemas *without* fixing them since
> fixing attribute values causes problems with backwards
> compatibility in minor revisions when trying to update the
> associations of codelists.
>
> These same considerations should, I think, be applied to
> implementations and any remodeling of Measure and Quantity
> but I just haven't had, myself, needed to go into details
> about them yet.
> This is partly becaues UBL 1.0 didn't provide a schema for
> Units of Measure (UOM) codes. If the UBL 2.0 aim remains to
> incorporate ATG2 v1.1 schemas then these include a UOM codelist
> schema but
> without any values. I think the ATG2 emphaisis is on
> providing the version, etc metadata in the namespace of the
> codelist but I'd be especially concerned with the fact that
> this might not be explicit in every given document instance.
> This would be a real concern for me with UBL 2.0 using the
> ATG2 CCTS datatype schemas. I'll aim to bring this up in the UBL TC.
>
> All the best
>
> Stephen Green
>
>
>
> ----- Original Message -----
> From: "Stephen Green" <>
> To: <>
> Sent: Tuesday, May 03, 2005 12:32 PM
> Subject: Re: [ubl-dev] UBL Code Data Types
>
>
>> 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" <>
>> To: <>
>> Cc: <>
>> 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,
>>>>
>>>>
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>
>>>>
>>>>
>>>>
>>>
>>> --
>>> 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:
>>> For additional commands, e-mail:
>>
>>
>>
> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
--- David Dobbing, Data Logistics,
