[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ciq] Closing date for review of CIQ Specs. V3.0 due 16 January 2006
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]