Subject: Re: More comments on CNRP spec (was: Re: Character Set Encoding i ssues)

From: Michael Mealling <[email-masked]>
Date: Thu, 13 Jul 2000 13:15:02 -0400

On Thu, Jul 13, 2000 at 10:23:47AM -0700, Nicolas Popp wrote:
> Ok.
>
> But still, since the language is a hint, we should probably leave it as is
> (lowest granularity level) and let the service decide how it wants to treat
> it (ignore the country subdivision or not)...

Most certainly....

-MM

--
--------------------------------------------------------------------------------
Michael Mealling        |      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions       |          www.lp.org          |  [email-masked]

---

From: Nicolas Popp <[email-masked]>
Date: Thu, 13 Jul 2000 10:23:47 -0700

Ok.

-Nico

-----Original Message-----
From: Michael Mealling [mailto:[email-masked]]
Sent: Thursday, July 13, 2000 9:51 AM
To: [email-masked]
Subject: Re: More comments on CNRP spec (was: Re: Character Set Encoding
i ssues)

On Thu, Jul 13, 2000 at 09:42:56AM -0700, Nicolas Popp wrote:
> We have both the 'language' and 'geography' property, so technically we
> could do what Martin suggests for languages and achieve the same
granularity
> of results (when the country subdivision matters) by having both hints in
> the query:
> <property name="language">fr</property>
> <property name="geography">FR</property>
>
> That being said, I see a pragmatic reason for keeping the language
property
> as is: it maps directly into the browser locale and it is easier to ask a
> CNRP service to support one property (language) instead of two (language +
> geography) in their database.

The country specifier in the language property has a different
meaning than when its in the geography property. fr-CA vs fr-FR
means french as its spoken in Canada as opposed to how its spoken
in France. Commingly that concept with the ISO-3166-1 code that
is a possible value in the Georgraphy property is simply wrong...

I.e. I can say "give me the CNs that are written in French Canadian
but that are actually in France".

> Another way to say the same thing is that there is one language/geography
> combination that it is important to support and that's the one one
expressed
> by the locale (a well-defined sets of language/country pairs). Other
> combinations (e.g language/any country or language/city) are second order.
> In the current proposal, the important combination can be implemented by
> supporting one property: the language proeprty. If we do what Marting
> suggests, it forces the service to understand 2 properties...
>
> IMHO, Less is better...

IMHO, this whole thread isn't sure what its talking about. ;-)
The country code Martin was talking about has no relationship
at all with country codes found in the Geography property...

-MM

--
----------------------------------------------------------------------------
----
Michael Mealling        |      Vote Libertarian!       |
www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:
14198821
Network Solutions       |          www.lp.org          |
[email-masked]