[rfc-i] Remove some requirements on element order

Nico Williams nico at cryptonector.com
Sun Dec 22 16:02:57 PST 2013

On Tue, Dec 17, 2013 at 2:40 AM, Julian Reschke <julian.reschke at gmx.de> wrote:
> On 2013-12-17 09:18, "Martin J. Dürst" wrote:
>> 1) Is this the right and only order (of how these elements should appear
>> in (final) output), or do other orders make sense?
> The point here is that - AFAIU - processors ignore the element order here
> anyway.

Do they ignore order or just the rule?

If in some country it's normal to put street address (or whatever)
last, then order ought to matter and be preserved by the XML
processors.  XML processors must preserve order at parse time, so
making the order in the input significant is hardly a problem, but
demanding one specific order is useless (or worse) in this case.

>> 2) Do we want to make it easier for the author(s), or easier for the
>> tool(s)?
>> Currently, it's the author(s) who have to put things in the right order,
>> and the tools just copy things over. If we relax the order of input, but
>> we want to keep the order on output, the tools will have to do more work.

I don't think it's too much to demand of tools, and anyways, they
should preserve input order, so if the author gets it wrong, the
author will have to edit their XML.

>> 3) Do we want to allow more than one of each of the subelements?
>> With a DTD, allowing at most one of each is quite simple if the order is
>> fixed, whereas it's a *lot* of work if the order is open.
> We shouldn't constrain the design by the limitations of schema languages.
> There are nice for documentation purposes and as a *first* step of
> validation, but that's it.

But also, we should allow a lot of freedom in postal address writing.
We want to break up postal addresses into elements that make sense for
real-world mail routing, but it's not always just street address,
city, state, country, zip code -- the actual "schema" for postal
addresses varies a lot by country.  Perhaps we need an open schema
here, denoting "type" of postal address sub-element using an

    <postal-element type="street number">12345</postal-element>
    <postal-element type="street name">Main</postal-element>
    <postal-element type="street type" abbrev="st">street</postal-element>

Now, that's going to extremes, and a bit more direction would have to
be provided in order to format such things (specifically, which
elements should be collected into a single line, separated how, ...).

Ideally we could have a schema that works naturally for postal
addresses around the world, but chances are that would be too much


More information about the rfc-interest mailing list