Re: [xml2rfc] [xml2rfc-dev] [Rfc-markdown] New xml2rfc release: v2.12.1

[Henrik Levkowetz <[e-mail]>]

Hi Robert,

> On 30 Oct 2018, at 19:34, Robert Sparks <[e-mail]> wrote:
> 
> Meta-comment/question:
> 
> Is this a discussion about the vocabulary that we should be tracking as an issue on the vocabulary document (to at least make it easier to find later)?

I've tried to capture the relevant bits in my implementation notes draft in parallel with writing the code.  The next rev will be submitted when submissions open again.

Best regards,

        Henrik

> 
> RjS
> 
>> On 10/30/18 2:20 AM, 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?
>> 
>>> postalLine would have been a bit of an improvement, if it hadn't been
>>> handicapped by throwing out interesting and valid information through
>>> the choice of not permitting any of the existing elements that made sense
>> 
>> Well, we can discuss it. <postalLine> is the way it is because the design team thought that the level of detail that we had before simply was unneeded and just made things too complex. I guess this discussion supports this point :-)
>> 
>>> for the location's address.  A better choice would have been to add
>>> city-region and postal-box as new address elements, and specify the use
>>> of country-specific formatting.  The latter is something I could do.
>>> I haven't done the former, even if it would have been tempting, given
>>> that it would have given a pretty complete set of labelled address entities
>>> to work with.
>>> 
>>> Take the statistics that are available here:
>>>    https://datatracker.ietf.org/stats/document/yearly/country/
>> 
>> Understood. I'm just not sure that the fact these kind of stats exists (and apparently are already done with heuristics) justifies the complexity of the vocabulary.
>> 
>>> Forcing the removal of country (and region, and city) labelling if your
>>> address needs a non-US address format makes producing that kind of info
>>> harder; and it also removes the vCard/hCard annotation made possible by
>>> having properly identified address parts.  The current code provides the
>>> correct hCard property labels also for non-US addresses.
>>> 
>>> I'm *tired* of having software only work right for one country out of
>>> many, and it's not necessary any longer.  Look at all the variations
>> 
>> Yes, that's why we took the complexity out of the vocabulary.
>> 
>>> across the globe, and come and tell me that it is preferred not to do
>>> things as right as you can for most of them:
>>> 
>>>    https://en.wikipedia.org/wiki/Postal_address
>>> 
>>> Finally, given an old conversation you had about address formatting, the
>>> rendering of the bottom address here may please you:
>>> 
>>> https://durif.tools.ietf.org/src/xml2rfc/html/show/elements.html#name-authors-addresses 
>>> ...
>> 
>> Best regards, Julian
>> 
>> _______________________________________________
>> xml2rfc-dev mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/xml2rfc-dev
> 
>