[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
Regards,
=20
--
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
=20
Improve the quality of your services with WmUnit
=20
Unit testing framework for WebMethods http://www.customware.net/WmUnit
=20
=20
=20
-----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.=20
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.=20
Regards,
=20
--
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
=20
Improve the quality of your services with WmUnit
=20
Unit testing framework for WebMethods http://www.customware.net/WmUnit
=20
=20
=20
-----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.=20
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=20
=20
> -----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
>=20
>=20
> CIQ TC,
>=20
> here are the updated versions of xNL-Basic and xNL-Advanced that I=20
> 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=20
> have
> not made the change since I, personally, do not like abbreviations.
> There is a partyNameKey attribute, which I think should be renamed=20
> 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,=20
> but
> anyway
> The biggest impact will be the xsd:documentation that needs to be
> assigned to every element, complex type, attribute group, etc. I=20
> have
> not done that yet, since we need to agree that this is indeed the=20
> level
> of details we want to specify in the schemas. Moreover, UBL calls=20
> for
> "run-time" versions of schemas with the documentation stripped=20
> down. Any
> thoughts?
>=20
> I probably missed a few NDRs here, but since we do not have the=20
> hierarchy of code lists (or do we?), the final document rules=20
> (Invoice, TaxFiling,
> InsuranceClaim) do not apply to CIQ.
> Comments and questions are welcome.
> Best regards,
>=20
> Michael Roytman.
>=20
> (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)
>=20
>=20
>=20
>=20
> |---------+---------------------------->
> | | "Ram Kumar" |
> | | <RKumar@msi.com.a|
> | | u> |
> | | |
> | | 10/12/2004 08:44 |
> | | PM |
> | | |
> |---------+---------------------------->
> =20
> >-------------------------------------------------------------
> ------------------------------------------------------------------|
> | =20
> |
> | To: <ciq@lists.oasis-open.org> =20
> |
> | cc: "Rob Beauchamp"=20
> <Rbeauchamp@Initiatesystems.com> =20
> |
> | Subject: [ciq] FW: UBL Address format vs. CIQ =20
> |
> =20
> >-------------------------------------------------------------
> ------------------------------------------------------------------|
>=20
>=20
>=20
>=20
> CIQ TC,
>=20
> FYI regarding UBL and CIQ from Tim McGrath of UBL.
>=20
> Michael,
>=20
> You have promised to look into the compatibility between NDR of UBL=20
> and CIQ. Can you please advise of your progress on this? Thanks.
>=20
> Regards,
>=20
> Ram
>=20
> 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
>=20
>=20
>=20
> 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
>=20
> 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=20
> necessarily that of the UBL technical committee.
>=20
> personally, i had thought UBL had shifted towards xNAL not away from=20
> it.
> perhaps you can give some examples? we deliberately include the xNAL=20
> terms as synonymous business terms in our library.
> in fact, we have had a continuous dialogue with the CIQ team=20
> throughout UBL's development. you may also be aware that CIQ are not=20
> 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=20
> our own team of ontologists.
>=20
> you mention UBL's flexibility. we have tried to take an 80/20=20
> approach to business requirements. we know that very few implementors =
> will be able to use UBL without some form of customization. we have=20
> tried to provide a common base on which these customization are built.
> this is important to the points that follow.
>=20
> the main issues why UBL could not simply 'use xNAL' are:
> * xNAL does not define a single address structure. it is a rich=20
> vocabulary that can be used to structure various different forms of=20
> addressing. two parties using xNAL may not have any more=20
> 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=20
> the same as NZ Government, etc., etc..
> * xNAL sometimes uses the concept of qualifying values for its=20
> semantic names. you mention thoroughfare and this is a case in point.
> unless parties subsequently agreed how to qualify thoroughfare - they=20
> 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=20
> this approach recreates the problems people had with EDI-based=20
> vocabularies.
> * the requirement for addresses in UBL is not simply for postal=20
> 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=20
> naming and design rules. the technical people in UBL tell me this=20
> would make using actual xNAL schemas difficult and UBL would have to=20
> recreate xNAL in its own schemas. we then have a maintenance issue=20
> with keeping synchronized into the future.
>=20
> 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=20
> in a UBL document to something equivalent in an xNAL format and vice=20
> versa. To this end UBL provides the equivalent xNAL terms in our=20
> model (something we dont do for any other vocabulary). but as you=20
> point out this is not a clean map - today.
>=20
> looking forward, i am aware that the CIQ team are considering using=20
> UBL's XML naming and design rules for future releases.
> this will resolve at least one the issues above.
>=20
> personally, i am a supporter of the work of the CIQ team and would=20
> 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=20
> Kumar, the chair of the CIQ team, in two weeks time and we shall=20
> certainly be talking about these issues.
>=20
>=20
> PS
> i hope i am not being presumptuous by including Ram and Jon in this=20
> response. i think they both have an interest in the matter.
>=20
> Colin.Wallis@ssc.govt.nz wrote:
> Hi Tim
>=20
> I got your contact details from Jon Bosak. Jon and I talked on=20
> the
> phone at the recent e-gov OASIS meeting.
>=20
> I expressed some concerns around the shift from the early UBL=20
> drafts
> which used CIQ exclusively, to V1 where some of those element=20
> names
> have been replaced. Also I am not sure if any testing of UBL=20
> address
> structures against UPU address structures has been done.
>=20
> I know terms like "thoroughfare" are not the most user friendly=20
> and
> in NZ where xNAL is mandatory for government agencies data=20
> exchange
> we have had heated discussions on such issues. That said, we=20
> have
> stuck to it because there is logic in it, after you have used=20
> CIQ for
> a while. Even in our own environment, there are addresses which=20
> do
> not easily (semantically) fit UBL's "StreetType" and you would=20
> find
> that in OZ too before even looking elsewhere in the world.
>=20
> I know UBL is flexible enough to pretty much put whatever=20
> elements
> you want in there, but it becomes a real pain getting that=20
> agreement
> across a whole spectrum of parties, altering parsers to suit etc =
> etc.
>=20
> I don't know how much deep thought was put into this change and=20
> if it
> is irreversible?
>=20
> That said, I fully support UBL and what it is trying to achieve.
>=20
> But I have to raise this issue as it will potentially hamper the =
> rate
> of adoption in NZ govt.
>=20
> Cheers
>=20
> Colin
>=20
> Colin Wallis
> e-GIF Business Analyst
> e-Government Unit - State Services Commission
> T: 04 495 6758
>=20
>=20
> http://www.e-government.govt.nz
>=20
>=20
>=20
>=20
> --
> regards
> tim mcgrath
> phone: +618 93352228
> postal: po box 1289 fremantle western australia 6160
>=20
>=20
>=20
>=20
>=20
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]