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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ciq message

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


Subject: RE: OASIS CIQ - next iteration GlobalAddress / CIQ Address


Vincent

Just a few quick comments:

> Questions to be discussed:

> - Do we or don't we extensively specify values for types, such as
> "apartment", "lot", "pobox", "freepost" etc.? Suggestion:
> predefine a known
> list and allow an extension mechanism, for example using
> names preceded by
> an underscore character. For example: define "apartment" and allow
> "_cardboardbox".

I personally feel that this is dangerous because as such we do not know
how many values for types are available. Instead, if we provide them the
tag for type definition, customer can always wrap the value for types using
this tag and it makes it easy for them to process the data. Using attributes
in XML where we are not definite about the different values for it, always
restricts the language. This is my opinion. For example, let us say that we
have identified 50 possible values for a type. When we take this language to
all countries, we could end up with more than 300 values. This makes the
language complex.

> - The necessity to split street names further into main word, type
> ("street", "highway", "alley", "square", etc), etc. Wouldn't
> this just be of
> interest to address-buffs like us? I don't believe there's
> any customer db
> which has this level of granularity.
> - Same for postal number (pre- and postfix)

Well, not true. Infact, all our customers (blue chips namely, insurance,
govt. agencies,
Telcos., retail, etc) in Australia, NewZealand, USA and Canada store this
level of granularity
in their database to perform de-dup and validation and for data quality
audit purposes.
This level of granularity is needed by these companies. I, therefore
strongly uggest that we have
this granularity level in xNAL.

> - Like in NAML, I made it mandatory at every level to choose
> between using
> AddressLines or using the detailed elements. This would avoid
> inconsistencies between the two representation methods, but
> does anyone know
> a reason why you would want to do both?

Normally it is either or. Either detailed level or a higher level.
I do not see both are being used at the same time, but I could be wrong!

> - Addressee?

I am not clear about this question. Can you please explain further?

> - Organization: We do definitely need "LargeMailUser" but for
> the internal
> mail system we need something too. For example, the
> LargeMailUser could be
> the US Armed Forces in Europe - how is an addressee further
> identified. By
> his name + army unit I would say (not having experience in
> this)? The AND
> GlobalAddress spec until now stopped with its definition
> where the postal
> authority responsibility ended, but we need this further spec.

Agreed. We have to work on this.

I will get back with more feedback after having gone through the specs.

Regards

Ram
>
> As said, there are also some questions that I have to forward
> internally to
> our address experts - I will get back on that.
>
>
> Regards,
>
>
> Vincent Buller
> AND Data Solutions B.V.
> Product Development
> P.O. Box 29134
> 3001 GC Rotterdam
> The Netherlands
> -------------------------------------
> Telephone +31 (0)10 8851345
> Fax            +31 (0)10 8851300
> -------------------------------------
> Email: vincent.buller@and.com
> URL: http://www.and.com/
>
>
>



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


Powered by eList eXpress LLC