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: Review of GobalAddress Spec.


Hi Vincent

Please e-mail me the latest DTD of GlobalAddress.

I had reviewed the GlobalAddress spec. Given that we have decided
to convert the existing GlobalAddress spec. into xNAL (the address part)
by also including the information in NAML that are missing in the
GlobalAddress spec.,
following are the issues that needs to be addressed in GlobalAddress spec.:

- The documentation needs more work. We need examples for each sections.
It is easy for address experts to understand what the documentation says.
But
it could be difficult for non-address experts to understand the contents
unless
we provide enough examples. Every element spec. needs an example to make it
easier to
understand.

-Page 11: GlobalAddress

I suggest we change this element to "CustomerAddressDetails".
For name, I have the root element as "CustomerNameDetails" in xNL
In xCIL, I have the root element as"CustomerDetails". The word "Customer"
means an "organisation" or a "person".

<xCIL>
    <CustomerDetails>
      <xNL>
           <CustomerNameDetails>
                <xAL>
                     <CustomerAddressDetails>
                     </CustomerAddressDetails>
                </xAL>
           </CustomerNameDetails>
      </xNL>
    ........... <--- other customer details here (other than name and
address)
    </CustomerDetails>
</xCIL>


- Page 11: Element Specification - Country

CountryCode should be 0...n instead of 1...n because
many customers DO NOT have country code in their data and we
cannot force them to include Country Code. Infact, Country code is
never in use in Australia, NZ, and Asian countries.

- Page 12 : AdministratoveArea

Under "Additional Notes", we definitely need examples for each points.
I tried to understand it, but it is complex.

- Page 14: Locality

I do not know what PremiseNoStreet element means as there is no explanation
for it.

Regarding Postcode and ExtendedPostcode, can you have an extended postcode
without
a postcode? Both are defined as exclusive or. I am sure you can have
postcode without
extended postcode but not vice versa. You can also have both postcode and
extended
postcode. Please clarify this.
eg. USA Address: CO 12345-1234 or CO 12345 are valid , but not CO 1234

The description of the Specification table for Postcode says, "See the
section "Postcode usage".
I cannot find such section in the document.

- Page 17: PostBox

We need prefix and suffix elements for postbox number as NAML supports it
because there
are customers with such data.

- Page 18: Street

What is the porpose of "Firm" in Street? Can you please give examples.
We need the following elements to be supported as NAML supports them and
there are
customers with these data elements in their DB:
- StreetType  (RD, ST, LANE...)
- StreetTypePrefix (STATE in 5 STATE HIGHWAY)
- StreetNumber (23 in 23 Archer St)
- StreetNumberSuffix (A in 23A of 23A Archer Street)
- StreetPredirection (NORTH in NORTH ARCHER STREET)
- LeadingStreetType (Spanish term AVENIDA in the street VANENIDA AURORA,
                                or the French term RUE in the street RUE
MOLIERE)
- StreetPostDirection (EAST in ARCHER STREET EAST)
- StreetPostName (DAVID EDGEWORTH in AVENUE OF DAVID EDGEWORTH)

Global Address Spec. supports dependent streets. That is fine. For example,
CNR of Archer and Stanley Street, Intersection of Archer and Stanley Street.

We need a Street Type for the dependent street that can tell what type it
is.
NAML supports this as there are customers with these data elements.
Eg. CNR, INTERSECTION, etc).

- Page 20: Premise

Why cannot we make PremiseNumber and PremiseName as separate elements
rather than being xor? We can get rid of BuildingName in such a case.
Therefore,
I am not clear with the rules 1 and 2 in "Additional notes" of Page 21. Why
canot
we store the name of the building/house under PremiseName if PremiseName and
PremiseNumber are considered as separate optional elements?

We need to change the element name "SecondaryStreetString" to something
else.

We need another element under "Premise" called PremiseType to define the
type
of premise, eg. House, Building Complex, etc.

What is the purpose of "Firm" in Premise? We need an example for this.

-Page 21: SubPremise

NAML support SubPremiseNumberSuffix and SubPremiseNumberPrefix as there
are customers with these data. Eg. SUITE 23A, SUITE A23,....

How can I define in XML using GlobalAddress for the following address
that is very common in Australia?

BLOCK A, LEVEL 2, SUITE 1, 23 ARCHER STREET

-Page 22: Postcode

The specification is incomplete and is not clear.

- How can I define the following addresses in XML using GlobalAddress
spec.

BUILDING 2, LEVEL 2, ROOM 3
WESTFIEID SHOPPING TOWN
NEAR HORNSBY RAILWAY STATION
HORNSBY
NSW 2072

23 Karpam Nagar
Kottivakkam
Via-Thiruvanmiyur
Chennai 600041

The above address is common in countries like Australia, NZ, Asia

In NAML, we have elemengts called Major Place and Minor Place where
'Westfield shopping town' is major place and 'hornsby raiway station' is
minor place.

Can you please send me some documentation with examples on
PAB, AddressLines/AddressLines elements as they are not covered in the spec.

I am not sure whether I have listed all the questions. If I come across
more,
I will in my next e-mail.

Kind regards

Ram







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


Powered by eList eXpress LLC