[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ciq] FW: UBL Address format vs. CIQ
Michael, Many thanks for this work. I will start looking into your work today and will comeback to you. Regards, Ram Ram Kumar General Manager Software R&D and Architecture MSI BUSINESS SYSTEMS Suite 204A, 244 Beecroft Road Epping, NSW 2121, Australia Direct: +61-2-9815 0226 Mobile: +61-412 758 025 Fax: +61-2-98150200 URL: www.msi.com.au > -----Original Message----- > From: Michael.Roytman@vertexinc.com > [mailto:Michael.Roytman@vertexinc.com] > Sent: Thursday, October 14, 2004 10:57 PM > To: Ram Kumar > Cc: ciq@lists.oasis-open.org; Rob Beauchamp > Subject: Re: [ciq] FW: UBL Address format vs. CIQ > > > CIQ TC, > > here are the updated versions of xNL-Basic and xNL-Advanced > that I have adjusted to reflect the UBL Name and Design rules. > The changes were made in the following areas: > Namespace [NMS4] > Attributes and attribute groups [GNR9] > The term "Indicator" should be abbreviated to ID [Appendix > B]. I have > not made the change since I, personally, do not like abbreviations. > There is a partyNameKey attribute, which I think should be > renamed to > partyNameIdentifier, since Key is a bit misleading. > xsd:anyAttibute must not be used [GTD2] > xsd:any element must not be used [ELD9], I do not think we > use it, but > anyway > The biggest impact will be the xsd:documentation that needs to be > assigned to every element, complex type, attribute group, > etc. I have > not done that yet, since we need to agree that this is > indeed the level > of details we want to specify in the schemas. Moreover, > UBL calls for > "run-time" versions of schemas with the documentation > stripped down. Any > thoughts? > > I probably missed a few NDRs here, but since we do not have > the hierarchy of code lists (or do we?), the final document > rules (Invoice, TaxFiling, > InsuranceClaim) do not apply to CIQ. > Comments and questions are welcome. > Best regards, > > Michael Roytman. > > (See attached file: xNL-Advanced-3.0.6.xsd)(See attached file: > xNL-Basic-3.0.6.xsd)(See attached file: UBL-NDR-Checklist-1.0.pdf) > > > > > |---------+----------------------------> > | | "Ram Kumar" | > | | <RKumar@msi.com.a| > | | u> | > | | | > | | 10/12/2004 08:44 | > | | PM | > | | | > |---------+----------------------------> > > >------------------------------------------------------------- > ------------------------------------------------------------------| > | > | > | To: <ciq@lists.oasis-open.org> > | > | cc: "Rob Beauchamp" > <Rbeauchamp@Initiatesystems.com> > | > | Subject: [ciq] FW: UBL Address format vs. CIQ > | > > >------------------------------------------------------------- > ------------------------------------------------------------------| > > > > > CIQ TC, > > FYI regarding UBL and CIQ from Tim McGrath of UBL. > > Michael, > > You have promised to look into the compatibility between NDR > of UBL and CIQ. Can you please advise of your progress on > this? Thanks. > > Regards, > > Ram > > Ram Kumar > General Manager > Software R&D and Architecture > MSI BUSINESS SYSTEMS > Suite 204A, 244 Beecroft Road > Epping, NSW 2121, Australia > Direct: +61-2-9815 0226 > Mobile: +61-412 758 025 > Fax: +61-2-98150200 > URL: www.msi.com.au > > > > From: Tim McGrath [mailto:tmcgrath@portcomm.com.au] > Sent: Tuesday, October 12, 2004 10:43 AM > To: Colin.Wallis@ssc.govt.nz > Cc: jon.bosak@sun.com; Ram Kumar > Subject: Re: UBL Address format vs. CIQ > > thank you for your support of UBL. i will attempt to address (pun > intended) your comments, but this is merely my own opinion > and not necessarily that of the UBL technical committee. > > personally, i had thought UBL had shifted towards xNAL not > away from it. > perhaps you can give some examples? we deliberately include > the xNAL terms as synonymous business terms in our library. > in fact, we have had a continuous dialogue with the CIQ team > throughout UBL's development. you may also be aware that CIQ > are not the only players working on standards for addressing > and UBL has tried to accomodate the work of various ISO > groups, the UN/ECE as well as our own team of ontologists. > > you mention UBL's flexibility. we have tried to take an > 80/20 approach to business requirements. we know that very > few implementors will be able to use UBL without some form of > customization. we have tried to provide a common base on > which these customization are built. this is important to > the points that follow. > > the main issues why UBL could not simply 'use xNAL' are: > * xNAL does not define a single address structure. it is a > rich vocabulary that can be used to structure various > different forms of addressing. two parties using xNAL may > not have any more compatibility than two using two different > vocabularies. UBL must have only one way to form an address. > so we wwould still need a UBl implementation of xNAL that may > not be the same as NZ Government, etc., etc.. > * xNAL sometimes uses the concept of qualifying values for > its semantic names. you mention thoroughfare and this is a > case in point. unless parties subsequently agreed how to > qualify thoroughfare - they may well use two different ways > of defining street or avenue, etc.. UBL could have provided > these qualifiers for our requirements but this breaks the > design philosophy UBL was built on. i believe that taking > this approach recreates the problems people had with > EDI-based vocabularies. > * the requirement for addresses in UBL is not simply for > postal services or CRM applications - xNAL's primary target. > this is why xNAL has a much more sophisticated data model. > * the actual XML syntax used by xNAL is not the same as UBL's > XML naming and design rules. the technical people in UBL > tell me this would make using actual xNAL schemas difficult > and UBL would have to recreate xNAL in its own schemas. we > then have a maintenance issue with keeping synchronized into > the future. > > these are all the practical results of separate initiatives > developing standards. in this situation, the best we can > hope to achieve is some form of interoperability. > specifically, this would mean being able to map an address > presented in a UBL document to something equivalent in an > xNAL format and vice versa. To this end UBL provides the > equivalent xNAL terms in our model (something we dont do for > any other vocabulary). but as you point out this is not a > clean map - today. > > looking forward, i am aware that the CIQ team are considering > using UBL's XML naming and design rules for future releases. > this will resolve at least one the issues above. > > personally, i am a supporter of the work of the CIQ team and > would like to see convergence. It is feasible that UBL 2.0 > may be closer to xNAL ?.?? > but this would need to be evolutionary. in fact, i am > meeting Ram Kumar, the chair of the CIQ team, in two weeks > time and we shall certainly be talking about these issues. > > > PS > i hope i am not being presumptuous by including Ram and Jon > in this response. i think they both have an interest in the matter. > > Colin.Wallis@ssc.govt.nz wrote: > Hi Tim > > I got your contact details from Jon Bosak. Jon and I > talked on the > phone at the recent e-gov OASIS meeting. > > I expressed some concerns around the shift from the > early UBL drafts > which used CIQ exclusively, to V1 where some of those > element names > have been replaced. Also I am not sure if any testing > of UBL address > structures against UPU address structures has been done. > > I know terms like "thoroughfare" are not the most user > friendly and > in NZ where xNAL is mandatory for government agencies > data exchange > we have had heated discussions on such issues. That > said, we have > stuck to it because there is logic in it, after you > have used CIQ for > a while. Even in our own environment, there are > addresses which do > not easily (semantically) fit UBL's "StreetType" and > you would find > that in OZ too before even looking elsewhere in the world. > > I know UBL is flexible enough to pretty much put > whatever elements > you want in there, but it becomes a real pain getting > that agreement > across a whole spectrum of parties, altering parsers to > suit etc etc. > > I don't know how much deep thought was put into this > change and if it > is irreversible? > > That said, I fully support UBL and what it is trying to achieve. > > But I have to raise this issue as it will potentially > hamper the rate > of adoption in NZ govt. > > Cheers > > Colin > > Colin Wallis > e-GIF Business Analyst > e-Government Unit - State Services Commission > T: 04 495 6758 > > > http://www.e-government.govt.nz > > > > > -- > regards > tim mcgrath > phone: +618 93352228 > postal: po box 1289 fremantle western australia 6160 > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]