[rfc-i] Section structure, was: RFC editing tools

[Nico Williams]

On Fri, Dec 7, 2012 at 12:40 PM, Julian Reschke <julian.reschke at gmx.de> wrote:
> On 2012-12-07 19:33, Nico Williams wrote:
>>>> If we're going to use HTML as the basis for the schema we might as
>>>> well stop nesting <section>s and go back to <h2>, <h3>, ... <hN>.
>>>> (Figuring out how to convert from the latter to the former in XSL took
>>>> a fair bit of effort when writing lyx2rfc!)
>>>
>>> But then you loose information, which will be hard to recover (much
>>> harder
>>> than the other way around).
>>
>> Actually, you lose nothing.  I know from having written XSLs to
>> convert from <hN> style to nested section style.
>
> I'm sure writing these wasn't trivial either (at least not on XSLT 1.0) :-)

It was not trivial, though the resulting idiom in XSLT 2.0 is actually
fairly simple.  I could not find a way to do this in XSLT 1.0 at all
(I tried).  But are we making XSLT 1.0 a requirement for RFC tooling??
 We shouldn't!

>> Well, actually I lie, you lose one pathological thing: section
>> contents following sub-sections!  (This pathological case is
>> impossible in <hN> style, and we cannot represent it in any output
>> formats we've had to date because we don't indent section content.
>> It's come up before for xml2rfc.  Isn't it nice that this error is not
>> possible in <hN> style?  Should we infer from this that nested
>> <section> style is flawed?)
>
> It's invalid in xml2rfc.

Yes, but xml2rfc didn't use to error out on this.

>> Also, now that I know how to easily and reliably convert from <hN>
>> style to nested <section> style (though it requires XSLT 2.0) we don't
>
> (see :-)

But there's nothing wrong with XSLT 2.0.  Indeed, once you've used
XSLT 2.0 you'll never want to go back to 1.0.

>>> You may want to check the mailing list archives for a previous epic
>>> thread
>>> about this topic.
>>
>> Maybe, but it sounds painful :(
>
> That it will be.

My guess is that I'll find personal preferences for nested sections,
not so much a fundamental reason why one or the other approach is
superior to the other.  In any case, as long as I know how to convert
between the two it makes little difference which one is canonical.

Nico
--