Subject: [xml2rfc] #262 (Version 2 cli): Add vspace to c, preamble, postamble

From: "xml2rfc issue tracker" <[email-masked]>
Date: Mon, 30 Jun 2014 03:32:44 -0000

#262: Add vspace to c, preamble, postamble

 I have an I-D that needed line breaks in table cells, but xml2rfc 2.4.8
 doesn't support <vspace> in c, preamble, or postamble. So, I added support
 for that!

 Please see the attached patch file. The patch also includes a tangential
 fix for a typo in the source code, "outpur" to "output".

-- 
----------------------------------+----------------------------------
 Reporter:  [email-masked]  |      Owner:  [email-masked]
     Type:  enhancement           |     Status:  new
 Priority:  major                 |  Milestone:
Component:  Version 2 cli         |    Version:  2.4.x
 Keywords:  vspace                |
----------------------------------+----------------------------------

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

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Mon, 30 Jun 2014 07:06:54 -0000

Comment (by [email-masked]):

 I don't believe we should do this right now. Let's put the energy into
 coming up with a proper table model in v3 instead.

-- 
-----------------------------------+----------------------------------
  Reporter:  [email-masked]  |      Owner:  [email-masked]
      Type:  enhancement           |     Status:  new
  Priority:  major                 |  Milestone:
 Component:  Version 2 cli         |    Version:  2.4.x
Resolution:                        |   Keywords:  vspace
-----------------------------------+----------------------------------

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

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Mon, 30 Jun 2014 09:44:42 -0000

Comment (by [email-masked]):

 Well, it's already done. The patch already adds support for it, and the
 functionality works well.
 I understand that you really want to come up with a "proper table model"
 in v3. That's fine. vpsace is deprecated in v3.

 But in v2, vspace is alive and well, and people are using it in their
 specifications. Let's make v2 count. Thanks.

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

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Mon, 30 Jun 2014 09:54:12 -0000

In v2, vspace is not allowed in the place where you are using it. The fact
 that it's allowed elsewhere is totally irrelevant.

 Again, let's not put energy into things we'll change in v3 anyway, and in
 particular not if it's clearly a nice-to-have.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Jun 2014 10:25:30 -0400

>   particular not if it's clearly a nice-to-have.

Julian - it is not like it is *your* energy. If the people who are doing 
the work want to do it then why object?

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 30 Jun 2014 07:35:18 -0700

On Jun 30, 2014, at 7:25 AM, Paul Kyzivat <[email-masked]> wrote:

> Julian - it is not like it is *your* energy. If the people who are doing the work want to do it then why object?

I cannot speak for Julian, but I can say that people have asked us to not make the v2 schema a moving target. Many people would prefer stability of the format and the tools. The fact that, in 2014, someone discovers a change to v2 that would help them with one RFC is not a compelling reason to change.

--Paul Hoffman

---

From: Julian Reschke <[email-masked]>
Date: Mon, 30 Jun 2014 16:39:14 +0200

> the work want to do it then why object?

- another thing that needs to be converted once we switch

- invalid XML the RFC production center will need to deal with

- people asking for support in rfc2629.xslt

So yes, it *will* affect me as well.

Help reviewing the "v3" draft -- that's what would be helpful.

Best regards, Julian

---

From: Tony Hansen <[email-masked]>
Date: Mon, 30 Jun 2014 10:55:23 -0400

On 6/30/14, 10:25 AM, Paul Kyzivat wrote:
> Julian - it is not like it is *your* energy. If the people who are 
> doing the work want to do it then why object?

And there's the rub. You're not seeing the cascading affect of this 
modification.

A change like this doesn't just affect the python code, which was 
provided. (Thank you.) But it ALSO affects the grammar, which has not 
been addressed at all by the provided patch.

