Subject: [Geopriv] Multiple instances of some components in a PIDF-LO

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 5 Apr 2013 15:07:50 +0000

In 5139, the basic civic location elements are defined like:

         <xs:element name="LMK" type="ca:caType" minOccurs="0"/>

Since maxOccurs is not specified, it defaults to 1.

In a field like LMK, there is often more than one name a location is known as.  This also occurs, at least in the U.S. in A4 and A5.  Place type is another one.  There isn't any significant downside to allowing more than one of these elements, and more closely adheres to actual practice.

I'd like to get this fixed.

Brian

---

From: James Polk <[email-masked]>
Date: Fri, 05 Apr 2013 14:39:15 -0500

At 10:07 AM 4/5/2013, Rosen, Brian wrote:
>Content-Language: en-US
>Content-Type: multipart/alternative;
>         boundary="_000_289C5AF47B8C4B53801CBB9EDACD996Aneustarbiz_"
>
>In a field like LMK, there is often more than one name a location is 
>known as.  This also occurs, at least in the U.S. in A4 and 
>A5.  Place type is another one.  There isn't any significant 
>downside to allowing more than one of these elements, and more 
>closely adheres to actual practice.
>

ahhh... write a draft updating 4119 (and 5139 if needed)...

just a thought

;-)

-j

>Brian
>
>_______________________________________________
>Geopriv mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 5 Apr 2013 19:53:03 +0000

I'll do the draft, no problem, but I want to see if we have any significant objections.

Brian

---

From: Ted Hardie <[email-masked]>
Date: Fri, 5 Apr 2013 12:53:32 -0700

On Fri, Apr 5, 2013 at 8:07 AM, Rosen, Brian <[email-masked]>wrote:

> known as.  This also occurs, at least in the U.S. in A4 and A5.  Place type
> is another one.  There isn't any significant downside to allowing more than
> one of these elements, and more closely adheres to actual practice.
>
>
Can you describe the use case more clearly?  These are optional "vanity"
designations; in what case is having more than one necessary?  I recognize
that you may have conditions where the same address is both Yale College
and Yale University, but in the use cases I can see, you would be to solve
the problem with multiple CivicAddress complex types, each of which had a
different LMK.

For the A4 A5 designations, I worry that the identifier designations may be
linked (that is, "A4-1, A5-1" are valid and "A4-2, A5-2" are valid, but
"A4-2, A5-1" would be odd) in cases where you have multiple languages as
the source of the variation.  Again, that looks like more than one of the
top level complex type is a better idea.

What am I missing?

TEd

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 5 Apr 2013 20:05:36 +0000

An example of multiple LMKs is "Old North Church" and "St George Episcopal".  The former is what most people call it, the latter is the official name.

An example of multiple A5s would be "Green Acres", the name of a development, and "Moor Park", the generic neighborhood.  Neither is a subset of the other.

You clearly can have combinations that won't work.  But you can have a part of a neighborhood that is officially in one municipality and another part that is in another municipality.  That is the reality, and the data component should be able to represent reality.  A given location would have a combination that works.

We're working on the U.S. profile of PIDF.  We're working from the Federal Geographic Data Committee's technical standard that encodes U.S. addresses.  It permits multiple entries that I described, because there are actual examples of such addresses.  The standards don't have a "preferred" attribute that would let us create a subset.

Brian

On Apr 5, 2013, at 3:53 PM, Ted Hardie <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Apr 5, 2013 at 8:07 AM, Rosen, Brian <[email-masked]<mailto:[email-masked]>> wrote:
In 5139, the basic civic location elements are defined like:

Can you describe the use case more clearly?  These are optional "vanity" designations; in what case is having more than one necessary?  I recognize that you may have conditions where the same address is both Yale College and Yale University, but in the use cases I can see, you would be to solve the problem with multiple CivicAddress complex types, each of which had a different LMK.

For the A4 A5 designations, I worry that the identifier designations may be linked (that is, "A4-1, A5-1" are valid and "A4-2, A5-2" are valid, but "A4-2, A5-1" would be odd) in cases where you have multiple languages as the source of the variation.  Again, that looks like more than one of the top level complex type is a better idea.

