[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] UBL Code Data Types
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" <stephen_green@seventhproject.co.uk> To: <ubl-dev@lists.oasis-open.org> 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" <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 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]