[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] UBL Code Data Types
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, ddobbing@attglobal.net 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" <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 >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org --- David Dobbing, Data Logistics, ddobbing@attglobal.net
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]