What am I missing?

TEd

Brian

_______________________________________________
Geopriv mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/geopriv

---

From: Ted Hardie <[email-masked]>
Date: Fri, 5 Apr 2013 13:27:12 -0700

On Fri, Apr 5, 2013 at 1:05 PM, Rosen, Brian <[email-masked]>wrote:

>  An example of multiple LMKs is "Old North Church" and "St George
> Episcopal".  The former is what most people call it, the latter is the
> official name.
>
>  An example of multiple A5s would be "Green Acres", the name of a
> development, and "Moor Park", the generic neighborhood.  Neither is a
> subset of the other.
>
>
I still am missing how having multiple entries of the complex top level
type doesn't solve this problem.  If you have two entries which are alike
other than having two different LMK entries, what breaks?

>  You clearly can have combinations that won't work.  But you can have a
> part of a neighborhood that is officially in one municipality and another
> part that is in another municipality.  That is the reality, and the data
> component should be able to represent reality.  A given location would have
> a combination that works.
>
>
If I understand you correctly, this is beside the point; any individual
Civic Address is going to have the salient municipality.  It may or may not
have a neighbourhood listed in the A5 field.  That two municipalities both
have a neighbourhood of the same name isn't more important if they adjoin
than if they are widely separated.

I am somewhat concerned here because this change will break parsers that
expect a single entry of the types that are listed, and *we cannot change
them all* because some would nonsensical to have more than one.  So we'll
have to have a determination on a case-by-case basis, which means
separating parsing rules for each one.

regards,

Ted

