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

[jhildebr at cisco.com (Joe Hildebrand (jhildebr))]

I think I've answered a couple of these already, so I'll address the new stuff in here.

On 3/15/16, 9:35 AM, "rfc-interest on behalf of Julian Reschke" <rfc-interest-bounces at rfc-editor.org on behalf of julian.reschke at gmx.de> wrote:

>2) It would be good to clarify that a <section> with numbered=false
>(<http://greenbytes.de/tech/webdav/draft-iab-xml2rfc-03.html#element.section.attribute.numbered>) 
>still gets a regular pn=s-..., even though the section number won't be 
>visible.

Yes.

>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.

>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.

-- 
Joe Hildebrand