[xml2rfc] formatting <postal>, was: [xml2rfc-dev] [Rfc-markdown] New xml2rfc release: v2.12.1

[Julian Reschke <[e-mail]>]

On 30.10.2018 08:20, Julian Reschke wrote:
> On 2018-10-30 07:29, Henrik Levkowetz wrote:
>>
>>
>> On 2018-10-30 05:57, Julian Reschke wrote:
>>> On 2018-10-29 22:57, Henrik Levkowetz wrote:
>>>> ...
>>>> Country-specific address formatting.  Without it, you'll be stuck
>>>> with the
>>>> fallback, which is very americentric for the text output, somewhat
>>>> less so
>>>> for the html output (but not very refined).  I'd hate to see it go.
>>>> ...
>>>
>>> Example? Smells a bit like overkill, given that v3 has simplified
>>> address formatting (postalLine).
>>
>> Example: In Norwegian and Swedish address format, the postal code goes
>> before the city, not after the region code.  This is correct:
>>
>>    Midtskogveien 18
>>    2020 Skedsmokorset
>>    Norway
>>
>> The current html specification would instead have produced, depending on
>> how you work around its problems, one of
>>
>>    Midtskogveien 18
>>    Skedsmokorset
>>    2020
>>    Norway
>>
>> or
>>
>>    Midtskogveien 18
>>    Skedsmokorset, 2020
>>    Norway
>>
>> which is a slighter degree of mangling than for places like various areas
>> of Japan, that needs city-region.  Here is a Japanese example.  This is
>> correct (except that it's also a translation, not just a romanization):
>>
>>    Japan
>>    112-0001
>>    Tokyo-to
>>    Bunkyo-ku
>>    4-3-2 Hakusan
>>    3rd Floor Room B
>>
>> and the RFC7992 specification would have rendered it as either this,
>> preserving the semantic labelling of the parts, but loosing the
>> city-region
>> part:
>>
>>    3rd Floor Room B
>>    4-3-2 Hakusan
>>    Tokyo-to, 112-0001
>>    Japan
>>
>> or would loose all semantic labelling through forced use of postalLine
>> for
>> all entries.
>>
>> This problem has however been solved to a large degree by modern
>> libraries.
>> If you can do this *right*, why continue to do it wrong?
>
> Because it's complex, and now you are relying on a specific
> implementation. Is the algorithm documented?
> ...

Coming back to this because I'm looking into how much it would take to
implement it.

Apart from complexity, my concern here is that the output now depends on
a library that is specific to a certain language. If you can point to a
definition of what that library does, it would be less of a concern.

Looking at
<https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-08#section-3.1.13>:

> 3.1.13.  In Section 2.37, <postal>
>
>    The enhancement to <postal>, adding a <postalLine> element, is a fair
>    step on the way to permitting better representation of the wealth of
>    postal addresses around the globe which don't match the American
>    postal addresses.
>
>    Unfortunately, it manages to throw the baby out with the bathwater by
>    constraining postalLine to be used only if none of the other elements
>    are used.  This makes it impossible to apply hCard [HCARD] labels
>    (based on vCard [RFC6350] properties) to the elements of an address,
>    as [RFC7992] requires.  Applying the schema from [RFC7991] would make

I agree that there's a disconnect between RFC 7991 and 7992. However, I
would prefer to solve that disconnect by just removing the hCard
requirement from RFC 7992. Is anybody aware of any real-world code that
actually processes that information (and can demonstrate it with an
example)?

(Disclaimer: rfc2629.xslt used to produce hCard information 14 years ago
(<https://github.com/reschke/xml2rfc/commit/e36d8b12968f60781bdc4d5ea77b6b16b3895ed4>)
but I removed it due to complexity and unclear benefits 6 years ago).

>    country information and hCard tags unavailable for any locality with
>    a postal address scheme that needs to use <postalLine> because it
>    does not match the American scheme.  This would make statistics such
>    as the author origin statistics either miss authors with such
>    addresses, or make the statistics harder to compile than is
>    necessary, and make for instance the data on this page skewed:
>    <https://datatracker.ietf.org/stats/document/yearly/continent/>

I note that this page currently works based on the text versions.

That said, I agree that if we want these stats, they should be easy to
extract from the XML. The current proposal however seems to be a bit
over the top to me.

>    The current implementation maps <postalLine> to the hCard property
>    "extended-address", and permits it to be used together with other
>    elements, in particular <country>, <region>, and <city>.  This is a
>    change to the schema.
>
>    The current implementation also provides a full set of hCard- and
>    [RFC6350]-compatible address elements, including <extaddr> and
>    <pobox>.  The hCard locality address component is mapped to the
>    current <city> element, however; not renamed to '<locality>'.

I note that the implementation notes do not describe all new elements,
nor how they are rendered.

Looking at the currently checked-in grammar
(<https://trac.tools.ietf.org/tools/xml2rfc/trac/browser/trunk/cli/xml2rfc/data/v3.rnc?rev=3042>):

>    postal =
>      element postal {
>        attribute xml:base { text }?,
>        attribute xml:lang { text }?,
>        ((city | code | country | region | street)*
>         | postalLine+
>         | (city?
>            & cityarea?
>            & code?
>            & country
>            & extaddr*
>            & pobox?
>            & region?
>            & sortingcode?
>            & street*))
>      }

This defines cityarea, extaddr, pobox and sortingcode. We need
descriptions of these.

I also note that the grammar now has three different content models for
<postal>, and whether a given source instance matches the first
(classic) or the third (new) seems not to be always deterministic. If
this is kept, we should try to reduce this to two cases.

Best regards, Julian