>  We're working on the U.S. profile of PIDF.  We're working from the
> Federal Geographic Data Committee's technical standard that encodes U.S.
> addresses.  It permits multiple entries that I described, because there are
> actual examples of such addresses.  The standards don't have a "preferred"
> attribute that would let us create a subset.
>
>  Brian
>
>  On Apr 5, 2013, at 3:53 PM, Ted Hardie <[email-masked]> wrote:
>
> For the A4 A5 designations, I worry that the identifier designations may
> be linked (that is, "A4-1, A5-1" are valid and "A4-2, A5-2" are valid, but

---

From: Martin Thomson <[email-masked]>
Date: Fri, 5 Apr 2013 15:24:13 -0700

On 5 April 2013 13:27, Ted Hardie <[email-masked]> wrote:
> have to have a determination on a case-by-case basis, which means separating
> parsing rules for each one.

I share Ted's concern.  An update would probably break backward compatibility.

ALL of the implementations that I'm aware of would definitely break.

Is this just A5 & LMK, or is the problem systemic?

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 8 Apr 2013 06:14:08 +0800

Any changes to the base 5139 specification will break compatibility and this will certainly impact our implementations and I suspect most others including LoST. We spent the time to put together a document that defines how to extend the civic schema, why can't we just use that?

Cheers
James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Saturday, 6 April 2013 9:24 AM
To: Ted Hardie
Cc: [email-masked] WG; Rosen, Brian
Subject: Re: [Geopriv] Multiple instances of some components in a PIDF-LO

On 5 April 2013 13:27, Ted Hardie <[email-masked]> wrote:
> I am somewhat concerned here because this change will break parsers 
> that expect a single entry of the types that are listed, and *we 
> cannot change them all* because some would nonsensical to have more 
> than one.  So we'll have to have a determination on a case-by-case 
> basis, which means separating parsing rules for each one.

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 9 Apr 2013 15:18:16 +0000

We can't get ourselves into a position where no changes can be made that break backwards compatibility.   We can try to avoid it, but it's not a straightjacket.

In the U.S., it applies to A4, A5, LMK and PLC.  Other countries may have different needs.

The extension mechanism wouldn't let us change maxoccurs.

About the only think we could do is add an extension that carries other instances ("otherA5").  That would be really messy, especially if, as in our case, there aren't any values that are considered authoritative or preferred that would go in the original tag.

Brian

---

From: Martin Thomson <[email-masked]>
Date: Tue, 9 Apr 2013 09:12:18 -0700

> We can't get ourselves into a position where no changes can be made that break backwards compatibility.   We can try to avoid it, but it's not a straightjacket.

This is broadly true, though I would stipulate two restrictions on the
statement:

First, you explore options that do not break backwards compatibility.
That's not something I've seen happen here, you leap to a solution
that breaks compatibility as the first option.

Second, you provide strong motivation when you do decide to break
backwards compatibility.  Again, I'm not seeing any strong motivation.

Perhaps you considered the first and decided not to bother us with the
rationale; perhaps that provided you with sufficient motivation.

> In the U.S., it applies to A4, A5, LMK and PLC.  Other countries may have different needs.

I can see how LMK might need to double up, and can understand how
jurisdictional peculiarities would lead to A4 and A5 getting confused.

> The extension mechanism wouldn't let us change maxoccurs.

That's true, the extension mechanism does not.  This is true.  It does
open other avenues though, for example a delimited string.

> About the only think we could do is add an extension that carries other instances ("otherA5").  That would be really messy, especially if, as in our case, there aren't any values that are considere…

Messy is, to my mind, preferable to broken.

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 9 Apr 2013 16:30:35 +0000

I looked at alternatives before I proposed a change.  Didn't see one that wasn't an ugly hack. 

When we did PIDF-LO, we tried to determine what was needed to represent an address. We made mistakes in doing that.  This is one of them, a fundamental one.  We assumed that all fields always had only zero or one value.  That is wrong.  We're not extending something for a new use.   It's not an extension, it's correcting a mistake.  It's different from a field used in a single country, or a forgotten field.  

It's a pretty strong motivation to correct a mistake like this.  We have real addresses that can't be correctly represented.  The extension mechanism we have doesn't really work for this mistake.  We can always hack.

I would not propose to fix just these fields.  I'd allow maxoccurs to be unbounded in all fields, and let national profiles restrict it.  We know which fields need more instances for the U.S., but we don't know about other countries.

I do understand that we have implementations, but I think that we have very few of them, and I think fixing mistakes like this is better done right, before we have a lot of implementations.  I think that forcing a change like this to existing implementations is much better than forcing every subsequent implementation to handle a hack (at least in countries where this problem occurs).

Brian

---

From: Ted Hardie <[email-masked]>
Date: Tue, 9 Apr 2013 10:29:25 -0700

On Tue, Apr 9, 2013 at 9:30 AM, Rosen, Brian <[email-masked]>wrote:

"We assumed that all fields always had only zero or one value.  That is
wrong.  We're not extending something for a new use.   It's not an
extension, it's correcting a mistake.  It's different from a field used in
a single country, or a forgotten field. "

I disagree with this characterization.  I believe we set out to make
something that allows you to construct a valid civic address for a
particular location.  We never said, and nor do I believe, that any single
valid civic address for that location needs to be comprehensive in its
representation.  The example of multiple LMKs is a good example here--one
with a single landmark *is valid*; it's just not comprehensive.   In the
system as currently build, generating multiple pidf-lo style
representations to get you both "old North Church" and "St. George's
Episcopal" associated with the other parts of the civic address *does
work*.  It also can work better than a simple list of alternates where some
combinations work and some do not (as the language-based examples imply).

All of the examples you have given seem to me to permit the multiple
complex type solution.

I would not propose to fix just these fields.  I'd allow maxoccurs to be
> unbounded in all fields, and let national profiles restrict it.

I would strongly oppose this particular approach.  For one thing, what
national profile deals with maxoccurs greater than one for country?  If I
am willing to consider addresses in Hong Kong and Macao to also be in
China, which national profile says this okay:  Hong Kong's or China's?  For
another, it invalidates national profiles already built which may rely on
maxoccurs being 1, but which did not say so out loud at the time (because
they didn't need to).

>  We know which fields need more instances for the U.S., but we don't know
> about other countries.
>
>

> I do understand that we have implementations, but I think that we have
> very few of them, and I think fixing mistakes like this is better done
> right, before we have a lot of implementations.  I think that forcing a
> change like this to existing implementations is much better than forcing
> every subsequent implementation to handle a hack (at least in countries
> where this problem occurs).
>
>
As I said before, I think you need to have a draft.  Setting out the goals
clearly with a proposal will get you further than this thread as at least I
(bear of little brain that I am), still do not see what is driving you to
change from "valid location representation" to "valid, comprehensive
location representation"

regards,

Ted Hardie

> >> We can't get ourselves into a position where no changes can be made
> that break backwards compatibility.   We can try to avoid it, but it's not
> a straightjacket.
> >
> >> About the only think we could do is add an extension that carries other
> instances ("otherA5").  That would be really messy, especially if, as in
> our case, there aren't any values that are considered authoritative or
> preferred that would go in the original tag.
> >

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 9 Apr 2013 18:03:04 +0000

First of all, at least in the U.S., we have no combinations that don't "work" where others do "work".  If you had multiple A4s and multiple A5s in a single address, you any combination "works", in that it leads to a single unambiguous location.

It certainly is the case that some, maybe most, uses of PIDF-LO involve carrying enough information such that a recipient can uniquely identify the location of the sender.  In those use cases, any combination works.  It wouldn't be wrong to send more than one, but it's not necessary.  However, we often don't want to promote use of PIDF that contains enough information to uniquely identify a location, but no more.  For example, we might have both a Post Office name and a municipality (A3).  If there were only one instance of a particular street name in both the service area of the Post Office and the municipality, then sending either is sufficient to determine what is the address.

But in many use cases, that is not desired behavior, and specifically, when an authoritative entity sends a PIDF-LO, it wants to provide a COMPLETE specification of the location, not what is minimally acceptable.

If you are worried about country I could see restricting that to a single occurrence.  While there are cases where a single unique location can have multiple countries (disputed territory for example), in the cases I know about, there are significant differences in other fields, which would not be covered by this proposed change.  I suspect, but don't know, that the A1 label never has more than one value in every country.  A2, on the other hand, probably does, although I am not sure.

I will write a draft.

Brian

On Apr 9, 2013, at 1:29 PM, Ted Hardie <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Apr 9, 2013 at 9:30 AM, Rosen, Brian <[email-masked]<mailto:[email-masked]>> wrote:

"We assumed that all fields always had only zero or one value.  That is wrong.  We're not extending something for a new use.   It's not an extension, it's correcting a mistake.  It's different from a field used in a single country, or a forgotten field. "

I disagree with this characterization.  I believe we set out to make something that allows you to construct a valid civic address for a particular location.  We never said, and nor do I believe, that any single valid civic address for that location needs to be comprehensive in its representation.  The example of multiple LMKs is a good example here--one with a single landmark *is valid*; it's just not comprehensive.   In the system as currently build, generating multiple pidf-lo style representations to get you both "old North Church" and "St. George's Episcopal" associated with the other parts of the civic address *does work*.  It also can work better than a simple list of alternates where some combinations work and some do not (as the language-based examples imply).

All of the examples you have given seem to me to permit the multiple complex type solution.

I would not propose to fix just these fields.  I'd allow maxoccurs to be unbounded in all fields, and let national profiles restrict it.

I would strongly oppose this particular approach.  For one thing, what national profile deals with maxoccurs greater than one for country?  If I am willing to consider addresses in Hong Kong and Macao to also be in China, which national profile says this okay:  Hong Kong's or China's?  For another, it invalidates national profiles already built which may rely on maxoccurs being 1, but which did not say so out loud at the time (because they didn't need to).

 We know which fields need more instances for the U.S., but we don't know about other countries.

As I said before, I think you need to have a draft.  Setting out the goals clearly with a proposal will get you further than this thread as at least I (bear of little brain that I am), still do not see what is driving you to change from "valid location representation" to "valid, comprehensive location representation"

regards,

Ted Hardie

Brian

On Apr 9, 2013, at 12:12 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

> On 9 April 2013 08:18, Rosen, Brian <[email-masked]<mailto:[email-masked]>> wrote: