Re: tightening element adr

[Frank_Dawson@xxxxxxxxx]

Actually, the values for the Adr element type content particles are parsable character data. The \n is parsable. No problem. But agree that if the intent is to convey multiple instances of the address component, then having multiple element types for the component is better.

About multiple locality, region, pcode and country. We don't want to provide any greater functionality than that provided in standard vCard, as defined in RFC 2426. This spec specifies:

adr-value    = 0*6(text-value ";") text-value
       ; PO Box, Extended Address, Street, Locality, Region, Postal
       ; Code, Country Name

Where text-value is specified as:

text-value-list      = 1*text-value *("," 1*text-value)

So, stictly speaking, the ability for multiple locality, region, pcode and country is correct. Let remember, we are defining a different semantic here than in the RFC. I do agree, though, that having multiple of these address components does not make much sense, as it would for Extended Address or Street components.

Maybe we need to fix the ABNF in the RFC 2426? I know of no implementation that will support multiple locality, region, pcode and country values.

-- Frank