And Julian (and a bunch of others) are currently involved in a process 
of documenting the *current* v2 grammar (not extending it). So it does 
DIRECTLY affect his (and others') work load.

A change to the grammar ALSO affects other processors that use that same 
grammar. The v2 python code is not the only code that would need to 
change if someone starts adding <vspace/> in places that the grammar 
does not currently allow.

We would REALLY love to consider the v2 grammar to be frozen and avoid 
what (to us) is an extremely late suggestion.

On the flip side, there is a parallel effort defining the new v3 
grammar, which DOES have a variety of extensions (and deprecations).

The discussion has shown to me (at least) that <c> is a place where the 
functionality of "add a blank line here" or "add a line break here" 
would be useful.

The way we addressed this in the v3 grammar for lists (which have a 
similar desire for the functionality) was to allow the <li> element used 
within <ul>/<dl>/<ol>'s to have multiple <t/> elements.

This suggests to me that we should all look at if the v3 grammar should 
provide a way to also gain similar functionality. Perhaps it can do 
something similar to <li>.

     Tony Hansen

PS. The current v2 grammar can be found in draft-reschke-xml2rfc. The 
proposed v3 grammar can be found in draft-hoffman-xml2rfc.

---

From: Sean Leonard <[email-masked]>
Date: Mon, 30 Jun 2014 08:38:06 -0700

On 6/30/2014 7:55 AM, Tony Hansen wrote:
> [...]
> The discussion has shown to me (at least) that <c> is a place where 
> the functionality of "add a blank line here" or "add a line break 
> here" would be useful.

I am willing to assist with documenting, so as to reduce the work load 
of others. It was not my intent to dump work on other people. As a tool 
or product becomes more popular, more users will find increasingly 
diverse uses for it. Inflexibility of a tool only encourages users to 
migrate elsewhere.

In the patch file add-vspace.patch, I also modified the rfc2629.dtd 
grammar. By "the grammar", do you also mean the I-D 
draft-reschke-xml2rfc? If so I can supply the requisite text for 
draft-reschke-xml2rfc-10 prior to the cutoff time on Friday. It may be a 
late suggestion, but from the perspective of newcomers to (this part of) 
xml2rfc, it is an obvious omission.

Respectfully submitted, Sean Leonard

---

From: Julian Reschke <[email-masked]>
Date: Mon, 30 Jun 2014 17:43:40 +0200

On 2014-06-30 17:38, Sean Leonard wrote:
> ...
> ...

The v2 grammar is fixed. We are not making any changes on it anymore. 
The whole point of the exercise was to document what's implemented and 
take that as a basis for the v3 discussions.

Best regards, Julian

---

From: Tony Hansen <[email-masked]>
Date: Mon, 30 Jun 2014 12:17:01 -0400

On 6/30/14, 11:38 AM, Sean Leonard wrote:
>> And Julian (and a bunch of others) are currently involved in a 
>> process of documenting the *current* v2 grammar (not extending it). 
>> So it does DIRECTLY affect his (and others') work load.
>> [...]
> of others. It was not my intent to dump work on other people. As a 
> tool or product becomes more popular, more users will find 
> increasingly diverse uses for it. Inflexibility of a tool only 
> encourages users to migrate elsewhere.
>
> draft-reschke-xml2rfc-10 prior to the cutoff time on Friday. It may be 
> a late suggestion, but from the perspective of newcomers to (this part 
> of) xml2rfc, it is an obvious omission.

You're ignoring the rest of my message. Please direct your energies on 
how to make the v3 grammar better, not changing the existing v2 grammar. 
Thank you.

     Tony Hansen

---

From: Sean Leonard <[email-masked]>
Date: Mon, 30 Jun 2014 10:17:02 -0700

On 6/30/2014 7:55 AM, Tony Hansen wrote:
> similar desire for the functionality) was to allow the <li> element 
> used within <ul>/<dl>/<ol>'s to have multiple <t/> elements.
>
> This suggests to me that we should all look at if the v3 grammar 
> should provide a way to also gain similar functionality. Perhaps it 
> can do something similar to <li>.

The topic here is being forked to "adding line breaks to v3".

 From my experience with the current xml2rfc, there is no way (other 
than <vspace>) to break a line with <t> or <list> elements, such that 
there are no blank spaces between the resulting text blocks.

I.e., I want:
***
Foo
Bar
Baz
***
not:
***
Foo

Bar

Baz
***

If you permit <li> (or lists in general) as children of <c> in the v3 
grammar, how can you smush the lines so that they are not separated by a 
blank line? If you add <t> elements as children of <c> in the v3 
grammar, how can you smush the lines so that they are not separated by a 
blank line? I do not see a way unless you add some attributes like 
vspacebefore="0" and vspaceafter="0".

My proposal is simple: create a new element, <br>, that can appear as 
children of <t> and in <c>. The element has a 1:1 correspondence with 
HTML/XHTML, and matches the general trend in draft-hoffman-xml2rfc of 
having elements like <b>, <em>, <sub>, <sup>, etc., which are imports 
from HTML/XHTML.

-Sean

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 30 Jun 2014 10:48:24 -0700

On Jun 30, 2014, at 10:17 AM, Sean Leonard <[email-masked]> wrote:

>> The discussion has shown to me (at least) that <c> is a place where the functionality of "add a blank line here" or "add a line break here" would be useful.
>> 
>> The way we addressed this in the v3 grammar for lists (which have a similar desire for the functionality) was to allow the <li> element used within <ul>/<dl>/<ol>'s to have multiple <t/> elements.
>> 
>> This suggests to me that we should all look at if the v3 grammar should provide a way to also gain similar functionality. Perhaps it can do something similar to <li>.
> 

Discussions of the v3 format should take place on the [email-masked] mailing list. There is already a huge amount in the archives.

> From my experience with the current xml2rfc, there is no way (other than <vspace>) to break a line with <t> or <list> elements, such that there are no blank spaces between the resulting text blocks.
> 
> I.e., I want:
> ***
> Foo
> Bar
> Baz
> ***
> not:
> ***
> Foo
> 
> Bar
> 
> Baz
> ***
> 
> If you permit <li> (or lists in general) as children of <c> in the v3 grammar, how can you smush the lines so that they are not separated by a blank line? If you add <t> elements as children of <c> in the v3 grammar, how can you smush the lines so that they are not separated by a blank line? I do not see a way unless you add some attributes like vspacebefore="0" and vspaceafter="0".
> 
> My proposal is simple: create a new element, <br>, that can appear as children of <t> and in <c>. The element has a 1:1 correspondence with HTML/XHTML, and matches the general trend in draft-hoffman-xml2rfc of having elements like <b>, <em>, <sub>, <sup>, etc., which are imports from HTML/XHTML.

That is possible. Another possibility is for us to deprecate the text tables in favor of tables that are much more like HTML. That's been discussed there too.

--Paul Hoffman