RE: [ciq] Re: *SPAM* Re: [ciq] Closing date for review of CIQ Specs. V3.

Subject: RE: [ciq] Re: *SPAM* Re: [ciq] Closing date for review of CIQ Specs. V3.0 d ue 16 Janua ry 2006

On 2/8/06, Colin.Wallis@ssc.govt.nz <Colin.Wallis@ssc.govt.nz> wrote:

Thanks Ram

You have "hit the nail on the head" re the interop concern.

I accept that perhaps I have not quite understood Michael's concern so please take that into account when reading the following:

We thought that one of the rationales for calling external namespaces was that "other committees" would only reference that part of CIQ that it wants; rather than trying to add complexity to CIQ itself. This is the notion of keeping it simple and interoperable. If you go down the Complex types track you are opening the door to mandating the need for a detailed interop/data exchange agreement with all of the hassle that involves and that leads to a multitude of "CIQ profiles". Now maybe that's no bad thing but that was where V2 was headed and that's what I thought we were heading away from..

Cheers

Colin

-----Original Message-----
From: Ram Kumar [mailto: kumar.sydney@gmail.com]
Sent: Tuesday, 7 February 2006 10:42 p.m.
To: Michael.Roytman@vertexinc.com
Cc: Max Voskob; ciq@lists.oasis-open.org
Subject: *SPAM* Re: [ciq] Closing date for review of CIQ Specs. V3.0 due 16 Janua ry 2006

Michael has raised valid points here. We can always make the elements as complex

types for reusability. But at the same time, we have to clearly state in our documentation how this could lead to interoperability problems if the structure of the schemas is broken which will make it a non CIQ standard. One can always extend CIQ with a new structure, but at a cost, which is, CIQ standard then becomes a non standard.

Max,

If you want to add your views, please do so.

Regards,

Ram

On 2/7/06, Michael.Roytman@vertexinc.com <Michael.Roytman@vertexinc.com > wrote:

I must be missing something here. What interoperability would be diminished if CIQ would offer complex types, which could be used by other committees? I am of the opinion that if something is not easily reusable, like types, it would lead a user to creation of their own, CIQ-like, components. I would consider that to be a really undesirable turn of events. No reason to fight here ;+)

-----"Max Voskob" <max.voskob@paradise.net.nz> wrote: -----

To: <ciq@lists.oasis-open.org>
From: "Max Voskob" < max.voskob@paradise.net.nz>
Date: 02/06/2006 04:46PM

Subject: RE: [ciq] Closing date for review of CIQ Specs. V3.0 due 16 Janua ry 2006

Just trying to find a centreground :-)

-----Original Message-----
From: Colin.Wallis@ssc.govt.nz [mailto: Colin.Wallis@ssc.govt.nz]
Sent: Tuesday, 7 February 2006 09:25
To: max.voskob@paradise.net.nz
Subject: RE: [ciq] Closing date for review of CIQ Specs. V3.0 due 16 Janua ry 2006

Thanks for fighting our corner Max:-)

Cheers

Colin
-----Original Message-----
From: Max Voskob [mailto: max.voskob@paradise.net.nz]
Sent: Tuesday, 7 February 2006 7:50 a.m.
To: ciq@lists.oasis-open.org
Subject: RE: [ciq] Closing date for review of CIQ Specs. V3.0 due 16 January 2006

Michael,

I appreciate you took time to reply.

The extensibility model that is proposed in the documentation, and the schema as well, is based on
the idea that anyone can add attributes from some other namespace, but no elements should be added
to the structure.
I understand that you also want to add elements.

We need to strike a balance here - extensibility vs. interoperability.
Adding new elements won't
help the latter.

Cheers,
Max

-----Original Message-----
From: Michael.Roytman@vertexinc.com [mailto:Michael.Roytman@vertexinc.com]
Sent: Tuesday, 7 February 2006 01:51
To: Ram Kumar
Cc: Max Voskob
Subject: Re: [ciq] Closing date for review of CIQ Specs. V3.0 due 16 January
2006

Gentlemen,

Sorry for the delayed response, I have been extremely busy lately. The basic
extensibility would be
provided if all structures are available as Complex/Simple types. As I
recall during the days of
first drafts for CIQ version 3, we had all components defined as types, with
corresponding global
elements that are then assembled into more comprehensive structures by
reference. In my opinion,
that would offer adequate flexibility for other business models, such as
tax.

As far as the grCommon1 is concerned, it could have been named grValidity,
grControl, grDuration, or
something like that.
I should have more time in the next couple of weeks and will try to be more
responsive if you have
any question or would like me to review the latest round of drafts.
Kind regards,

Michael.

|---------+---------------------------->
| | Ram Kumar |
| | <kumar.sydney@gma|
| | il.com> |
| | |
| | 02/06/2006 06:06 |
| | AM |
| | |
|---------+---------------------------->

>---------------------------------------------------------------------------
------------------------
----------------------------|
|
|
| To: Max Voskob <max.voskob@paradise.net.nz>
|
| cc: Michael.Roytman@vertexinc.com
|
| Subject: Re: [ciq] Closing date for review of CIQ Specs. V3.0 due
16 January 2006
|

