[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] UBL Code Data Types
Hi David, The ATG2 schema are available as part of the NDR Implementation Verification (Step 6 ODP) package available at: http://webster.disa.org/cefact-groups/atg/downloads/index.cfm. ATG will be having a F2F the last week of June to discuss implementation verification issues. I am hopeful that any issues related to the schema will be identified before that meeting so we can make adjustments as necessary to ensure we address any UBL concerns, as well as those of other standards bodies such as OMG, and other implementers, such as the US Government and Department of the Navy. Mark > -----Original Message----- > From: David Dobbing [mailto:ddobbing@attglobal.net] > Sent: Wednesday, May 04, 2005 9:15 AM > To: ubl-dev@lists.oasis-open.org > 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 > > > > > --------------------------------------------------------------------- > 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]