Dunno if you still wanted answers to these questions, but in order to not leave you hanging here are my best attempts:
> > > On Tue, 4 Mar 2014, Evan Stade wrote: > > > > "dependent-locality" and "locality" have a fairly precise meaning in the > > UK. Also in a natural-language conversation, if you ask me what "region" > > of the country I live in, I'd say "New England", "the Midwest", or some > > such; certainly not the state where I reside. The descriptions for these > > tokens are currently pretty specific, for example they say a city would > > be a locality. But this is not true for Beijing or some other cities. To > > fix the descriptions, we'd have to change them to something like > > "region: the highest level administrative region below country in the > > address" and "locality: the second-highest level administrative region > > below country in the address", "sub-locality: the third-highest level > > administrative region [...]". > > With you so far. > > > > At this point, one wonders why the tokens aren't just [something]1, > > [something]2, etc. > > I don't understand how you get there. Why would you wonder this? > Because if the long, more descriptive copy is "first highest," "second highest," etc., it follows that the concise description (i.e. the type name) match that. > > > > > > > > > > > "address-line1" | > > > > > > > > > "address-line2" |- "street-address" > > > > > > > > > "address-line3" | > > > > > > > > > "locality" > > > > > > > > > "subsubregion" > > > > > > > > > "subregion" > > > > > > > > > "region" > > > > > > > > > "country-name" > > > > > > I don't understand why you think authors will think they need to > > > include "subregion", but won't think they need to include > > > "address-level3". > > > > I think they'll assume subregion returns something for the US if it's > > sandwiched between "region" and "locality", because county is in between > > state and city. But in reality, subregion will return nothing. > > But why does this not apply to the numeric version? > Because address-level1 is state and address-level2 is city, so there's no implication of something in between them. > > > > > Why is that better than 1=region, 2=locality, except to a US-centric > > > > viewpoint? This would lead to a weird situation where (a) you > > > > couldn't expand past 4 levels without changing the meaning of > > > > previous levels and (b) a country such as the US would have > > > > address-level4 and address-level3 but no address-level2 or > > > > address-level1. > > > > > > Well, at least as far as (a) goes, we have no way to know where > > > governments are going to introduce new levels. Who's to say that the > > > US won't introduce something between states and towns? This problem > > > exists whatever we do. Maybe the US and the EU will merge and there'll > > > be a new field between "country-name" and "region". Who knows. > > > > One can dream... > > > > You're right that changing political circumstances might put us in an > > awkward situation no matter what we do. But it seems to me the most > > likely scenario is that a government would add more administrative > > levels at the most granular level. > > Why? It seems just as likely that we'll add levels between "country" and > "region". For instance, the example above. Or, in a few years, when there > are parts of countries in space, maybe there'll be a planetoid name > between the country and the region. Or maybe that will go on the other > side of the country. > I think trying to guess how things will be extended is a fool's errand. > > If we use numbers, we paint ourselves into a corner with extensions > anywhere but at the deepest level. > Well what do we do with words? Add "subsubsubregion" or "moderately-big-area" in between two existing words? If a country experiences political turmoil and changes the number of types of administrative divisions it has, I guess it's reasonable to redefine "level4" to the former "level3", and add a new "level5" which is the former "level4". > > I've filed a bug on this topic; if I can get agreement from other vendors, > then I'll go ahead and spec this: > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25235 great!