Subject: [Geopriv] Extending PIDF (-local-civic)

From: Brian Rosen <[email-masked]>
Date: Thu, 11 Nov 2010 19:47:14 -0500

As I wait for the geopriv meeting to start, I wanted to summarize my thoughts on extending PIDF (-local-civic).

First of all, I agree that we need to do something.  The current mechanisms we have for extending are not adequate.  The fundamental problem is that to add a CAtype (or anything else), one needs to create a new namespace, which effectively wipes out backwards compatibility.  

-local civic correctly points out that one can add a new namespace, and define any new element in that namespace.  It proposes to do that without any constraint - anyone who wants to add an element would be free to define a new namespace and create a new element.  The issue several of us have with that is that it will be very difficult to maintain interoperability.  Since the threshold to add new namespaces with uncontrolled elements will be low, we would expect a great many such namespaces, with all kinds of elements that may have a local name which is very similar to another element in another namespace, but be different, or alternatively have two (local) names for the same thing.  While this is not strictly speaking a problem, because of the uniqueness of the namespace, it seems very hard to do something like create a parser which could parse "Address Line 1" into a PIDF that would be likely to be acceptable to a server.

The basic idea that Martin and James want to push out is that 5139, which added CAtypes and fixed some problems with 4119 contains the LAST official IETF PIDF-LO namespace, and the schema is hereby considered inviolate.  Now, that's probably an overstatement, but they really do want to lock down any further changes, and confine them to some new namespace, and never change the schema in 5139.

There is a compromise proposal on the table, which would work as follows:
We would create a new namespace in a new RFC.  In that namespace, we would define two new CAtypes: extCAtype and localExtCAtype.  These CAtypes would have a parameter "name".  There would be two registries, the existing CAtype registry created by 5139 and a new one.  New entries in the existing registry would be used with extCAtype as:
  <newns:extCAtype name="STP">Avenue</newns:extCAtype>
The intention is that address elements with general use (like a street type prefix) would be defined in the existing registry with the existing management policy.

Entries in the new registry would be used with localExtCAtype.  The management for the policy with localExtCAtype would be expert review, with the instructions to seek to avoid clear duplication or spelling but otherwise to be liberal in allowing new definitions.  The registry ONLY intends to foster re-use, not become a barrier to actual new address elements.  The option to define a new namespace would remain as is.

