[rfc-i] Supporting both ease-of-entry and un-labeled list items in v3

Nico Williams nico at cryptonector.com
Thu Feb 13 09:54:15 PST 2014


On Thu, Feb 13, 2014 at 11:12 AM, Julian Reschke <julian.reschke at gmx.de> wrote:
> On 2014-02-13 17:55, Paul Hoffman wrote:
>>
>>
>> On Feb 12, 2014, at 12:45 PM, Julian Reschke <julian.reschke at gmx.de>
>> wrote:
>>
>>> On 2014-02-12 20:57, Paul Hoffman wrote:
>>>>
>>>> On Feb 12, 2014, at 11:47 AM, Julian Reschke <julian.reschke at gmx.de>
>>>> wrote:
>>>>
>>>>> We can support both inline elements (text, <xref>) and block elements
>>>>> (<t>), but why would we want to allow to combine them?
>>>>
>>>>
>>>> Because it makes it easier to create an Internet Draft, which is a
>>>> design goal. Compare the current proposal:
>>>>
>>>>     <list style="symbols">
>>>>        <li>This is the first element with a bullet.</li>
>>>>        <li>This is the second element with a bullet.
>>>>           <t>This is part of the second element,
>>>>           but it does not have a bullet</t></li>
>>>>        <li>This is the third element with a bullet.</li>
>>>>     </list>
>
>
> Once we start mixing text with block level elements, we'll probably see
>
>
>         <li>This is the second element with a bullet.
>            <t/>This is part of the second element,
>            but it does not have a bullet</li>
>
> as well :-)

But that's just not valid XML, so it's not a problem (as long as the
tools require strict XML).

*My* problem with mixing text nodes with block level elements is that
it complicates any XSLs for manipulating such inputs.  The problem is
that the code would have to notice that the text nodes (note plural)
of an <li> are (each) as-if inside a <t>.  This isn't likely to be a
big deal, so in this case I think we can let ease of use trump
developer convenience -- assuming that this mixing really is easier to
use (which Julian argues it's not, and I'm not yet sure).

> BTW, my proposal was to have <li> (*) be either inline content *or* block
> content. That is,
>
>      <list style="symbols">
>         <li><t>This is the first element with a bullet.</t></li>
>         <li><t>This is the second element with a bullet.</t>
>            <t>This is part of the second element,
>            but it does not have a bullet</t></li>
>         <li><t>This is the third element with a bullet.</t></li>
>      </list>
>
> would work but so would
>
>
>      <list style="symbols">
>         <li>This is the first element with a bullet.</li>
>         <li><t>This is the second element with a bullet.</t>
>            <t>This is part of the second element,
>            but it does not have a bullet</t></li>
>         <li>This is the third element with a bullet.</li>
>      </list>

+1.  This is what I'd understood you were proposing.

> (*) I'd prefer not to use <li> unless it's really the same thing as in HTML.
> That's why the proposed element name has been <lt> for a very long time.

Meh.

>>> Let's not mix block-level elements with text content.
>>
>> That design goal has little or nothing to do with making it easier to
>> create an Internet Draft, which is a design goal.
>
> It seems that you equate "has less to type" with "easier". I disagree with
> that. A logical structure with fewer edge cases makes things "easier", too.
> (And no, not only for implementers)

I think that's right.  If I'm sharing an I-D editorship with someone
and their XML surprises me...

Also, XML-oriented editors might not understand (and therefore
properly display) that text nodes and block level <t> elements inside
the <li> are indeed as if at the same level.

>> A possible third alternative, which makes me cringe a bit but I can see
>> some logic to it, would be:
>>
>>     <list style="symbols">
>>        <li>This is the first element with a bullet.</li>
>>        <li>This is the second element with a bullet.
>>        <linolabel>This is part of the second element,
>>           but it does not have a bullet.</linolabel>
>>        <li>This is the third element with a bullet.</li>
>>     </list>

It makes me cringe a lot.

We currently have a containership approach to most everything
(sections contain sections, ...) in the xml2rfc schema.  This would be
a significant departure.

In particular it turns out to be difficult to write XSLs for
converting from non-containership schemas to containership schemas.
So I really would prefer to stay away from this last proposal!

Nico
--


More information about the rfc-interest mailing list