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: CIQ action plan


Hi Ram,

AND has a generic address DTD which supports already 80 countries, including
(one of) the most complex: the UK. It also encompasses the countries you
name (Australia, NZ, USA, Canada). I think we should use this definition as
our starting point for addresses, and insert it into your work.

I will have to finish some extra documentation on it before I would dare
send you our definition... :-) Trying to do this early next week. In the
meantime I will look at your latest DTDs and its use of addresses.

I believe we have to come up with a 0.5 version, joining both our
definitions, to send it out on the CIQ list before our meeting in December
to serve as a starting point there.

I fully agree with you that we need an extensible structure - and that we
need an evolutionary approach. We feel that our generic address structure
will serve all countries, and we need only minimal changes to serve not just
80 but all countries. I would suggest we further detail our ideas about an
evolutionary development before our December meeting also, and come up with
a joint plan.

Regards,

Vincent

From: Ramkumar [mailto:rkumar@msi.com.au]
Sent: Wednesday, October 25, 2000 3:07 PM
To: Vincent Buller
Subject: Fw: CIQ concall 25/26 Oct


----- Original Message -----
From: Vincent Buller <vincent.buller@and.com>
To: 'Ram Kumar' <rkumar@msi.com.au>
Sent: Wednesday, October 25, 2000 7:09 PM
Subject: RE: CIQ concall 25/26 Oct


> How do we start integrating our Address and Customer profile DTDs?

Vincent,

Let us concentrate on working with the name and address DTD first.
The current DTD called NAML covers Australia, USA, Canada and New Zealand
in greater detail. It handles different kinds of addresses in these
countries.
I suggest that we can do the following:
- Decide on different releases of the DTD (incremental development). Each
new
release must support new address structures. To do this we have to decide
on what countries we will support for each release. It will be very complex
if
we try to support all countries in one go.

FOR EXAMPLE, we can decide that we will release a DTD (V1.0) in March 2001
that
will support address structures of Australia, USA, Canada, NewZealand, UK,
Netherlands and Germany. V2.o will include Spain, Mexico, France,
Switzerland, etc.

The above is just an example of how we can break up our work.
This breakup will help us to concentrate on building
the DTD incrementally as address structures are very complex to work on in
one go.

Currently, I have up to date specs. on the DTD that I have developed. AND
can provide
me with the address structures of different countries that we decide on
(a document will be useful) and I can have a look at it to see how it can be
integrated
with the existing DTD.

We need some expertise on name structures in other countries too. If we
cannot find
the expertise, that is still fine. We will do our best to include the name
structures. Even if
it is incomplete, that is still fine. Once we release a DTD for public
comment, and once
people start using it/playing with it, we will get feedbacks on issues to be
addressed.
The beauty with XML is that the language is extendable and hence, feedback
can be
incorporated into the DTD without much difficulty.

At the same time, we will clearly define what the DTD is for and what it is
not for, what
sort of data it can handle and what it cannot, etc.

Please feel free to let me know your thoughts on this.

Regards

Ram



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


Powered by eList eXpress LLC