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