There is a problem with validation of location information using LoST.  The proposal on the table is to extend the definition of the items in the <valid>, <invalid> and <unchecked> lists to allow a name like newns:extCAtype+STP (ie behave as if newns defined an element extCAtype+STP.

I am not thrilled with the LoST hack.  I would prefer to actually fix the problem, but I recognize that means updating the schema, and thus the namespace for LoST, and we're back to the same issue.  I can live with it if that is the consensus of the work group.

However, I am unhappy about promising that we will never update the schema for PIDF-LO or LoST.  We are not that good.  Mistakes have been made.  New features will arise that won't be able to be done with new namespaces.  For example, I would like to change the part of the schema that contains the CAtype elements from what is now SEQUENCE, because SEQUENCE implies a fixed order, and there have been suggestions for things where SEQUENCE is problematic (INT).  Now, actually, if INT was done with extCAtype, SEQUENCE would work, because there is only repeated instances of extCAtype (and localExtCAtype), and they are in a different namespace from the 5139 namespace, so just consider this an example.  I don't know what problems we will find, only that history suggests that will happen.

We should not make such promises.  We may be able to avoid updating the schema this time, we might not the next time.

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 12 Nov 2010 23:40:19 +0800

A few clarifications and points inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian Rosen
> Sent: Friday, 12 November 2010 11:47 AM
> To: [email-masked]
> Subject: [Geopriv] Extending PIDF (-local-civic)
> 
> As I wait for the geopriv meeting to start, I wanted to summarize my
> thoughts on extending PIDF (-local-civic).
> 
> First of all, I agree that we need to do something.  The current
> mechanisms we have for extending are not adequate.  The fundamental
> problem is that to add a CAtype (or anything else), one needs to create a
> new namespace, which effectively wipes out backwards compatibility.
> 
> -local civic correctly points out that one can add a new namespace, and
> define any new element in that namespace.  It proposes to do that without
> any constraint - anyone who wants to add an element would be free to
> define a new namespace and create a new element.  The issue several of us
> have with that is that it will be very difficult to maintain
> interoperability.

[AJW] And I think that this has been quite well refuted. The namespace defines a clear context in which those elements have significance. local-civic describes how to use them and describes what happens if nodes don't understand them. This doesn't lead to interoperability issues unless something doesn't follow basic XML rules, and in this case any extension will have problems.

  Since the threshold to add new namespaces with
> uncontrolled elements will be low, we would expect a great many such
> namespaces, with all kinds of elements that may have a local name which is
> very similar to another element in another namespace, but be different, or
> alternatively have two (local) names for the same thing.

[AJW] Again, I think that this is not really a problem because the significance is placed in context by the namespace. Much more to the point, this solution categorically stops misinterpretation of two local elements with the same name but different meanings. Something that simply can't be caught otherwise. Elements without clear context are subject to misuse and misinterpretation, namespaces help mitigate this problem.

  While this is
> not strictly speaking a problem, because of the uniqueness of the
> namespace, it seems very hard to do something like create a parser which
> could parse "Address Line 1" into a PIDF that would be likely to be
> acceptable to a server.

[AJW] I use DOM, it is quite good at doing this, and I know that there are a lot of other parsers that are faster and better. So I don't think that I agree that this is hard at all.
 
> 
> The basic idea that Martin and James want to push out is that 5139, which
> added CAtypes and fixed some problems with 4119 contains the LAST official
> IETF PIDF-LO namespace, and the schema is hereby considered inviolate.
> Now, that's probably an overstatement, but they really do want to lock
> down any further changes, and confine them to some new namespace, and
> never change the schema in 5139.
> 
[AJW] I think that this is an accurate assessment. A lot of people have data, implementations and specifications that all use 5139. By changing the base reference you will result in interoperability issues as systems will need to support both the new and the old formats. I don't believe that this is a tenable situation when perfectly good alternatives are available.

> We would create a new namespace in a new RFC.  In that namespace, we would
> define two new CAtypes: extCAtype and localExtCAtype.  

[AJW] I think the compromise consists of the extCAtype, there is no agreement on the localExtCAtype, in fact I am opposed to this latter type because it is open to the misuse and misinterpretation issues that I raised earlier.

These CAtypes would
> have a parameter "name".  There would be two registries, the existing
> CAtype registry created by 5139 and a new one.  New entries in the
> existing registry would be used with extCAtype as:
> The intention is that address elements with general use (like a street
> type prefix) would be defined in the existing registry with the existing
> management policy.
> 
> Entries in the new registry would be used with localExtCAtype.  The
> management for the policy with localExtCAtype would be expert review, with
> the instructions to seek to avoid clear duplication or spelling but
> otherwise to be liberal in allowing new definitions.  The registry ONLY
> intends to foster re-use, not become a barrier to actual new address
> elements.  The option to define a new namespace would remain as is.

[AJW] I think that what you describe here is one option, but certainly is not agreed to. I personally think that a registry of this nature has little to no practical use and adds burden on IANA.

> 
> There is a problem with validation of location information using LoST.
> The proposal on the table is to extend the definition of the items in the
> <valid>, <invalid> and <unchecked> lists to allow a name like
> newns:extCAtype+STP (ie behave as if newns defined an element
> extCAtype+STP.

[AJW] This hack, as I think I have pointed out, works "sort-of" within the limited CAtype space, it really doesn't scale at all well to arbitrary types, and will be hard to implement with a localExt option.

> 
> I am not thrilled with the LoST hack.  I would prefer to actually fix the
> problem, but I recognize that means updating the schema, and thus the
> namespace for LoST, and we're back to the same issue.  I can live with it
> if that is the consensus of the work group.
> 
> However, I am unhappy about promising that we will never update the schema
> for PIDF-LO or LoST.  We are not that good.  Mistakes have been made.  New
> features will arise that won't be able to be done with new namespaces.
> For example, I would like to change the part of the schema that contains
> the CAtype elements from what is now SEQUENCE, because SEQUENCE implies a
> fixed order, and there have been suggestions for things where SEQUENCE is
> problematic (INT).  Now, actually, if INT was done with extCAtype,
> SEQUENCE would work, because there is only repeated instances of extCAtype
> (and localExtCAtype), and they are in a different namespace from the 5139
> namespace, so just consider this an example.  I don't know what problems
> we will find, only that history suggests that will happen.
> 
[AJW] I will reserve my comment on the concept of INT for another time as they will be quite large.

> We should not make such promises.  We may be able to avoid updating the
> schema this time, we might not the next time.

[AJW] Understand please, that updating the schema, leads to ambiguity in the meaning and scope of the CATypes as delivered over DHCP. How does a device know if they should be put into the 5139 schema, or one of the 7 newer schemas you propose? What does a server do if it gets them in an older schema format that it was expecting? I a don't think that you can make this change as easily as you suggest Brian without having very far reaching consequences some of which I am sure we have not thought about.

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

---

From: Brian Rosen <[email-masked]>
Date: Fri, 12 Nov 2010 12:35:55 -0500

We're probably going to have to agree to disagree on a couple of these points.  It may be that we can find out the work group has rough consensus on this without a whole lot more compromise.  We can push off this discussion until the virtual interim.

Fundamentally, we're disagreeing on the value of a registry, the sanctity of the schema in PIDF (and LoST) and the syntactic niceties of how to construct the PIDF.  Of these, I care least about the latter.  I think it would be much better to have one extension namespace and use the registry to extend the list, but if consensus is to have lots of new namespaces and include the namespace with the element name in the registry, it's okay.  I'll keep pushing on that a bit, but it's not the important thing from my point of view.

We've long realized that there is no way to get a straightforward parser for any address anywhere in the world.  We have decided that there would be a document that describes how a particular country encodes addresses.  We have a REGISTRY (that's a hint) for those documents.  I don't see any practical way to totally automate parsing - code will have to be written for any particular country.  That's a pain, but I don't see anyway around that.

However, we have found, and I believe will continue to find, that there are fields that are common among many countries.  It seems to me that there is GREAT value in making those elements common.  It seems to me that the existing registry, possibly with a new column (for namespace), is fine for that.

But how about fields which are not so common.  How many do you think will actually be UNIQUE - some address field used literally in one place?  I think that will be very uncommon.  I think instead there will be many instances where someone already has a field.  The thing is, how would you know that?  Without the registry, you can't.  Without the registry, two fields will have the same name, but be different.  Sure, the namespaces makes them unique, but the confusion and effort to make sure the right thing happens is large.

The difference between the extCA and the localExtCA is the level of review.  One is very common, and has more review, one is less common, and only has enough review to determine that it is actually unique.

And, of course, the option to just create a new namespace and put anything you need in it exists.  It's just that such extensions will have no review, will have no consistency, and will require more work to be interoperable.

Finally, it is not in our interest to promote easy expansion of elements.  We can't stop someone from creating a namespace and doing anything they want (or even misusing some defined elements).   What we can do is encourage consistency, element re-use, and exert some quality control.  Our experience is that it's very helpful.

With respect to the basic schemas, I think there is no level of agreement.  I think it is very unwise to keep the schema sacrosanct.     I agree that we should not make changes without good reason, and if it is reasonable to achieve full backwards compatibility, as it could be in this case, that is desirable.  However, it has never, ever, been our practice to promise backwards compatibility for anything.  We should not do so here.

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 13 Nov 2010 01:53:27 +0800

Comments inline.

> 
> Fundamentally, we're disagreeing on the value of a registry, the sanctity
> of the schema in PIDF (and LoST) and the syntactic niceties of how to
> construct the PIDF.  Of these, I care least about the latter.  I think it
> would be much better to have one extension namespace and use the registry
> to extend the list, but if consensus is to have lots of new namespaces and
> include the namespace with the element name in the registry, it's okay.
> I'll keep pushing on that a bit, but it's not the important thing from my
> point of view.

[AJW] I just don't see the need for a registry at all, including for the namespaces, there isn't one today for all XML namespaces in the world, why do we suddenly need one? However, if the only way that this is going to get through the working is with the creation of the registry then sobeit, though mandating use of it is going to be quite a different matter.

> 
> We've long realized that there is no way to get a straightforward parser
> for any address anywhere in the world.  We have decided that there would
> be a document that describes how a particular country encodes addresses.
> We have a REGISTRY (that's a hint) for those documents.  I don't see any
> practical way to totally automate parsing - code will have to be written
> for any particular country.  That's a pain, but I don't see anyway around
> that.
> 
> However, we have found, and I believe will continue to find, that there
> are fields that are common among many countries.  It seems to me that
> there is GREAT value in making those elements common.  It seems to me that
> the existing registry, possibly with a new column (for namespace), is fine
> for that.

[AJW] If these are common in this way, then write a spec and get a CAType allocated for them and then the common CAType extension schema can be employed and we are done. If they are more localized than that, then use a local schema, and again we are done.

> 
> But how about fields which are not so common.  How many do you think will
> actually be UNIQUE - some address field used literally in one place?  I
> think that will be very uncommon.  I think instead there will be many
> instances where someone already has a field.  The thing is, how would you
> know that?  Without the registry, you can't.  Without the registry, two
> fields will have the same name, but be different.  Sure, the namespaces
> makes them unique, but the confusion and effort to make sure the right
> thing happens is large.

[AJW] Actually, I think that these could well be enterprise or application specific, so yes I think that defining solely within the scope of that environment should be possible. That is the difference, one makes it not possible, while the other says uncommon yes, but possible and I believe that the solution to allow it is more flexible and more simple than the solution that would forbid it. On the confusion aspect caused by namespaces we will just have to disagree, namespaces provide context and make intent clear.

> 
> The difference between the extCA and the localExtCA is the level of
> review.  One is very common, and has more review, one is less common, and
> only has enough review to determine that it is actually unique.
> 
> And, of course, the option to just create a new namespace and put anything
> you need in it exists.  It's just that such extensions will have no
> review, will have no consistency, and will require more work to be
> interoperable.

[AJW] Please justify this, I personally believe that this is a fallacy.

> 
> Finally, it is not in our interest to promote easy expansion of elements.
> We can't stop someone from creating a namespace and doing anything they
> want (or even misusing some defined elements).   What we can do is
> encourage consistency, element re-use, and exert some quality control.
> Our experience is that it's very helpful.

[AJW] Again we will just have to agree to disagree on this point.

> 
> With respect to the basic schemas, I think there is no level of agreement.
> I think it is very unwise to keep the schema sacrosanct.     I agree that
> we should not make changes without good reason, and if it is reasonable to
> achieve full backwards compatibility, as it could be in this case, that is
> desirable.  However, it has never, ever, been our practice to promise
> backwards compatibility for anything.  We should not do so here.

[AJW] <sarcasm mode="on> To be consistent then lets reallocate the meaning of CATypes each time we change the schema then so that the degree of confusion can be universal across all things.</sarcasm>
Seriously, I think that you will face a huge uphill battle from a bunch of folks that have not yet weighed in on this debate if you try and change the basic namespace.  

> > [AJW] And I think that this has been quite well refuted. The namespace
> defines a clear context in which those elements have significance. local-
> civic describes how to use them and describes what happens if nodes don't
> understand them. This doesn't lead to interoperability issues unless
> something doesn't follow basic XML rules, and in this case any extension
> will have problems.
> >
> >
> > [AJW] Again, I think that this is not really a problem because the
> significance is placed in context by the namespace. Much more to the
> point, this solution categorically stops misinterpretation of two local
> elements with the same name but different meanings. Something that simply
> can't be caught otherwise. Elements without clear context are subject to
> misuse and misinterpretation, namespaces help mitigate this problem.
> >
> >  While this is
> > [AJW] I use DOM, it is quite good at doing this, and I know that there
> are a lot of other parsers that are faster and better. So I don't think
> that I agree that this is hard at all.
> >
> >>
> > [AJW] I think that this is an accurate assessment. A lot of people have
> data, implementations and specifications that all use 5139. By changing
> the base reference you will result in interoperability issues as systems
> will need to support both the new and the old formats. I don't believe
> that this is a tenable situation when perfectly good alternatives are
> available.
> >
> > [AJW] I think the compromise consists of the extCAtype, there is no
> agreement on the localExtCAtype, in fact I am opposed to this latter type
> because it is open to the misuse and misinterpretation issues that I
> raised earlier.
> >
> >
> > These CAtypes would
> > [AJW] I think that what you describe here is one option, but certainly
> is not agreed to. I personally think that a registry of this nature has
> little to no practical use and adds burden on IANA.
> >
> >>
> > [AJW] This hack, as I think I have pointed out, works "sort-of" within
> the limited CAtype space, it really doesn't scale at all well to arbitrary
> types, and will be hard to implement with a localExt option.
> >
> >>
> > [AJW] Understand please, that updating the schema, leads to ambiguity in
> the meaning and scope of the CATypes as delivered over DHCP. How does a
> device know if they should be put into the 5139 schema, or one of the 7
> newer schemas you propose? What does a server do if it gets them in an
> older schema format that it was expecting? I a don't think that you can
> make this change as easily as you suggest Brian without having very far
> reaching consequences some of which I am sure we have not thought about.
> >
> >
> >>
> >> Brian
> >>

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 15 Nov 2010 11:04:11 +0800

Brian,

We should not be discussing whether any particular RFC and the specification it contains are inviolate.  Requirements change, working groups make subtle mistakes, and bit-rot sets in.  The applicability of the contents are to be evaluated on their own merits.  To suggest otherwise is dishonest.

The core issue under contention is whether the additions in question are sufficient justification for the changes that you propose.

Redefining the basic schema is a drastic measure.

It's easy to turn this discussion into a complex tapestry of interconnected and confusing issues.  This illusory complexity might serve to make drastic measures seem more justifiable.

It's not that complex.  Adding fields was anticipated and we only have a handful to add.

The only issue relates to the use of the registry and where private and local extensions fit.  

--Martin

On 2010-11-13 at 04:35:55, Brian Rosen wrote:
> We're probably going to have to agree to disagree on a couple of these
> points.  It may be that we can find out the work group has rough
> consensus on this without a whole lot more compromise.  We can push off
> this discussion until the virtual interim.
> 
> Fundamentally, we're disagreeing on the value of a registry, the
> sanctity of the schema in PIDF (and LoST) and the syntactic niceties of
> how to construct the PIDF.  Of these, I care least about the latter.  I
> think it would be much better to have one extension namespace and use
> the registry to extend the list, but if consensus is to have lots of
> new namespaces and include the namespace with the element name in the
> registry, it's okay.  I'll keep pushing on that a bit, but it's not the
> important thing from my point of view.
> 
> We've long realized that there is no way to get a straightforward
> parser for any address anywhere in the world.  We have decided that
> there would be a document that describes how a particular country
> encodes addresses.  We have a REGISTRY (that's a hint) for those
> documents.  I don't see any practical way to totally automate parsing -
> code will have to be written for any particular country.  That's a
> pain, but I don't see anyway around that.
> 
> there is GREAT value in making those elements common.  It seems to me
> that the existing registry, possibly with a new column (for namespace),
> is fine for that.
> 
> But how about fields which are not so common.  How many do you think
> will actually be UNIQUE - some address field used literally in one
> place?  I think that will be very uncommon.  I think instead there will
> be many instances where someone already has a field.  The thing is, how
> would you know that?  Without the registry, you can't.  Without the
> registry, two fields will have the same name, but be different.  Sure,
> the namespaces makes them unique, but the confusion and effort to make
> sure the right thing happens is large.
> 
> review.  One is very common, and has more review, one is less common,
> and only has enough review to determine that it is actually unique.
> 
> And, of course, the option to just create a new namespace and put
> anything you need in it exists.  It's just that such extensions will
> have no review, will have no consistency, and will require more work to
> be interoperable.
> 
> Finally, it is not in our interest to promote easy expansion of
> elements.  We can't stop someone from creating a namespace and doing
> anything they want (or even misusing some defined elements).   What we
> can do is encourage consistency, element re-use, and exert some quality
> control.  Our experience is that it's very helpful.
> 
> With respect to the basic schemas, I think there is no level of
> agreement.  I think it is very unwise to keep the schema sacrosanct.
> I agree that we should not make changes without good reason, and if it
> is reasonable to achieve full backwards compatibility, as it could be
> in this case, that is desirable.  However, it has never, ever, been our
> practice to promise backwards compatibility for anything.  We should
> not do so here.
> 
> Brian
> > [AJW] And I think that this has been quite well refuted. The
> namespace defines a clear context in which those elements have
> significance. local-civic describes how to use them and describes what
> happens if nodes don't understand them. This doesn't lead to
> interoperability issues unless something doesn't follow basic XML
> rules, and in this case any extension will have problems.
> >
> >
> elements with the same name but different meanings. Something that
> simply can't be caught otherwise. Elements without clear context are
> subject to misuse and misinterpretation, namespaces help mitigate this
> problem.
> >
> >  While this is
> > [AJW] I use DOM, it is quite good at doing this, and I know that
> there are a lot of other parsers that are faster and better. So I don't
> think that I agree that this is hard at all.
> >
> >>
> > [AJW] I think that this is an accurate assessment. A lot of people
> have data, implementations and specifications that all use 5139. By
> changing the base reference you will result in interoperability issues
> as systems will need to support both the new and the old formats. I
> don't believe that this is a tenable situation when perfectly good
> alternatives are available.
> >
> agreement on the localExtCAtype, in fact I am opposed to this latter
> type because it is open to the misuse and misinterpretation issues that
> I raised earlier.
> >
> >
> > These CAtypes would
> > [AJW] I think that what you describe here is one option, but
> certainly is not agreed to. I personally think that a registry of this
> nature has little to no practical use and adds burden on IANA.
> >
> >>
> > [AJW] This hack, as I think I have pointed out, works "sort-of"
> within the limited CAtype space, it really doesn't scale at all well to
> arbitrary types, and will be hard to implement with a localExt option.
> >
> >>
> > [AJW] Understand please, that updating the schema, leads to ambiguity
> in the meaning and scope of the CATypes as delivered over DHCP. How
> does a device know if they should be put into the 5139 schema, or one
> of the 7 newer schemas you propose? What does a server do if it gets
> them in an older schema format that it was expecting? I a don't think
> that you can make this change as easily as you suggest Brian without
> having very far reaching consequences some of which I am sure we have
> not thought about.
> >
> >
> >>
> >> Brian
> >>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 15 Nov 2010 09:45:26 -0500

Sure.

You could also parse 100% of the U.S. addresses by having "Address Line 1" instead of all those pesky prefix/suffix/directional/... fields.  But when you parse "A Avenue" into two elements, and "Avenue A" into one, something is wrong.  Either the suffix is extraneous, or the prefix is needed.   Mostly, this is English bias.  If you looked at Spanish street names, you would have a bigger problem than with U.S. names.  I believe the same is true of French street naming and several other languages.

Brian

On Nov 15, 2010, at 9:19 AM, Marc Berryman wrote:

> Brian,
> Re: However, I am unhappy about promising that we will never update the schema for PIDF-LO or LoST.  We are not that good.  Mistakes have been made.  
> 
> I have tested RFC 5139 on millions of street names across the US. I challenge you or anyone to illustrate to me a single street name, or complete street name, that I cannot parse into the street name elements within RFC 5139.
> 
> Your example of 
> seems to me a fix to something that is not a problem. 
> 
> Granted there is a very small fraction of a single percent of house numbers that I cannot parse into the namespace, but your example was implying a "fix" was needed due to the street name elements.
> 
> Marc B.
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
> Sent: Thursday, November 11, 2010 7:47 PM
> To: [email-masked]

---

From: "Carl Reed" <[email-masked]>
Date: Mon, 15 Nov 2010 08:13:30 -0700

There is an ISO TC 211 activity looking at addressing. Part of the activity 
is a review of addressing standards. As you can see from the list below, the 
work is quite international. I am an observer for this activity. Ram Kumar 
(on the list) is the editor of the OASIS xAL (address encoding) standard. 
xAL is the address encoding standard used in KML.

There are two primary activities that this group is involved in:

1. Investigate and formulate requirements in relation to addressing.
2. Make recommendations on whether standards should be developed and if so, 
how this should be done.

 Address standards review (see list under refinement of scope above) 
according to identified requirements:
Goal is to prepare section 5 (see Table of Contents); the section is split 
into three parts, i.e. three teams; review the list of standards for each 
identified requirement; for example, identify the terminology in the 
standards and compare it.
  Team 1:
  Requirements: Scope of the standard; terminology; classifications of 
addresses (address types); identification of possible components of an 
address; conceptual model (relationship between components)
  Team leader: Rob Walker (UK)
  Team members: Piotr Piotrowski (UPU), Patrick Dousseaud (FR), Boris Gutkin 
(CA), Morten Lind (DK), Antony Cooper (ZA), Li Li (CN), Karen Owens (US), 
Teruko Usui (JP), Koichi Hirata (JP), Hidenori Fujimara (JP), Arjen van 
Zwieten (ZA), Serena Coetzee (ZA)

  Team 2:
  Requirements: Transfer and exchange of address data; address rendering 
(print/write/display) of address data; multilingual addresses; managing 
address aliases
  Team leader: Piotr Piotrowski (UPU)
  Team members: Boris Gutkin (CA), Joe Lubenow (UPU), Morten Lind (DK), 
Pierre Rossouw (ZA), Ram Kumar (Australia), Serena Coetzee (ZA)

  Team 3:
  Requirements: Definitive address datasets (reference dataset); quality 
management; life cycle; metadata for addresses
  Team leader: Randy Fusaro (US)
  Team members: Karen Owens (US), Boris Gutkin (CA), Antony Cooper (ZA), Li 
Li (CN), Carsten Roensdorf (UK and Germany), Piotr Piotrowski (UPU), Marius 
van der Merwe (ZA), Serena Coetzee (ZA)
So, two thoughts.

1. I can provide input from this WG into the ISO process.
2. Perhaps this group needs to consider the work being done in the ISO 
activity. Much of the recent address discussion has been a bit US centric.

The ISO work involves not just the countires lists above but others as well.

Regards

Carl
OGC

----- Original Message ----- 
From: "Brian Rosen" <[email-masked]>
To: "Marc Berryman" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, November 15, 2010 7:45 AM
Subject: Re: [Geopriv] Extending PIDF (-local-civic)

> Sure.
>
> You could also parse 100% of the U.S. addresses by having "Address Line 1" 
> instead of all those pesky prefix/suffix/directional/... fields.  But when 
> you parse "A Avenue" into two elements, and "Avenue A" into one, something 
> is wrong.  Either the suffix is extraneous, or the prefix is needed. 
> Mostly, this is English bias.  If you looked at Spanish street names, you 
> would have a bigger problem than with U.S. names.  I believe the same is 
> true of French street naming and several other languages.
>
> Brian
>
>> Re: However, I am unhappy about promising that we will never update the 
>> schema for PIDF-LO or LoST.  We are not that good.  Mistakes have been 
>> made.
>>
>> I have tested RFC 5139 on millions of street names across the US. I 
>> challenge you or anyone to illustrate to me a single street name, or 
>> complete street name, that I cannot parse into the street name elements 
>> within RFC 5139.
>>
>> Your example of
>> Granted there is a very small fraction of a single percent of house 
>> numbers that I cannot parse into the namespace, but your example was 
>> implying a "fix" was needed due to the street name elements.
>>
>> Marc B.
>>
>> interoperability.  Since the threshold to add new namespaces with 
>> namespaces, with all kinds of elements that may have a local name which 
>> is very similar to another element in another namespace, but be 
>> different, or alternatively have two (local) names for the same thing. 
>> While this is not strictly speaking a problem, because of the uniqueness 
>> of the namespace, it seems very hard to do something like create a parser 
>> which could parse "Address Line 1" into a PIDF that would be likely to be 
>> acceptable to a server.
>>
>> added CAtypes and fixed some problems with 4119 contains the LAST 
>> official IETF PIDF-LO namespace, and the schema is hereby considered 
>> inviolate.  Now, that's probably an overstatement, but they really do 
>> want to lock down any further changes, and confine them to some new 
>> namespace, and never change the schema in 5139.
>>
>> We would create a new namespace in a new RFC.  In that namespace, we 
>> would define two new CAtypes: extCAtype and localExtCAtype.  These 
>> CAtypes would have a parameter "name".  There would be two registries, 
>> the existing CAtype registry created by 5139 and a new one.  New entries 
>> in the existing registry would be used with extCAtype as:
>> management for the policy with localExtCAtype would be expert review, 
>> with the instructions to seek to avoid clear duplication or spelling but 
>> However, I am unhappy about promising that we will never update the 
>> schema for PIDF-LO or LoST.  We are not that good.  Mistakes have been 
>> made.  New features will arise that won't be able to be done with new 
>> namespaces.  For example, I would like to change the part of the schema 
>> that contains the CAtype elements from what is now SEQUENCE, because 
>> SEQUENCE implies a fixed order, and there have been suggestions for 
>> things where SEQUENCE is problematic (INT).  Now, actually, if INT was 
>> done with extCAtype, SEQUENCE would work, because there is only repeated 
>> instances of extCAtype (and localExtCAtype), and they are in a different 
>> namespace from the 5139 namespace, so just consider this an example.  I 
>> don't know what problems we will find, only that history suggests that 
>> will happen.
>>