[rfc-i] draft-iab-xml2rfc-03, "B.2.1 Overlapping Values"

Julian Reschke julian.reschke at gmx.de
Tue Mar 15 15:18:50 PDT 2016

On 2016-03-15 23:00, Joe Hildebrand (jhildebr) wrote:
> I think I've answered a couple of these already, so I'll address the new stuff in here.
> ...
>> 4) The preptool spec and the vocabulary spec are inconsistent with
>> respect to which elements get numbered (the vocabulary spec defines the
>> "pn" attribute on many elements not mentioned in the preptool spec).
> Here are the places I see pn's in the current RNC:
> """
> abstract
> note
> boilerplate (remove)
> section
> t
> aside
> blockquote
> ol
> ul
> li
> dl
> dt (remove?)
> dd (remove? Not in preptool)
> figure
> table
> artwork
> sourcecode
> thead (remove? Not in preptool)
> tbody (remove? Not in preptool)
> tfoot (remove? Not in preptool)
> tr (remove? Not in preptool)
> th (remove? Not in preptool)
> references
> """
> So it looks like the main places we have to talk about are tables and dt/dd.


>> 5) It's not clear at all to me why we need to have pn attributes on all
>> the elements it's mentioned for; their use case seems to provide stable
>> targets for pilcrow links, but not all of them can get a pilcrow. For
>> instance, why have it on <dd> and <dt>?
> Nod.  Let's discuss what to do.  Removing the pn attributes on the elements in question is an approach that makes sense to me at this time.  We can always add more in a later version.


>> Aside from these technical issues, I'm also unhappy with the usability
>> of this.
>> Numbering all child elements of a section without considering nesting is
>> technically simple, but will generate part numbers that are very
>> unintuitive. For instance, in an imaginary Section 1.1 that has exactly
>> five paragraphs with no other markup, we'll get the part numbers
>>    p-1.1-1 through p-1.1-5
>> Good. However, inserting a single <xref> into the first <t> will change
>> the part numbers for paragraph 2...5 to p-1.1-3...p-1.1-6. Not good,
>> IMHO, because:
> <xref>'s don't have pn's.

That may be true, but 
<http://greenbytes.de/tech/webdav/draft-iab-xml2rfc-03.html#overlap> says:

""pn" for all elements not listed above always has the format 
"p-nnn-mmm", where "nnn" is the section number and "mmm" is the relative 
position in the section. For example, this would be "p-2.1.3-7" for the 
seventh part number in Section 2.1.3."

So it needs to clarify what it means by "relative" position.

(And of course that doesn't really affect the argument about the structure).

>> Finally, I continue to find it odd that we use both the "s-" prefix and
>> the "p-" prefix. The latter isn't needed, and the part numbers that we
>> generate lose the nice property of having a somewhat logical sort order.
> Yeah, we came to consensus on that over a year ago, and you were a part of the conversation.  I really don't want to change that again if there's not a clear need.

Well, I continue to disagree. (But it's definitively not the biggest 
issue here, so let's focus on the other points first)

Best regards, Julian

More information about the rfc-interest mailing list