[rfc-i] Remove some requirements on element order

Phillip Hallam-Baker hallam at gmail.com
Mon Jan 6 09:26:54 PST 2014


On Mon, Jan 6, 2014 at 10:32 AM, Paul Hoffman <paul.hoffman at vpnc.org> wrote:

> On Jan 5, 2014, at 8:31 PM, Martin J. Dürst <duerst at it.aoyama.ac.jp>
> wrote:
>
> > On 2014/01/03 2:54, Julian Reschke wrote:
> >
> >> What I had on my mind is something like:
> >>
> >> <postal>
> >> ...
> >> <addressline><code>48155</code> <city>Münster</city></addressline>
> >> ...
> >> </postal>
> >
> > Actually, that's overkill. The problem can be solved much simpler. Just
> have a postal address as a free-form element, with the newlines possibly
> being relevant for formatting.
>
> +1
>
> There is no real value to having any structure to the postal addresses in
> RFCs, is there?
>

Absolutely none at all.

Ignore the ordering of the address elements already in my HTML input format
and I plan to do the same with the markdown style variant.


But I am rather worried by the suggestion that the specification is defined
by the tool behavior rather than the schema. Like most people writing XML
using tools, I generate the code to parse XML2RFC from the DTD (via the
schema). So if there is any change to the ordering requirements this has to
be effected through the DTD, not some words in the text.

Similarly, suggestions to make the text interpretation sensitive to
linefeeds etc. ignores some very fundamental principles of XML that simply
can't be supported with code generated from XML tools

Not that you said this, but others sure seemed to.


If you are going to use XML then use XML, otherwise you are just hitting
your head against a brick wall without seeing any of the benefit.

-- 
Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20140106/51fdd4b5/attachment.htm>


More information about the rfc-interest mailing list