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: Minutes CIQ confcall 2001/02/22,plus initial breakdown planning V0.5


Vincent

> Let me give what I believe is a chronological list of actions
> to be taken
> until the release, plus a rough estimate of required lapse time:

> - Expand GlobalAddress with finer grained elements (VB, 1.5 week)

> - Integrate GlobalAddress and NAML spec/DTD into xNAL (RK,
> VB, 2 weeks)

Agreed. If you can change your DTDs to include all the necessary elements
that are
missing when compared with NAML (the address components only), we can then
use your DTD as the DTD for xNAL (address component only). Just a
suggestion. We can work closely
on getting this done. The important feature of xNAL is flexibility, ie.,
provide options for
representing the data at a higher level or at a detailed level with optional
tags. For example,

23 Archer Street
Boulder, Colorado 103445

should be represented in xNAL as either

<address>
23 Archer Street
Boulder, Colorado 103445
</address>

OR

<address>
    <street number>23</street number> <street name>Archer</street name>
<street type>Street</street type>
    <town>Boulder</town>
    <state>Colorado</state>
    <postcode>103445</postcode>
<address>

The tags in the latter should also be optional wherever necessary.

> - Discuss and decide on name vs. address position in xNAL
> specification (VB,
> RK, 1 week)

One possible solution will be to have two DTDs for xNAL, one for name and
one for address. This is just a suggestion. By doing this, it makes things
easier
when it comes to maintainability and usage. Name structures vary between
country to
country as addresses though not complicated as addresses.

The question we have is whether some organisation names should be part of an
address.
For example, large mail users such as postal companies, hospitals and
airports with their
own post code. Another example is c/o (care of). Is "care of" part of
address or part of name
is the other question. It makes sense to have it as part of address.
Therefore, it appears that
sometimes organisation names/personal names become part of an address. Eg.

Singapore Airport
PO Box: 12345
Singapore

Ram Kumar
c/o MasterSoft International
PO Box: 123, Chatswood, NSW 2067

Master Craig Smith
c/o Peter Smith
23 Archer Street
Boulder, Colorado 103355

In some countries, they have d/o or s/o etc. where d/o represents "daughter
of"
and s/o represents "son of".

Therefore, it appears that we have to cater for entering an organisation
name or a person name
in the address section as well. But detailed representation of these names
(breaking them into first,middle,
surname, organisation type, etc) are not necessary in the address section. I
welcome your comments.

We also need to think about names of some of the tags in xNAL. The names
should make sense to various
applications that will use name and address.

> - Adapt pre-GlobalAddress sample data (still in proprietary
> AND format) to
> the finalized xNAL spec (VB, RK, 2 weeks)

> - Adapt xNAL documentation to final spec (RK, VB, 2 weeks)

The xNAL document is now OASIS specific and does not have any reference to
NAML or MSI or Global Address or AND.

> - Add security chapter to documentation (RK, JB, 1 week)

Do we need this in the xNAL specifications and if so, what value does it
add?

> - Internal CIQ review period DTD, samples, documentation +
> write release
> announcement etc. (RK, VB, JB, 1 week)
>
> Given that some activities can be done in parallel, release
> of v0.5 is at
> least 6 weeks out according to my estimate. These times may
> look long, but I
> find them very realistic and maybe even on the short side
> given that every
> round-trip e-mail exchange takes at least a full day. Any
> shortening of
> these times may only be achieved by doing more work in
> "splendid isolation",
> but IMO this would only lead to more fundamental discussions
> *after* the
> work has been done (taking even more time for changes).

>
> Last but not least, in none of the conversations we have
> discussed in detail
> what we will do with xCIL. I would not be happy to release
> xCIL as a 1:1
> copy of CIML before I have had the time to compare it with at
> least the OTA
> spec myself. Also, checking and changing all CIML
> documentation to make them
> xCIL takes time.

I am glad for someone to have a look at CIML. It does not take much time
to change CIML to xCIL as there is no integration issue like xNAL.

>
> We agreed during the last call that we should have a new
> meeting in two
> weeks - as I've spent most of this time in bed, could we
> postpone this call
> until early next week? Any day would be fine with me.

done. March 14, 2001 (your day) and March 15, my day.

Regards

Ram

>
> Best regards,
> Vincent
>
>
>
> 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