>---------------------------------------------------------------------------
------------------------
----------------------------|

Michael,

If you can respond to Max's questions, Max can then complete the revision of
the schemas and we
should be in a position to go to the next stage.

Thanks,

Regards

Ram

On 2/2/06, Max Voskob < max.voskob@paradise.net.nz> wrote:
Michael,

I started fixing the spec and schemas, but need some more feedback from you.

- Extending Nationalities -
What kind of extension do you have in mind?
We don't encourage adding elements as an extension mechanism. Adding
attributes is fine tho.
What solution would be best for your situation? E.g. making those top-level
elements named complext
types?

Any suggestion for a better name for grCommon1?

Cheers,
Max

-----Original Message-----
From: Michael.Roytman@vertexinc.com [mailto: Michael.Roytman@vertexinc.com]
Sent: Wednesday, 18 January 2006 05:07
To: Ram Kumar
Cc: ciq@lists.oasis-open.org
Subject: Re: [ciq] Closing date for review of CIQ Specs. V3.0 due 16 January
2006

Ram,

I will echo Joe's comments related to parsing of lower level elements and
overall XML Schema
structures. I have been looking at CIQ as being a set of "core" components
for names, addresses,
relationships and how these could be used to create structures within Tax
XML. As an example I will
use Tax XML Certificate of Residence project, which requires a standard name
of an individual,
birthday, nationality, current residence address. For the most part I will
be able to use the
PartyNameType, BirthInfo element, and AddressType to get most of the
structure, but Nationalities is
a bit trickier. It is a container, and an element, so I have to reference
it, which will not allow
me to extend it.

Also, grCommon1 could have a more meaningful name, like grDataQuality. The
types listed are code
lists/enumerations and could have been named as such.

Overall, the structures do look easier to navigate and learn, but a lot of
testing by various
business groups will be necessary to achieve expected flexibility and reuse.
Thanks,

Michael Roytman.

|---------+---------------------------->
| | "Joe Lubenow" |
| | <lubenow@msn.com>|
| | |
| | 01/16/2006 02:31 |
| | AM |
| | |
|---------+---------------------------->

>
----------------------------------------------------------------------------
-----------------------

----------------------------|
|
|
| To: < ciq@lists.oasis-open.org>, "Ram Kumar" <
kumar.sydney@gmail.com>
|
| cc:
|
| Subject: Re: [ciq] Closing date for review of CIQ Specs. V3.0
| due
16 January 2006
|

>
----------------------------------------------------------------------------
-----------------------

----------------------------|

Ram,

Here are some comments on version 3.0 as you requested.

On the whole, it does seem simpler than the previous version and yet able to
handle complicated
examples. There are numerous examples provided, and as a general rule the
mappings seem quite
sensible.

The documentation is very fair to point out that an unparsed field cannot be
assigned to lower level
elements without parsing using rules that are outside of the scope. But as
you state, often it is
simple to combine lower level elements into a single higher level element.
In view of this, it
perhaps should be explicitly stated that achieving interoperability may be
facilitated by having a
strong parsing capability and using lower level elements where possible.

A potential difficulty exists when a region is used for both a region within
a country and a
multi-country region. See the example from Grenada for this. It would be
helpful to distinguish
between these two situations because a region within a country generally
comes before the country
name, while a multi-country region generally comes after the country name.

The example from Saudi Arabia assigns "Diplomatic Quarter" to Premises, but
perhaps this should be a
Locality.

The examples from the Russian Federation and Ukraine seem inconsistent. In
the Ukraine example a
raion (r-n) is a district and an oblast (obl) is a region. But in the
Russian Federation example
these assignments are reversed.

Some addresses in Australia, such as Unit 12, 23 Archer Street, can also be
written in a more
compact form as 12/23 Archer Street. In this case, users of the
specification might map the whole
line to thoroughfare, or they might map 12 as a premise number. There does
not seem to be an easy
way to achieve uniformity in this sort of practice, and clearly it could
have an effect on the
success of de-duplication.

In a specifically postal context, many postal services do not want to see
multiple delivery points
in the same address, such as a post office box and a street address. These
are often not just
different delivery points, but do not even have the same postal code. In
such a situation the
notion of validity is ambiguous. A possible example of this in your sample
addresses is
Switzerland. However, such addresses are frequently observed, so the
example is not erroneous.

In the overview you refer to the GCA and IDEAlliance and the ADIS
specification. It has now been
four years since the GCA became IDEAlliance, so you might drop the reference
to GCA. But more
important, it is not correct to say, as you currently do, that the UPU has
approved ADIS. Rather,
you could say that ADIS shares some features with the UPU standard.

Thanks for the opportunity to comment.

Joe Lubenow

----- Original Message -----
From: Ram Kumar
To: ciq@lists.oasis-open.org
Sent: Sunday, January 15, 2006 7:00 PM
Subject: [ciq] Closing date for review of CIQ Specs. V3.0 due 16 January
2006

CIQ TC,

This is a reminder regarding the review of CIQ TC Specs. V3.0.
The reviews must be completed by 16 January 2006 as we need to move to the
next stage, i.e. vote on
the specs. for approval as a committee specs./draft.

Thanks

Regards,

Ram

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a
link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a
link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

ciq message