Subject: [xml2rfc] #378 (Version_3_cli_txt): <iref> in <table> not supported

From: "xml2rfc issue tracker" <[email-masked]>
Date: Sat, 17 Nov 2018 13:48:14 -0000

#378: <iref> in <table> not supported

 The following construct:

 {{{
         <table>
           <iref item="Bare Table"/>
           <thead>
             <tr>
               <th>Column 1</th>
               <th>Column 2</th>
             </tr>
           </thead>
           <tbody>
             <tr>
               <td>Value 1</td>
               <td>Value 2</td>
             </tr>
           </tbody>
         </table>
 }}}

 fails with:

  Error: Did not expect element iref there, at
 /rfc/middle/section[10]/section[1]/table/iref

-- 
-----------------------------------+--------------------
 Reporter:  [email-masked]  |      Owner:
     Type:  defect                 |     Status:  new
 Priority:  medium                 |  Milestone:
Component:  Version_3_cli_txt      |    Version:  2.13.x
 Keywords:                         |
-----------------------------------+--------------------

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/378>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Sat, 17 Nov 2018 14:33:55 -0000

Comment (by [email-masked]):

 This is intentional.  Could be wrong, of course.  The reason is as given
 here:

 https://zin.tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-
 notes-06#section-3.1.7

-- 
------------------------------------+--------------------
Resolution:                         |   Keywords:
------------------------------------+--------------------

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/378#comment:1>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Sat, 17 Nov 2018 18:05:44 -0000

Comment (by [email-masked]):

 I agree that there's a spec problem. However, that needs to be fixed on
 them HTML level. FWIW, RFC 7992 tries to specify all kinds of things
 without having to, and this leads to problems like these.

 rfc2629.xslt generates:

 {{{
             <div class="tt">
                <div id="rfc.iref.b.1"/>
                <table class="tt tcenter">
                   <thead>
                      <tr>
                         <th>Column 1</th>
                         <th>Column 2</th>
                      </tr>
                   </thead>
                   <tbody>
                      <tr>
                         <td>Value 1</td>
                         <td>Value 2</td>
                      </tr>
                   </tbody>
                </table>
             </div>
 }}}

 So the table is enclosed in a div anyway, and that allows div child
 elements that can be used as targets for the references. There are more
 ways to do this, though, and I believe RFC 7992 shouldn't mandate a
 specific way to do it.

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/378#comment:2>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Sat, 17 Nov 2018 18:53:45 -0000

Yes, in many places in the html renderer I use enclosing divs in order to
 have something for an ID to be attached to.  In some cases, such as link
 targets for caption text links, I use spans inserted immediately in front
 of a table or figure.  In this case, the idiocy of the specification and
 the extent of the special-casing needed in the code made me choose a
 different path.

 With respect to cluelessness of the RFC 7992 text in this area, see also
 https://tools.ietf.org/html/rfc7992#section-5.1 (mentioned in
 https://zin.tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-
 notes-06#section-4.2.1)

 Doing something else isn't hard, it's just a bother to work from a
 clueless specification.  Is there any fundamental reason to prefer
 enclosing divs as opposed to sibling spans when in an inline rendering
 context?

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/378#comment:3>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Sat, 17 Nov 2018 19:07:07 -0000

It's really a matter of taste.

 I like the enclosing model when it's used for the user-specified anchor.

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/378#comment:4>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Sat, 17 Nov 2018 19:45:02 -0000

Ok, thanks Julian.

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/378#comment:5>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Sat, 17 Nov 2018 19:48:01 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 Fixed in [2750]:

 Added back the ability to place <iref> elements in locations where they
 will translate to invalid HTML.  Avoided invalid HTML by pushing the span
 up one level, as a previous sibling, when needed.  Fixes issue #378.

-- 
------------------------------------+--------------------
  Reporter:  [email-masked]  |      Owner:
      Type:  defect                 |     Status:  closed
  Priority:  medium                 |  Milestone:
 Component:  Version_3_cli_txt      |    Version:  2.13.x
Resolution:  fixed                  |   Keywords:
------------------------------------+--------------------

Ticket URL: </ticket/378#comment:6>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>