[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ciq] CIQ using UBL NDR?
CIQ TC,
What I am hearing is that many of us do not want to have the xsd:Any attribute and
element in the new schemas. The best way to get this formalised is to call for a vote.
I will send a call for vote and PLEASE VOTE.
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: Mark Meadows [mailto:mmeadows@microsoft.com]
> Sent: Tuesday, October 19, 2004 9:39 PM
> To: Max Voskob; ciq@lists.oasis-open.org
> Subject: RE: [ciq] CIQ using UBL NDR?
>
>
> Max is right that the MSXML parser will understand the tag.
>
> I'm not educated enough yet on the matter to make a call on
> the UBL NDR issue specifically, but I agree 'xs:any' should
> be eliminated.
>
> My 2¢, and I never thought about it before this string
> started, but including 'xs:any' will require a lot of design
> time effort for anyone wanting to utilize our efforts.
>
> Best to eliminate if at all possible.
>
> Rgds,
> Mark
>
>
>
>
> -----Original Message-----
> From: Max Voskob [mailto:max.voskob@paradise.net.nz]
> Sent: Monday, October 18, 2004 11:24 PM
> To: ciq@lists.oasis-open.org
> Subject: RE: [ciq] CIQ using UBL NDR?
>
> Hido,
>
> Parsers from MS Windows part of the world handle it alright.
> I have never had any problems.
> What parsers exactly are you talking about?
>
> Cheers,
> Max
>
>
> -----Original Message-----
> From: Hido Hasimbegovic [mailto:hido.hasimbegovic@customware.net]
> Sent: Tuesday, 19 October 2004 15:53
> To: ciq@lists.oasis-open.org
> Subject: RE: [ciq] CIQ using UBL NDR?
>
> Hi Max
>
> I think both "xs:anyAttribute" and "xsd:any" should go.
> Implementation time, they cause no end to problems. Parsers
> will fail the schema unless instructed to ignore "violation
> of the unique particle attribute rule".
> From my experience, this element/attribute is more hassle
> then its worth.
>
> 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: Max Voskob [mailto:max.voskob@paradise.net.nz]
> Sent: Tuesday, 19 October 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?
>
> 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
> .
>
>
> 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]