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

[Julian Reschke <[e-mail]>]

On 15.05.2019 09:19, Julian Reschke wrote:
> ...
> 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
> ...

FWIW, I just recalled *why* it is so.

In RFC 2629's DTD, the content model for <postal> made the ordering of
child elements significant, so in theory an author could at least have
specified the elements in the order that is correct for the country the
address is in (see <https://tools.ietf.org/html/rfc2629#section-2.2.2>).
However, the *implementation* (v1/TCL) did not respect that. Thus, this
could not be changed without breaking existing output, and so that's
what we have today.

<postalLine> was introduced as *alternative* which has this ordering
guarantee. However, that meant that it couldn't be easily fitted back
between the existing child elements.

Hope this clarifies how we got where RFC 7991 stands.

Best regards, Julian