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

[Robert Sparks <[e-mail]>]

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)?

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