[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ciq] CIQ using UBL NDR?
CIQ TC,
> -----Original Message-----
> From: Max Voskob [mailto:max.voskob@paradise.net.nz]
> Sent: Tuesday, October 19, 2004 12:46 PM
> To: ciq@lists.oasis-open.org
> Subject: RE: [ciq] CIQ using UBL NDR?
>
> Hido, do u think we should get rid of xs:anyAttribute as well?
The more I hear about the drawbacks of xsd:any attribute and element
with regards to interoperability, the more I am tempted to get rid of
these from the schemas and make it more restrictive. I think this is
not a bad idea. Any views on this?
I am also not happy with the "free text lines" used.
But there is no way we can get rid of it because most of the data
contain
unparsed data fields that must be suported somehow. Atleast, with this
element, any unsuported data fields by xNAL can be represented using
this
element. Any views on this?
Ram
>
> Cheers,
> Max
>
> -----Original Message-----
> From: Hido Hasimbegovic [mailto:hido.hasimbegovic@customware.net]
> Sent: Tuesday, 19 October 2004 12:28
> To: 'Ram Kumar'
> Cc: ciq@lists.oasis-open.org; 'Rob Beauchamp'
> Subject: RE: [ciq] CIQ using UBL NDR?
>
> I think the idea is definitely worth pursuing. I would
> personally not mind getting rid of "xsd:any"
> element in any case! In my opinion this is not the right way
> to improve flexibility of schemas. It also breaks one of the
> XSD schema rules ("violation of the unique particle
> attribution rule").
>
> There's two things we can do:
>
> 1. Perform the gap analysis between the two standards and
> identify which areas need changing. Again, I don't think that
> absence of "xsd:any" elements and attributes will be such a
> big impact.
>
> 2. Analyse applicability of CAM to the problem. In addition
> to templates, CAM requires implementation of compiler to
> support translation of data from one schema to another. It
> seems to me it's more of a mapping specification/tool, than a
> data dictionary/schema itself. Perhaps I'm wrong, but we
> should put it to the test, especially with all the info
> kindly provided by David Webber.
>
> I look forward to generating some robust debate around this
> issue. I think this is a good opportunity to encourage wider
> adoption of CIQ schemas by working together with UBL. At the
> same time, we should not loose the sight of enabling other
> schemas to use/incorporate CIQ schemas.
>
>
> Regards,
>
> --
> Hido Hasimbegovic
> eBusiness Consultant | CustomWare Asia Pacific | www.customware.net
> T: +61-3-9667-0124 | F: +61-3-9663-2616 | M: +61-416-174-453
> Level 2, 222 Latrobe Street Melbourne VIC 3000 Australia
>
> Improve the quality of your services with WmUnit
>
> Unit testing framework for WebMethods http://www.customware.net/WmUnit
>
>
>
> -----Original Message-----
> From: Ram Kumar [mailto:RKumar@msi.com.au]
> Sent: Monday, 18 October 2004 5:12 PM
> Cc: ciq@lists.oasis-open.org; Rob Beauchamp
> Subject: [ciq] CIQ using UBL NDR?
> Importance: High
>
> CIQ TC,
>
> I am keen to know what decision we have to take regarding
> seriously looking into modifying our schemas to be
> compatibile with UBL NDR. There are some significant impacts
> to xNAL due to this and one of them is the use of "xsd:any"
> element and attribute. We use this in our schemas whereas,
> UBL strongly advocates against it.
>
> The best way to make a decision regarding whether we want to
> move towards the direction of UBL NDR for our V3.0 is to call
> for a vote.
>
> Please let me know your views.
>
> 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.
>
>
>
> 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]