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

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 19 Jul 2006 23:57:15 -0500

Based on Hennings WGLC comments on the revised civic draft, I have penned a new section for the draft that deals with the conversion issues arising from having multiple languages.

I would like to get some feedback from the group on the following section.  Is it clear enough?  Does it strike the right balance?

As always, constructive suggestions are favoured.  I'm particularly interested in what you think is the right algorithm...and why.

~~~

3.5.1.  Duplicated Elements in the DHCP Format

   The DHCP format for civic addresses [I-D.ietf-geopriv-dhcp-civil]
   permits the inclusion of an element multiple times with different
   languages.  However, this XML form only permits a single instance of
   each element.  This section describes an algorithm for converting
   from DHCP form.

   If the user of the XML representation is known, and the user has
   indicated language preferences a single XML format can be constructed
   using those preferences.  For example, language preferences can be
   indicated by the "Accept-Language" header in the SIP or HTTP
   protocols.  In the absence of language preferences, multiple civic
   address elements are constructed.

   To convert from the DHCP form, the civic address is constructed by
   taking each element in turn.  For elements that have only one
   candidate option, that element is included in the resulting address,
   irrespective of language preferences.  If multiple values are
   available in different languages for the element, the value in the
   highest preferred language is selected; if none of the languages
   present are preferred, or if two elements have the same preference,
   the first of these options is selected.

   If there are no language preferences, the above procedure is repeated
   with a series of constructed language preferences.  The initial order
   of language preference is established by using the order of languages
   included in the DHCP form, with any duplicates removed.  For each
   subsequent iteration of the procedure, the preferences are rotated -
   the language of highest preference is moved to the lowest preference.

   Note that this process might result in duplicate results; duplicate
   results SHOULD be omitted.  Note also that this algorithm can also
   omit possible combinations of language choices; this method is chosen
   because it limits the impact of a DHCP civic format that contains
   multiple languages.

   When inserting these representations into a PIDF-LO document, the
   multiple civic address elements SHOULD be inserted into the same
   tuple.

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]

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 26 Jul 2006 01:51:30 -0500

Here is the new text that I am proposing for Section 3.5:

   For civic addresses that form a complex to describe the same
   location, these SHOULD be inserted into the same tuple.

3.5.1.  Converting from the DHCP Format

   The DHCP format for civic addresses [I-D.ietf-geopriv-dhcp-civil]
   permits the inclusion of an element multiple times with different
   languages.  However, this XML form only permits a single instance of
   each element.  Multiple "civicAddress" elements are required if any
   element is duplicated with different languages.  If the same language
   is used for all elements, or no elements are duplicated, the format
   can be converted into a single civic address.

   Where there are duplicated elements in different languages, a
   "civicAddress" element is created for each language that is present.
   All elements that are in that language are included.  Elements that
   are language independent, like the "country" and "PLC" elements, are
   added to all "civicAddress" elements.

3.5.2.  Combining Multiple Elements Based on Language Preferences

   If the receiver of the XML representation is known, and that receiver
   has indicated language preferences a single XML format can be
   constructed using those preferences.  For example, language
   preferences can be indicated by the "Accept-Language" header in the
   SIP or HTTP protocols.  This applies when converting from the DHCP
   format, or when multiple "civicAddress" elements are present.

   All elements that have only one value, irrespective of language, are
   used.  Where multiple values exist, each value is assigned a
   weighting based on the language preferences.  The value with the
   highest weighting is selected.  An arbitrary value is selected if two
   values have the same preference, if there is no preference for the
   available languages, or if there a conflicting values with the same
   language.

> -----Original Message-----
> From: Thomson, Martin
> Sent: Tuesday, 25 July 2006 10:01 AM
> To: 'Henning Schulzrinne'
> Cc: [email-masked]
> Subject: RE: [Geopriv] Revised Civic LO: Conversion from DHCP format
> 
> When you suggest that the top-level element can be selected, are you
> suggesting that this is OK?
> 
>   <civicAddress xml:lang="en">
>     <country>DE</country>
>     <A1>Bavaria</A1>
>     <A3>Munich</A3>
>     <PLC>government-building</PLC>
>   </civicAddress>
> 
> 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:
> 
>   <civicAddress xml:lang="de">
>     <country>DE</country>
>     <A1>Bayern</A1>
>     <A2>Oberbayern</A2>
>     <A3>M&#00FC;nchen</A3>
>     <RD>Marienplatz</RD>
>     <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>
>     <PLC>government-building</PLC>
>   </civicAddress>
>   <civicAddress xml:lang="it">
>     <country>DE</country>
>     <A1>Baviera</A1>
>     <A3>Monaco</A3>
>     <PLC>government-building</PLC>
>   </civicAddress>
> 
> ...and, in the presence of language preferences:
> 
> Accept-Language: en,de;q=0.8
> 
>   <civicAddress>
>     <country>DE</country>
>     <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>
> 
> 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.
> 
> 
> 
> > 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).
> 
> 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:
> 
>   <civicAddress xml:lang="en">
>     <country>DE</country>
>     <A1>Bavaria</A1>
>     <A3>Munich</A3>
>     <PLC>government-building</PLC>
>   </civicAddress>
> 
> 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
> >
> > > <!-- 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>
> > >     <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>
> >
> > 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.
> >
> > >
> > >> - 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.
> > >
> > > 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
> >
> >
> >
> >