[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]