[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ciq] FW: UBL Address format vs. CIQ
David, points well taken. Designers, developers, technical writers, and people paying the bills have different agendas and expectations. My task was to review the OASIS UBL NDR and CIQ schema conformance with it, which I did. Whether we choose to follow and comply is a different matter. Thank you for your very insightful response. Best regards, Michael. |---------+----------------------------> | | David RR Webber | | | <david@drrw.info>| | | | | | 10/15/2004 08:50 | | | AM | | | | |---------+----------------------------> >-------------------------------------------------------------------------------------------------------------------------------| | | | To: Michael.Roytman@vertexinc.com | | cc: ciq@lists.oasis-open.org, Rob Beauchamp <Rbeauchamp@Initiatesystems.com>, Ram Kumar <RKumar@msi.com.au> | | Subject: Re: [ciq] FW: UBL Address format vs. CIQ | >-------------------------------------------------------------------------------------------------------------------------------| Michael, That's a huge "if"! Schema frankly is not intended to be doing all this. If you read the W3C Requirements - it has a very simple use profile. However - people keep heaping all these other things on it - and wonder why it does not do a great job. Frankly - shoe-horning this stuff into schema gives people a false sense of solution - its just a band-aid at best - and then has all these side effects - now we have to have two schemas - and you have to ignore parts of it - and then there is gnarly questions like - how do you support versioning and contextual selections, how do you create re-usable sub-assemblies for address components? That is why we created CAM and Registry because we recognize these chronic limitations. I know I keep urging using CAM here - and people don't want to have to learn something else - and have more extensions - but the bottom line is either you can do this right or you can continue to band-aid. And CAM really is not hard to do because it has been designed to be readable syntax - whereas schema is explicitly stated to be unreadable by humans as a design decision. The jCAM implementation has matured dramatically in the past two months - and now we're seriously tackling the direct integration to registry - the ability to manage nouns definitions and then deploy them directly to a standard based engine is achievable here. Your Java programs can call jCAM directly and pass DOM pointers to XML content and have jCAM both validate and post-process the content using the integrated Saxon tools. So - my argument is that the schema cannot be a self-contained source, its not designed to be, and it does not have sufficent tools or extensibility to do that. It use model is a narrow client-centric structure checker in a disconnected environment. That's not what an e-Business system is - e-Business is about collaborative working and leveraging shared resources. You need a car ferry and the W3C schema is a row-boat. Cheers, DW =========================================================================== Michael.Roytman@vertexinc.com wrote: >David, > >If the schemas are used as a reference implementation and a specification >the documentation for the developers and testers may be generated directly >from the schema. I realize that there are data dictionaries, repositories, >etc. However, if the schema is intended to be a self-contained source of >XML message information it may be worthwhile to put the documentation into >the schema. I think that production of reference documentation is a very >time consuming process and if we choose to keep the details in the schemas >could become a push of a button. > >The path from the "design-time" to "run-time" schema is very simple, since >it is only removal of documentation tags. > >Regards, > >Michael Roytman. > > >|---------+----------------------------> >| | "David RR Webber"| >| | <david@drrw.info>| >| | | >| | 10/14/2004 08:37 | >| | PM | >| | | >|---------+----------------------------> > > -------------------------------------------------------------------------------------------------------------------------------| > | | > | To: "Ram Kumar" <RKumar@msi.com.au>, <Michael.Roytman@vertexinc.com> | > | cc: <ciq@lists.oasis-open.org>, "Rob Beauchamp" <Rbeauchamp@Initiatesystems.com> | > | Subject: Re: [ciq] FW: UBL Address format vs. CIQ | > > -------------------------------------------------------------------------------------------------------------------------------| > > > > >Micheal, > >I just saw your note below about adding xsd:documentation tags to every >element. > >That is truely insane! No wonder they use "stripped down" schemas for >production. > >But why bother when you do not have to?!? > >The CAM template approach allows you to move that away from the schema >itself >into the registry layer - where it belongs. > >I'll post the CAM document with example nouns that allows this to happen. >We're >integrating this into jCAM and Registry right now - so give it a couple of >weeks >and you will be able to download this from the jCAM sourceforge site and >run >it. > >That will save you a shed load of time too - since we're finding you can >build these >noun XML entries straight out of your dictionary database with a simple SQL >script. Martin already have several hundred UK Telecomm domain elements >done this way. > >Thanks, DW > >----- Original Message ----- >From: "Ram Kumar" <RKumar@msi.com.au> >To: <Michael.Roytman@vertexinc.com> >Cc: <ciq@lists.oasis-open.org>; "Rob Beauchamp" ><Rbeauchamp@Initiatesystems.com> >Sent: Thursday, October 14, 2004 5:59 PM >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 >> >> >> >> >> >> >> > >To unsubscribe from this mailing list (and be removed from the roster of >the >OASIS TC), go to >http://www.oasis-open.org/apps/org/workgroup/ciq/members/leave_workgroup.php >. > > > > > > > > > >To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ciq/members/leave_workgroup.php . > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]