OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tax message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: AW: [tax] Groups - stfandciq.doc uploaded


Thank you, Ram, for your answer.

1. optional NameLine element in PersonName : I see your point, even if it is
difficult to imagine, what could be "forgotten" in the very complete
collection of name parts offered  by PersonName (and others). Still: is
NameLine really suggestive for the purpose that you explain? Anyway, I do
not think that we will really need that provision in STF.
2. When talking about "restriction" of PersonName I certainly did not want
to suggest any change in your standard. I just wanted to speak about the
technical process of a datatype restriction in XML Schema. I think it is a
perfectly natural use of a schema standard to restrict a datatype for use
within a defined area. 
3. regarding xAL: Yes, I have considered xAL. I mentioned my position in the
second paragraph of the "I propose" section. Whilst my complete and sincere
admiration is for the extensive coverage of all conceivable address
complexity, this is also the source of anxiety: For the time being I am just
too much of a coward to risk the acceptance of STF for this degree of
conceptual complexity (I do know the argument that one can stay as simple in
xAL instances as one desires, the complexity of concepts remains).

Kind regards

Arndt
-----Ursprüngliche Nachricht-----
Von: Michael.Roytman@vertexinc.com
[mailto:Michael.Roytman@vertexinc.com]
Gesendet am: Mittwoch, 16. Juli 2003 15:54
An: tax@lists.oasis-open.org
Cc: rkumar@msi.com.au
Betreff: RE: [tax] Groups - stfandciq.doc uploaded

Tax XML TC,

I had a look at the comments made in this document.
The reason why we had a free format part in a fixed
format/structure such as "PersonName" is because there
"could" potentially be some elements in the person name
that cannot be put under an element tag in xNL which we
might not be aware of. In such a  case, users can use the
free tag and assign a type to it.

Note that CIQ standards are flexible because of its positioning
as application independent standard. Some might use name and address
for a simple registration system (eg. address line 1, address line 2, etc)
Some might use it for complex applications such as name and address
parsing,
matching and validation. This requires breaking down name and address
string
into atomic elements. Moreover, an organisation might use name and address
data for various purposes (accounts, billing, marketing, validation, etc)
and ideally would prefer to have a single name and address standard in
their
organisation that they can use to support various applications. This is
also another reason why CIQ standards have been designed to be flexible.
Therefore, my personal suggestion is not to consider restricting xNL from
the perspective of Tax related data only.

What about xAL? Have you considered it?

Regards,

Ram Kumar
CIQ TC



You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/tax/members/leave_workgroup.php


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]