OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ciq message

[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]