[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ciq] FW: UBL Address format vs. CIQ
Michael, Indeed - herding the cats is never easy. I was feeling bad about shooting the messenger here! I'm still learning about the UBL side too - so your notes have been really helpful. We've been working this for five plus years now - so patience is definately needed in having people understand and learning only incrementally. Every now and again you feel like the vulture on the fence - "To heck with it I'm going to go out and kill something today!". Thanks, DW ================================================ Michael.Roytman@vertexinc.com wrote: >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]