Subject: Re: [Geopriv] Revised Civic LO: Conversion from DHCP format

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 21 Jul 2006 21:47:14 -0400

On Jul 21, 2006, at 2:32 AM, Thomson, Martin wrote:

> If it seems complex, it's probably my wording more than anything  
> else.  I wasn't that happy in the first place, so I will have  
> another stab at it.
>
> The method that I so crudely described follows your original  
> suggestions:
>  - When a set of language preferences exists, a value is selected  
> for each element that has the highest preference.
>  - When you have no preferences available, you construct a few  
> different sets of preferences and offer several alternatives.
>
> "powerset" is the wrong word to use here, but I think I get what  
> you mean.  You believe that there will be few enough languages for  
> the number of possible combinations to be manageable.  You suggest  
> that we can get away with just saying, "in the absence of language  
> preferences, provide all possible combinations of elements".

Indeed, something to that effect, but not "every combination". If  
there are N languages, you would never have more than N XML entries,  
one for each language. There is no reason to create combinations of  
languages since that's meaningless.

The only special case that's useful is when a DHCP element is *not*  
marked with any language. It could presumably be used for any language.

>
> I wanted to provide a little more guidance on how that is done, and  
> limit the number of results for the case where you get an extra  
> helpful DHCP server that provides more languages for fields.  Your  
> suggestion results in a possible N! (N factorial) number of results  
> for N languages, whereas I wanted to keep it to N.  N! is unlikely  
> and N is quite small, but I don't like to suggest that sort of  
> algorithm on principle.  (Incidentally, a "powerset" implies 2^N.)

Powerset is indeed not the right term. The algorithm is simple  
(loosely formulated):

- Determine all languages represented in the DHCP data and create an  
XML civic element for each (a "skeleton").

- Walk through each DHCP element and copy each element into the  
corresponding civic "skeleton". If the DHCP element has no language,  
copy it into all "skeletons" unless a tag name is already filled by  
language-specific content.

Henning

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 24 Jul 2006 01:16:19 -0500

> The algorithm is simple (loosely formulated):
> 

That was my initial thought, but I was not happy with the results that this gave.  Your example in the DHCP draft is a good one to examine:

  <civicAddress xml:lang="de">
    <country>DE</country>
    <A1>Bayern</A1>
    <A2>Oberbayern</A2>
    <A3>M&#00FC;nchen</A3>
<!-- was this A6 supposed to be RD (34) ? -->
    <A6>Marienplatz</A6>
    <HNO>8</HNO>
    <LMK>Rathaus</LMK>
    <PC>80331</PC>
    <PLC>government-building</PLC>
    <POBOX>Postfach 1000</POBOX>
  </civicAddress>
  <civicAddress xml:lang="en">
    <country>DE</country>
    <A1>Bavaria</A1>
    <A3>Munich</A3>
  </civicAddress>
  <civicAddress xml:lang="it">
    <country>DE</country>
    <A1>Baviera</A1>
    <A3>Monaco</A3>
  </civicAddress>

PLC doesn't have a language in the example, but it is labeled as German.  I don't think it matters whether or not it is included in each section for this example.

My thought was that the English component would be usable on its own (the Italian section would be constructed in a similar fashion):

  <civicAddress>
    <A1 xml:lang="en">Bavaria</A1>
    <A2 xml:lang="de">Oberbayern</A2>
    <A3 xml:lang="en">Munich</A3>
    <A6 xml:lang="de">Marienplatz</A6>
    <HNO xml:lang="de">8</HNO>
    <LMK xml:lang="de">Rathaus</LMK>
    <PC xml:lang="de">80331</PC>
    <PLC>government-building</PLC>
    <POBOX xml:lang="de">Postfach 1000</POBOX>
  </civicAddress>

That is where the complexity arose.  Your suggestion is OK, if you are happy to subsequently combine the different components when preferences become available.  The English-German form above could be derived by the application of language preferences.

> language-specific content.

I do have a problem with this.  I expect that either all elements have a language tag (as applicable), or that none of the elements have a language tag (if the language is assumed == bad form, but common practice in other areas, c.f. the Internet).  To recommend that fields are included with no language - just so they can be copied across - would be discouraging the use of the language tag, even where the information is helpful.

Cheers,
Martin

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 24 Jul 2006 09:31:40 -0400

> <!-- was this A6 supposed to be RD (34) ? -->

Yes.

>
> PLC doesn't have a language in the example, but it is labeled as  
> German.  I don't think it matters whether or not it is included in  
> each section for this example.
>

PLC is a protocol constant, so it doesn't have a language (neither  
does <country>). This is probably a special case that should be  
mentioned.

> My thought was that the English component would be usable on its  
> own (the Italian section would be constructed in a similar fashion):
>
>   <civicAddress>

This seems far less clear and makes more work for the receiver,  
although it saves a bit of space. I would certainly not want to  
require this complexity. This mechanism is unlikely to work for many  
practical circumstances and only works when elements don't have  
multiple language renderings.

>
> That is where the complexity arose.  Your suggestion is OK, if you  
> are happy to subsequently combine the different components when  
> preferences become available.  The English-German form above could  
> be derived by the application of language preferences.

With language preferences, you can just select one of the top-level  
<civicAddress> elements.

