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" <br@brianrosen.net>
To: "Marc Berryman" <mberryman@ddti.net>
Cc: <geopriv@ietf.org>
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
>
> 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
>> <newns:extCAtype name="STP">Avenue</newns:extCAtype>
>> 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.
>>
>> -----Original Message-----
>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
>> Behalf Of Brian Rosen
>> Sent: Thursday, November 11, 2010 7:47 PM
>> To: geopriv@ietf.org
>> 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. 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
>>
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
