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: CIQ Call



Ram, all,


> > For one, I believe that we should first discuss integration
> > of GlobalAddress
> > into NAML to make xNAL (I believe we would call it that,
> > right?), and leave
> > element-level discussions for later. Discussion topics there
> > would be how
> > tight the integration of Name (person or company) and Address
> > should be.
>
> Given that we are here talking about Customer Profile/Information
> Management,
> Name and address are the most important components.

Yes... and?


> > Your remark concerning our Firm element reinforces my belief here.
> > Firm/Company (I would prefer the neutral name Organization to
> > get the taste
> > of for-profit out) is an essential part of the postal
> information, but
> > whether this should be part of the address or moved into the
> > Name part is
> > open for discussion.
>
> We can discuss about this. The reason I question about firm
> is that the
> name of the firm that delivers mails must not be part of an address as
> it is part of the name component. When you look at NAML, the
> name component
> is separated out from address component. This helps
> organisations that deal "must not be part of".
> with only addresses (like yours) to standardise the addresses
> as there is
> no tight integration between name and address.

Ram, may I kindly request you choose your wording more carefully? We both
have an opinion, and I try to make mine sound like one. It does not help if
you pretend to have ownership to the truth, because that is what this sounds
like to me. If unintended -which I believe it to be-, please seek a way to
rephrase in the future and refrain from using "there is no" and "must not be
part of" without the proper context.

This issue is IMO important, and not because 'companies like mine' need some
place to store a name or something. The question here is what an address is,
and in my definition this is every bit of information that is required to
reach a certain entity (person or organization), either physically or by
sending mail. In many cases, in many countries, there are address formats
that do not allow for unique identification of a mail delivery point if the
name is omitted. Look at any address-definition reference book and you will
find examples where the name is tightly bound in the address. This makes IMO
the distinction between name and address rather artificial, and I would .


> > I even believe looking at it the other way around is easier: Take an
> > Address, and insert into that the naming information. This
> > would better
> > support automated address validation, as sometimes a name is
> > an essential
> > part of the address and sometimes it isn't.
>
> Well, there is no customer record that has only an address component
> and no name component. If there is an address without a name,
> probably,
> it will be a part of a postal reference/address file for
> address validation
> purposes. We have to be clear here that we are concentrating on
> managing CUSTOMER DATA/INFORMATION and therefore, name and
> address is crucial. Address validation tools can use our standard to
> represent
> the addresses in a standard way. But the intention of this
> standard is not
> to give priority to address validation process.

I believe you are putting words in my mouth, and I would dare say you are
missing the point here also. There is no discussion about whether a name is
important; I stressed its importance in my mail and find it even an
intricate part of an address, the biggest argument being my definition of an
address stated above. This is exactly the definition of GlobalAddress (no
surprise there I guess) which is for everybody to see, so I do not see why
you are reacting as if I would like to leave name out.

If one company is to define what a committee's intent is, there would be no
standardization at all...

May I take this opportunity to also suggest we start developing CIQ
documentation instead of producing more company-labeled documents? We now
have three contributions: ANDs, MSIs and the customer profile of the OTA and
we should focus on getting them together instead of producing updates of the
contributions. Would you agree?

Given the amount of work yet to do, and the expertise of the members
involved, may I suggest AND focus on the NAML part taking the AND and MSI
contributions, and MSI focus on the rest of the customer profile using their
own and the OTA contribution?


> >XML specification
> > languages are
> > still at their best describing hierarchical relations inward
> > (i.e. name
> > *within* address, and when it is mandatory). GlobalAddress
> > structure is
> > currently verifyable using DTDs or Schema and I would prefer
> > to keep it that
> > way.
>
> We need to discuss this.

Okay.


> > Good news is that I have received raw sample data for 36
> > countries from our
> > data department, which I need to seriously process before
> > release. I would
> > appreciate you (Ram) send some samples of NAML, as this would
> > aid in the
> > integration.

About the samples?


> > I would suggest the following topics for our call:
> >
> > - ebXML
> Low priority at the moment.

I agree with you that the team members do not have sufficient resources to
pursue this matter. Which, in my opinion, is different from whether it is
important or not.

I see this as VERY important regardless, because questions ARE being raised
(in the OTA for example, guys we would very much like to keep as friends) if
there is any coordination between CIQ and ebXML. I have no satisfactory
answer for them at this moment.

As suggested in my earlier mail I believe this is a role for OASIS
management and ebXML chairs to pick up, and I would appreciate very much if
Karl could suggest an appropriate course of action for this.


> > - CEN/UPU
> This is important.

Important, but not related in time to our current V0.5 development, so I
would say low(er) priority at this point.


> > - Integration of GlobalAddress and NAML and further detailed
> > timeline to
> > publication 0.5
>
> This is important

It is our reason for living! ;-)

>
> > - Use of Schema
> > - Security update
> Hope John has something for us.

Looking forward to that

>
> We also need to seek the help of OASIS in getting other
> organisations/groups
> working with us. I strongly believe that it is OASIS responsibility to
> approach there
> groups and promote our work to them to get their co-operation
> rather than
> the
> members of a TC running around and trying to get it touch
> with these groups.
> We
> will discuss about this in our meeting.

Could not agree with you more, Ram. Not to say we cannot and will not help
when appropriate and possible, such as meeting with CEN, but IMO there is a
responsibility with OASIS for coordinating with those organizations that
outgrow the scope of CIQ.

Adios!
Vince



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


Powered by eList eXpress LLC