> I do have a problem with this.  I expect that either all elements  
> have a language tag (as applicable), or that none of the elements  
> have a language tag (if the language is assumed == bad form, but  
> common practice in other areas, c.f. the Internet).  To recommend  
> that fields are included with no language - just so they can be  
> copied across - would be discouraging the use of the language tag,  
> even where the information is helpful.

I don't see how this discourages specifying languages; it just deals  
with the special cases (and the PLC and country elements that never  
have language information).

Henning

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 24 Jul 2006 19:01:12 -0500

When you suggest that the top-level element can be selected, are you suggesting that this is OK?

That information isn't especially useful.  The mixed English/German version at least includes sufficient information.

I understand your concern with the complexity of the conversion and agree that it is good to simplify.  Therefore, I will take your suggestion to just include multiple civicAddress elements, each with a different language.  The 'country' and 'PLC' elements (and any with no language) can be included in all instances.  I like the fact that this is simple, it avoids combinatorial problems and is easy to describe.

However, I will suggest a different method for constructing a single civicAddress element where preferences are known.  In this case, every element that is present in the DHCP form is included, with the language preferences dictating which language is used.  The element with the highest language preference is selected, or if no preference is given for the available languages, the first is selected.

Thus, we have the following without preferences:

    <RD>Marienplatz</RD>

...and, in the presence of language preferences:

Accept-Language: en,de;q=0.8

  <civicAddress>
    <country>DE</country>

This step is not specific to the DHCP version of a civic address; it equally applies when you receive a PIDF-LO containing a multi-language civic address.

> have language information).

OK, here is how your proposal discourages the use of the language tag.

If the document says, just pick the civic address element that is in your language you get the following:

This isn't much use.  However, a smart DHCP server operator will realize that if they omit the language tag for most of their data, those tags suddenly appear in all language variants:

  128 = Latn
  2 = Overbayern
  34 = Marienplatz
  19 = 8
  21 = Rathaus
  24 = 80331
  29 = government-building
  31 = Postfach 1000
  0 = de <--- deferred for language specific stuff...
  1 = Bayern
  3 = M=U+00FCnchen      
  0 = en
  1 = Bavaria
  3 = Munich
  0 = it
  3 = Monaco

This results in usable forms for all languages, because the elements that aren't assigned a language are propagated to all forms.  It might also result in some errors.  I realize that I have made some assumptions here, but I don't think that they are unrealistic.

Cheers,
Martin

p.s.  This may no longer be true: 
  "We assume that five levels are sufficient for sub-national divisions above the street level."

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Monday, 24 July 2006 11:32 PM
> To: Thomson, Martin
> Cc: [email-masked]
> Subject: Re: [Geopriv] Revised Civic LO: Conversion from DHCP format
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 25 Jul 2006 19:56:09 -0400

Let's step back a minute and avoid getting hung up on element  
manipulation. In real multi-lingual civic address life, we are likely  
to have two situations:

(1) A Western-language address where some parts (usually the city)  
have multiple renderings, e.g., Koeln and Cologne. The remainder has  
the same rendition in any Western language since it simply makes no  
sense to translate these. Even in Canada, the main street name (say,  
"Maple" in "Maple Street") remains the same whether rendered in  
French or in English since translating it would be far too confusing.  
It makes no sense to label "University" in the Montreal Street (in  
"Rue de University", I believe) as "French" (or English).

(2) In Asian countries, the whole address is transliterated into  
"English" (more accurately, Latin characters) or maybe a second  
national alphabet (as in Japan or Korea). The only piece likely to  
remain the same are possibly numeric components.

In the first case, only replication makes sense since the city name  
will appear in multiple renderings. In the second case, there isn't  
really much of a choice, unless one does some random collation  
where   elements are collected into <civicAddress> elements in some  
haphazard order.

Henning

On Jul 24, 2006, at 8:01 PM, Thomson, Martin wrote:

> That information isn't especially useful.  The mixed English/German  
> version at least includes sufficient information.
>
> I understand your concern with the complexity of the conversion and  
> agree that it is good to simplify.  Therefore, I will take your  
> suggestion to just include multiple civicAddress elements, each  
> with a different language.  The 'country' and 'PLC' elements (and  
> any with no language) can be included in all instances.  I like the  
> fact that this is simple, it avoids combinatorial problems and is  
> easy to describe.
>
> However, I will suggest a different method for constructing a  
> single civicAddress element where preferences are known.  In this  
> case, every element that is present in the DHCP form is included,  
> with the language preferences dictating which language is used.   
> The element with the highest language preference is selected, or if  
> no preference is given for the available languages, the first is  
> selected.
>
> This step is not specific to the DHCP version of a civic address;  
> it equally applies when you receive a PIDF-LO containing a multi- 
> language civic address.
>
>
>
> This isn't much use.  However, a smart DHCP server operator will  
> realize that if they omit the language tag for most of their data,  
> those tags suddenly appear in all language variants:
>
>   128 = Latn
>   2 = Overbayern
>   34 = Marienplatz
>   19 = 8
>   21 = Rathaus
>   24 = 80331
>   29 = government-building
>   31 = Postfach 1000
> This results in usable forms for all languages, because the  
> elements that aren't assigned a language are propagated to all  
> forms.  It might also result in some errors.  I realize that I have  
> made some assumptions here, but I don't think that they are  
> unrealistic.
>
> Cheers,
> Martin
>
> [mf2]_______________________________________________
> Geopriv mailing list
> [email-masked]