Subject: [xml2rfc] will <vspace=n> disappear

From: Loa Andersson <[email-masked]>
Date: Thu, 16 Oct 2014 16:19:55 +0200

Folks,

Hope this is the correct mailing list :)!

I tested the v2 to v3 converter that Tony circulated. Both the v3 
definition and the converter is a good job.

However I'm not happy the the vspace will disappear, apart from
that is is an easy way to create simple lists it is also useful
in development of a draft, i.e. I can put line breaks and comments
where I need and the is simple to remove.

Would it be possible to to keep a simple vspace, line feed or line
break element?

And then I have a question on the author element, it seems that you
allow "organizations to be authors", I thought that was against IETF
policies, everything should be contributed by a real live person.

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Tony Hansen <[email-masked]>
Date: Thu, 16 Oct 2014 11:28:41 -0400

Replies to this message should go to the RFC Interest mailing list.

     Tony Hansen

> definition and the converter is a good job.

I'm glad the converter has been useful.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 16 Oct 2014 17:33:53 +0200

> that is is an easy way to create simple lists it is also useful

Lists should be created with list elements :-)

> Would it be possible to to keep a simple vspace, line feed or line

What's the use case for enforcing a line break?

> policies, everything should be contributed by a real live person.

The author element is also used in <reference>s, where the thing being 
referenced might be a non-IETF document.

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 16 Oct 2014 18:43:04 +0200

In kramdown-rfc2629, I am generating vspace for the following cases:

— forced page breaks (<vspace blankLines='999' />)
  This is clearly a hack, but the need for tweaks like this is there as long as people are looking at the pages-based versions.
— to separate multiple paragraphs in a list item (since every new t element starts a new list item)
— for definition lists, where for some applications the dd should be on its own line (please see:
  https://github.com/cabo/kramdown-rfc2629/issues/3 ), as in  <t hangText=‘definition label:'><vspace blankLines='0'/>
— for line breaks without increased leading, which are needed in particular for semi-structured material such as media type definitions (yes, one can sometimes fall back to code blocks here, but that doesn’t look that great in HTML then).

I haven’t checked whether these are covered in v3.

Grüße, Carsten

---

From: Sean Leonard <[email-masked]>
Date: Thu, 16 Oct 2014 10:01:26 -0700

> Would it be possible to to keep a simple vspace, line feed or line

+1!!!

Look—here is the situation.

"LINE BREAK" is a basic element of punctuation in modern written 
languages, at the same semantic level as period, space, and paragraph. 
The distinction was recognized in Unicode and is written up in UTR #13: 
Unicode Newline Guidelines 
<http://www.unicode.org/standard/reports/tr13/tr13-5.html>. That is why 
U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR exist. That is also 
why <br> and <p> exist in HTML.

The fact that US-ASCII (ANSI X.34) never distinguished between line 
breaks and paragraph separators is inapposite. It was invented in the 
Before Time, when people thought it was just as important to encode BEL 
(07h) sounds. Codes less than 20h (and DEL 7Fh) were meant to /send 
commands to output devices/, not represent semantic elements of human 
languages.

Please, we need line breaks.

Kind regards,

Sean

---

From: Julian Reschke <[email-masked]>
Date: Thu, 16 Oct 2014 19:28:55 +0200

> Please, we need line breaks.

Again: use case?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 16 Oct 2014 19:32:48 +0200

>    This is clearly a hack, but the need for tweaks like this is there as long as people are looking at the pages-based versions.

In the new RFC format, pagination plays a less important role. The 
intent is to have a vocabulary sufficiently expressive so that the tools 
can do the right thing.

> — to separate multiple paragraphs in a list item (since every new t element starts a new list item)

We fixed the vocabulary for this use case.

>    https://github.com/cabo/kramdown-rfc2629/issues/3 ), as in  <t hangText=‘definition label:'><vspace blankLines='0'/>

I believe we have a special element/construct for this as well.

> — for line breaks without increased leading, which are needed in particular for semi-structured material such as media type definitions (yes, one can sometimes fall back to code blocks here, but th…

I've been doing media type definitions with lists for years, and nobody 
has complained. You don't need to follow the templates exactly with 
respect to whitespace; it's the content that counts...

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 16 Oct 2014 20:44:01 +0200

On 2014-10-16 20:11, Charlie Perkins wrote:
> Hello folks,
>
> I think it is crucial to be able to insert page breaks.  One
> use case is to improve readability when passages of text
> should be kept together.  Or lists...

The formatter should be able to do that without additional hints.

> It doesn't seem right to encourage putting in more
> and more sections of "artwork" for this purpose.

Did anybody suggest that?

> By the way, is there a mailing list for people who have
> questions about using xml2rfc but not the time to devote
> to becoming experts and exploring every random bit of
> documentation that might be applicable?  Somehow
> this mailing list does not seem to be the right one...

It's the best we have :-)

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 16 Oct 2014 21:11:46 +0200

On 2014-10-16 21:07, Charlie Perkins wrote:
>
> Hello Julian,
>
> Thanks for your response.
>
> On 10/16/2014 11:44 AM, Julian Reschke wrote:
> How do we do that?

We fix the formatter.

> No explicit suggestion, but if that's the only way I know
> how to control where the text should go, it's one way
> to get the job done.

Don't.

> Thanks -- I might have to ask questions once in a while...

Please go ahead!

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Oct 2014 08:39:54 +1300

> Did anybody suggest that?

No, but it's exactly what will happen if there is no equivalent
of <br>. (I can't think of anything that I might ever want to
do with <vspace/> that I couldn't do in html with a few <br>s,
so I'd be very glad to see the back of <vspace> as it exists
today.)

I don't think we need explicit use cases to know that sometimes
people will want to do some kind of visual layout without
leaving any decisions up to the rendering engine. Certainly,
whenever I've used <vspace/> that has been the underlying issue.

(I agree that in the new regime we can't have an explicit page
break. I do wonder whether we don't need something explicit to
help the widow/orphan logic in some cases.)

   Brian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 16 Oct 2014 21:48:59 +0200

On 2014-10-16 21:39, Brian E Carpenter wrote:
> ...
> ...

Again, what would be helpful at this point was an example where you need 
to enforce a line break which is not addressed in the proposed v3 
vocabulary.

> help the widow/orphan logic in some cases.)

Again, a concrete example would help.

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 16 Oct 2014 22:23:48 +0200

On 16 Oct 2014, at 18:50, Joe Touch <[email-masked]> wrote:

> Is there some reason not to use a "pagebreak" indicator?

There isn’t one in the vocabulary.

> The above doesn't insert a pagebreak; it adds vertical space

Yes, that’s why I said it is a hack.
(For .txt output, the vertical space is truncated by the page length, which is known to be less than 999 lines.
For .html output, xml2rfcv2 generates 999 <br/> elements, which is not what one would want.)

I listed those usages of vspace not because I wouldn’t be happy for it to go away, but just to point out that those usages need to be covered by any vocabulary that doesn't have vspace.

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Thu, 16 Oct 2014 22:29:02 +0200

> For .html output, xml2rfcv2 generates 999 <br/> elements, which is not what one would want.)

We could fix that. How often is it used?

> I listed those usages of vspace not because I wouldn’t be happy for it to go away, but just to point out that those usages need to be covered by any vocabulary that doesn't have vspace.

Absolutely. And that's why I keep asking for the use case :-)

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 16 Oct 2014 22:40:33 +0200

On 2014-10-16 22:30, Joe Touch wrote:
>
>
> On 10/16/2014 12:39 PM, Brian E Carpenter wrote:
> ...
> There are many cases where it's useful to control such things:
>
> 	- tables (either render it in a single screen/page or
> 	control where it breaks)

So you want to add a hint about what is a good point to break a table?

> 	- lists, especially hierarchical ones
> 		(it's preferable to break only before toplevel items)

I think that rule could be automated, right?

> I agree that pagebreak itself isn't useful - it just as
> rendering-specific as vspace.
>
> Joe
>

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 16 Oct 2014 23:47:01 +0200

On 16 Oct 2014, at 19:32, Julian Reschke <[email-masked]> wrote:

> In the new RFC format, pagination plays a less important role. The intent is to have a vocabulary sufficiently expressive so that the tools can do the right thing.

As long as we use paper (or paper-like formats such as PDF), pagination will be important.

We have some 50 years of experience with automatic formatters that tells us that placement problems occasionally need tweaks.  So I hope some page-break like tweaking (and, preferably, also something close to troff’s .ne) will be possible in xml2rfcv3.

> We fixed the vocabulary for this use case.

I think you are referring to the substructure of <li>, which looks good.

> I believe we have a special element/construct for this as well.

The »hanging« attribute looks great for this.

> I've been doing media type definitions with lists for years, and nobody has complained. You don't need to follow the templates exactly with respect to whitespace; it's the content that counts…

I’m sorry, as the editor of an RFC I have higher standards than that.
There is a reason some form of line-breaking is part of just about any vocabulary for publishing.
(<ul spacing=“compact” empty=“true”> is a hack, and I’m not sure whether empty labels still imply additional indentation or not.)

Grüße, Carsten

---

From: Loa Andersson <[email-masked]>
Date: Thu, 16 Oct 2014 23:47:21 +0200

Brian,

> so I'd be very glad to see the back of <vspace> as it exists

I don't particular care what is between the < > as long as can
break the line. My use case is mostly that I put info for myself
while editing. The <vspace> or <br> i something simple that I can
remove without thinking about how it will effect other elements
once I'm done.

/Loa

--

---

From: Julian Reschke <[email-masked]>
Date: Thu, 16 Oct 2014 23:52:50 +0200

> remove without thinking about how it will effect other elements

"info for myself" sounds like a case for either XML comments or the 
<cref> element.

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 17 Oct 2014 00:59:29 +0200

> We could fix that. How often is it used?

There are approximately 20 000 occurrences of <vspace in the ~ 1500 XML files I have for RFCs.
The majority of these appear to be for line breaks (e.g., see Appendix A of RFC 4948); some (> 3000) are clearly for formatting tweaks in lists.

I find approximately 200 usages that look like they are for page breaks.
These are in approximately 84 XML files (~ 5 % of the total I looked at).
(I may have missed some comment markers, so the actual number may be slightly lower.)

Grüße, Carsten

PS.: My favorite hit (the authors clearly were aware that this usage is evil):

rfc5889.xml:130:<t><vspace blankLines="666"/></t>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Oct 2014 16:43:34 +1300

On 17/10/2014 09:52, Joe Touch wrote:
> 
> On 10/16/2014 1:40 PM, Julian Reschke wrote:
> Not so much where to break as where NOT to break:
> 
> 	item		break before?	break after?

I can actually see two things I might want to say. They would
both be hints to the rendering algorithm.

<please-do-not-break-if-possible>
important stuff that should be kept together if possible
</please-do-not-break-if-possible>

and

<if-you-must-break-do-it-here/>

    Brian

> 
> 	header		yes		no
> first 2 items		no		yes
> middle items		yes		yes
> last 2 items		no		after last item
> 
> However, it might be useful to control that, for the same reason as with
> hierarchical lists. If you have a table with items that are grouped, you
> might want the same "keep with previous" or "keep with next" identifier
> that is currently useful for paragraphs and lists (though those don't
> appear to be in V3, I use them all the time in modern word processors)
> 
> It could, but it's useful to have user ability to override.
> 
> Joe
> .
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Oct 2014 16:45:58 +1300

> to enforce a line break which is not addressed in the proposed v3

I'm afraid you are asking for an unknown unknown. I have no answer.

    Brian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Oct 2014 11:53:05 +0200

> rfc5889.xml:130:<t><vspace blankLines="666"/></t>

I did similar stats in February, see 
<http://www.ietf.org/mail-archive/web/xml2rfc/current/msg04432.html>.

The question is whether the specific use of vspace to create a form feed 
happens frequent enough to justify special support in HTML (where it 
would only apply to printing/paged media), given the fact that in the 
new RFC format world, pagination is much much less important than it 
used to.

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 17 Oct 2014 14:27:16 +0200

On 17 Oct 2014, at 11:53, Julian Reschke <[email-masked]> wrote:

> The question is whether the specific use of vspace to create a form feed happens frequent enough to justify special support in HTML (where it would only apply to printing/paged media), given the fact that in the new RFC format world, pagination is much much less important than it used to.

The answer is that we don’t know how life in that brave new world will be.
All we know is that page-based media will continue to exist.

(HTML already supports page-breaking via CSS, so maybe I don’t really understand this sentence in the first place.  The point here is that we need a way (element, attribute, pi) to insert the tweak into the source.)

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Oct 2014 15:14:44 +0200

> All we know is that page-based media will continue to exist.

Yes, but the default format that people will use will not use page 
breaks (unless when printed, and then they will vary based on font 
settings, paper size, whatnot).

> (HTML already supports page-breaking via CSS, so maybe I don’t really understand this sentence in the first place.  The point here is that we need a way (element, attribute, pi) to insert the tweak…

Enforcing a page break usually depends on knowledge where the previous 
page break happened. If that varies (and it will), there's no point in 
trying to do this.

Suggesting a good place for a page break (or suggesting what to keep 
together) can indeed be useful, but should be inherent in our 
vocabulary. So again, I'd like to see a concrete use case where a well 
implemented default behavior needs to be overridden.

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 17 Oct 2014 22:39:44 +0200

On 17 Oct 2014, at 19:52, Joe Touch <[email-masked]> wrote:
> 
> Is there a way to determine whether this was due to the tool used to
> generate the XML or by the explicit author insertion?

[this = page break insertion]

I’m not even aware which tools are being used to generate the XML for RFCs (except for pandoc-rfc, which just carries through vspace elements [1] as specified by the author, and kramdown-rfc2629, which generates page break tweaks based on author input).  Generic XML tools would have no idea about the vspace element.

Grüße, Carsten

[1] RFC 7328: »
   o  The "<vspace>" tag is supported and carried over to the generated
      XML.
«

PS.: I’d sure like to know which weird tool generated the 7488 <vspace/> elements in rfc6716.xml...

---

From: Miek Gieben <[email-masked]>
Date: Fri, 17 Oct 2014 22:09:13 +0100

[ Quoting <[email-masked]> in "Re: [xml2rfc] [rfc-i]    will <vspa..." ]
>   o  The "<vspace>" tag is supported and carried over to the generated

But note that I've done this purely because xml2rfc v2 needs it in some places.
With xml2rfc v3 I see no need for it, and I've removed support for it in my
v3 pandoc2rfc branch [*]

/Miek

-- 
Miek Gieben

[*] https://github.com/miekg/pandoc2rfc/tree/v3 (work-in-progress)

---

From: Nico Williams <[email-masked]>
Date: Thu, 23 Oct 2014 15:38:11 -0500

> Again: use case?

The use cases were given, but they aren't use cases for "vertical
blank space".  They are use cases for other things:

 - multi-paragraph list items (I forget if in v3 the schema supports
this properly)

   (lyx2rfc and kramdown-rfc2629 use vspace for this.)

 - weak control over where page breaks are placed

The former should be a first-class feature of the v3 schema.

The latter is only necessary for paginated formats, but it comes in
real handy for those.  I agree with Brian C. about this, we need some
elements for hinting about what text is too precious to split, and
what text isn't, then the paginator can probably do the Right Thing.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 23 Oct 2014 15:46:07 -0500

On Fri, Oct 17, 2014 at 4:53 AM, Julian Reschke <[email-masked]> wrote:
> happens frequent enough to justify special support in HTML (where it would
> only apply to printing/paged media), given the fact that in the new RFC
> format world, pagination is much much less important than it used to.

Let's not get into that debate (to paginate or not).  Instead let's
agree that some people really want to paginate.  Doesn't matter why.
Paper fetish?  OCD?  Aspergers?  whatever, it's not your place to deny
them, though you might not implement this feature.  Let them (us) say
"don't page break in this paragraph" or "if you must, break around
here".

Defining such elements, making them meaningless in non-paginated
media, and OPTIONAL to implement in paginated media, should suffice.

Nico
--

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Oct 2014 16:52:56 -0400

> media, and OPTIONAL to implement in paginated media, should suffice.

But manual insertion of pagination points doesn't work right when there 
are multiple output formats that may need to break at different points.

The appropriate pagination points for txt format may be quite different 
from those for HTML. And the break points for HTML depend on printer 
settings.

	Thanks,
	Paul

---

From: Julian Reschke <[email-masked]>
Date: Thu, 23 Oct 2014 22:55:10 +0200

>   - multi-paragraph list items (I forget if in v3 the schema supports

It does.

> The former should be a first-class feature of the v3 schema.

It is.

> what text isn't, then the paginator can probably do the Right Thing.

The question is whether the vocabulary has sufficient information, or 
whether we need more.

The one use case I've seen is grouping table rows; anything else?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 23 Oct 2014 23:00:18 +0200

> "don't page break in this paragraph" or "if you must, break around

I'd prefer that what the formatter implements wrt page breaking in 
paragraphs produces consistently good output. Do we *really* need 
additional hints?

> media, and OPTIONAL to implement in paginated media, should suffice.

But then, it would also be good to avoid new features that aren't really 
needed.

Maybe we can have this discussion once we have prototypes that *do* 
produce paginated output but fail to paginate in the "right" place? When 
that happens, we can discuss whether that's a bug in the formatter, or 
indeed a shortcoming of the vocabulary.

Best regards, Julian

---

From: Nico Williams <[email-masked]>
Date: Thu, 23 Oct 2014 16:06:27 -0500

On Thu, Oct 23, 2014 at 3:52 PM, Paul Kyzivat <[email-masked]> wrote:
> But manual insertion of pagination points doesn't work right when there are
> multiple output formats that may need to break at different points.

I don't want manual insertion of pagination points.  I want manual
hints as to text too precious to break up, as well as hints to
locations where page breaks would be more welcomed than for all
others.

Nico
--

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 23 Oct 2014 15:31:31 -0700

Hello Julian,

For other use cases:
- I already mentioned that some lists belong on a single page
- Similarly a figure caption should be on the same page as the figure
- I prefer not to have a single line of a section alone on a page,
    especially for short sections.  If the section header appears
    alone at the bottom of a page that is even worse.

One way to find out the use cases is to have xml2rfc report
when people use page break, analyze the need, propose a
better solution, and verify with the document writer.  I reckon
that darned near 100% of the writers would be glad to help,
and after a few months the temporary page break feature
could be removed.

Just an idea.

Regards,
Charlie P.

On 10/23/2014 1:55 PM, Julian Reschke wrote:
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml2rfc
>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 23 Oct 2014 15:39:46 -0700

> locations where page breaks would be more welcomed than for all

Would this only be in <artwork> and <sourcecode>? Or other places?

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Thu, 23 Oct 2014 18:18:54 -0500

> Would this only be in <artwork> and <sourcecode>? Or other places?

Great question.  These are the cases I can think of:

 - multi-paragraph list items: it may be better to break between items
than between paragraphs (this could be an attribute of the list and/or
list items, and the default could be to prefer breaking between
items);

 - tables: group the leading and trailing N rows so that one never
sees just one row on a page (this could be an attribute of the table
element though, and the default could be N=3 for tables with six or
more rows, N=2 for tables with four or five rows, and N=<number of
rows> for tables with fewer than four rows);

 - <artwork> and <sourcecode>, indeed (this could be an attribute of
<artwork> and <sourcecode>);

 - paragraphs: try not to break in the middle of this paragraph (this
could be an attribute of <t>, defaulting to allow breaks);

 - groups of paragraphs: try not to break in the middle of these
paragraphs (this could be an element, or a list with no indentation
and no bullets, and just one multi-paragraph item);

 - general preference to break between paragraphs, never in the middle
of a paragraph (this could be an attribute of <rfc> and <section>,
defaulting to allow breaks anywhere).

For the last two cases the main use case is to make it easier for
readers to have all of some critical part of the RFC available on the
same page (e.g., security considerations text).

In all of these cases the page break hints will be advisory (e.g., if
some artwork does not fit on a page, it must be split), and
non-critical (rendering can't fail if the break preference can't be
met).

Nico
--

---

From: Julian Reschke <[email-masked]>
Date: Fri, 24 Oct 2014 08:01:33 +0200

> - I already mentioned that some lists belong on a single page

Yes, and I believe the formatter has sufficient information already.

> - Similarly a figure caption should be on the same page as the figure

Yes. Why does the formatter need a hint for that?

>     alone at the bottom of a page that is even worse.

Again. No hint needed.

> and after a few months the temporary page break feature

I'd prefer to do it exactly the other way around.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 24 Oct 2014 11:15:13 +0200

> list items, and the default could be to prefer breaking between

How frequently is this relevant in practice?

> rows> for tables with fewer than four rows);

Would we ever need something different from these defaults?

> <artwork> and <sourcecode>);

An attribute saying what?

> could be an attribute of <t>, defaulting to allow breaks);

What would be a case where you would try to avoid breaking inside a 
paragraph?

> same page (e.g., security considerations text).

That sounds like a fix to a problem that's caused by looking at 
paginated output in the first place :-)

I have trouble seeing why certain sections need "keep-on-same-page" 
while others do not. The example of Security Considerations sounds very 
arbitrary to me.

> non-critical (rendering can't fail if the break preference can't be

Of course.

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 24 Oct 2014 11:41:56 +0200

On 24 Oct 2014, at 08:01, Julian Reschke <[email-masked]> wrote:
> No hint needed.

A useful example to ponder may be draft-ietf-6lo-ghc-05

This would be much harder to read without the tweaks.

Requiring the author to provide hints to a level of detail that makes this manual intervention unnecessary doesn’t sound very productive.  (Yes, I have been drinking the “declarative markup” Kool-Aid since 1982.  I just know it’s not always the best way.)

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Fri, 24 Oct 2014 12:15:15 +0200

> Requiring the author to provide hints to a level of detail that makes this manual intervention unnecessary doesn’t sound very productive.  (Yes, I have been drinking the “declarative markup” Kool-A…

Thanks for the concrete example.

We're talking about the appendix, right?

You can instruct xml2rfc (v1) to keep text together with artwork by 
moving it into <preamble>. (Yes, tested)

This however doesn't do what you want when the artwork alone would fit 
onto a page, but including the preamble, won't. In this case, xml2rfcv1 
will keep the preamble on the same page as the artwork, but break the 
artwork.

Is it more important to keep the preamble with the artwork, or to avoid 
breaking inside the artwork?

In general, the more "unbreakable" things there are, the harder it is 
for the page breaking to do something useful without overrides. In this 
case, I'd probably reformat the examples into smaller chunks (v3 will 
allow multiple <artwork> elements in one <figure>).

Best regards, Julian

---

From: Loa Andersson <[email-masked]>
Date: Fri, 24 Oct 2014 12:35:41 +0200

Folks,

The way I see this is that I don't particular care what is
within the <here/> as long as it give me a line break and is
not <here> paragraph </here>. Just one single element that gives
me the the line break.

I think I agree with most of what Julian says "not needed for RFC
and final formatting". Though we have some cases where folks think
it is useful.

We need the xml to write RFCs and IDs, that is slightly different.
I guess I've removed most of the <vspace> elements when document is
in its production form.

But when developing the ID the <vspace blankLines="1" /> is extremely
useful.

/Loa

On 2014-10-24 11:41, Carsten Bormann wrote:
> rfc-interest mailing list
> [email-masked]
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>

--

---

From: Julian Reschke <[email-masked]>
Date: Fri, 24 Oct 2014 13:03:09 +0200

> But when developing the ID the <vspace blankLines="1" /> is extremely

Can you explain why it's more useful "when developing"?

Best regards, Julian

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 24 Oct 2014 11:35:59 -0400

>  - multi-paragraph list items (I forget if in v3 the schema supports
[etc.]

This being the universe of computers, we've been down this road
before.  Viz., it comes time to reform some part of the universe, and
for all sorts of good reasons, the Great New Thing incorporates all
and only the things that we have good arguments for.  For instance, we
stopped writing system software in assember and started writing it in
Pascal, which was carefully designed to let you express the things you
should be able to express and not express the things you shouldn't.

Then we suddenly discover that there are things we need to express
that we really *shouldn't* have to express, but somehow we *do* have
to express.  For instance, people quckly found that Pascal doesn't let
you do those tricky, ugly little things that save so much processing
if you can just do the trick once in 10,000 lines of code.  The result
is we write our system software in C, which lets you do as those
horrible tricks, not Pascal.

The real test of a new vocabulary is to rewrite a large sample of
documents in the new vocabulary and *see what breaks*.  Because if you
don't test it in reality, you can easily be designing the next Pascal.

Dale

---

From: Nico Williams <[email-masked]>
Date: Fri, 24 Oct 2014 11:07:24 -0500

> don't test it in reality, you can easily be designing the next Pascal.

This is not a completely objective test because "what breaks" is a
matter of subjective opinion.

We're having this [recurring] debate precisely because the matter is
subjective, and reasonable people can disagree as to "what breaks".

Nico
--

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 24 Oct 2014 09:47:49 -0700

Hello Julian,

My suggestion to allow page break was exactly for the
reason that it's sometimes difficult to predict when one
might need it, and a few months of using the new
system but including the page break might be long enough
to uncover the other use cases I didn't mention.

> Yes, and I believe the formatter has sufficient information already.

Could you provide one sentence that describes the algorithm and
what information it uses?

>>     alone at the bottom of a page that is even worse.

It sounds to me like these will not be a problem -- good to hear that.

> I'd prefer to do it exactly the other way around.

Yes, that is clear.  I only suggested it because prediction is much
much harder than hindsight.

Regards,
Charlie P.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 24 Oct 2014 19:02:31 +0200

> what information it uses?

No, because I don't know the internals of the current formatter. You may 
want to look up the source code (it's on tools.ietf.org).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 24 Oct 2014 19:13:55 +0200

> don't test it in reality, you can easily be designing the next Pascal.

Hint: there already is a conversion tool (written by Tony).

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 25 Oct 2014 16:25:29 +0200

On 24 Oct 2014, at 12:15, Julian Reschke <[email-masked]> wrote:
> 
> In general, the more "unbreakable" things there are, the harder it is for the page breaking to do something useful without overrides. In this case, I'd probably reformat the examples into smaller chunks (v3 will allow multiple <artwork> elements in one <figure>).

As an author, I’d rather put the page breaks where they make sense and be done with it.
While hinting is great for the first 80 %, there is no known way to infuse a formatter with *all* the considerations that are immediately obvious to a human observer.

I think it is important to be able to put in such tweaks at the draft stage as well — this is the first time a specification gets many new readers, and it is worth it making their work easier.

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Sat, 25 Oct 2014 16:32:53 +0200

> As an author, I’d rather put the page breaks where they make sense and be done with it.

Well, in a world where pagination depends on font, font size and paper 
format, you can't put a page break somewhere. You *can* include hints, 
though.

> I think it is important to be able to put in such tweaks at the draft stage as well — this is the first time a specification gets many new readers, and it is worth it making their work easier.

I expect that once we're there, the majority of readers will actually 
read the HTML (which is a far bigger improvement than optimized page 
breaks in plain text).

Best regards, Julian

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 25 Oct 2014 12:53:30 -0400

> While hinting is great for the first 80 %, there is no known way to infuse a formatter with *all* the considerations that are immediately obvious to a human observer.

As Julian already said, manual page breaks don't work when the 
pagination will be done for different page sizes, etc.

> I think it is important to be able to put in such tweaks at the draft stage as well — this is the first time a specification gets many new readers, and it is worth it making their work easier.

When I am writing MSWord documents I am often tempted to put in manual 
page breaks. But I've found that doing so usually results in a massive 
waste of time, because then every time there is a change to the document 
I may have to tweak them again.

For the most part I have learned to just chill out and leave it to the 
pagination algorithm, and tolerate the inadequacies of the algorithm. It 
really isn't that important.

I agree that hinting is a possibility. (I do often try to use "keep 
together" and "keep with next" in MSWord, though they only rarely seem 
to do the right thing.)

IMO it would be better to put the work into the formatting tools - so 
that they work well without hints.

Regarding unbreakable stuff screwing up pagination algorithms, I don't 
think anything should be *totally* unbreakable. There might be a rule 
that says to keep all of a single artwork together, but that still must 
be violated if the artwork is bigger than the page size. ISTM that 
boundaries between words, paragraphs, sections, etc. should each have 
some degree of "stickiness". Then the pagination algorithm can run some 
sort of minimization algorithm.

	Thanks,
	Paul

---

From: Charlie Perkins <[email-masked]>
Date: Sun, 26 Oct 2014 06:36:12 -0700

Hello Paul and all,

On 10/25/2014 9:53 AM, Paul Kyzivat wrote:
>> While hinting is great for the first 80 %, there is no known way to 
>> infuse a formatter with *all* the considerations that are immediately 
>> obvious to a human observer.

This is why I was suggesting a period of time to allow page breaks
and to analyze why they might be needed by looking at actual
use patterns.

> pagination will be done for different page sizes, etc.

Does this mean that the current text format is disfavored?

>
>
>> I think it is important to be able to put in such tweaks at the draft 
>> stage as well — this is the first time a specification gets many new 
>> readers, and it is worth it making their work easier.

I agree with this.

> waste of time, because then every time there is a change to the 
> document I may have to tweak them again.

MSWord itself is a massive waste of time, but the main reason that
one can avoid page breaks is that MSWord has a trillion other features.
No one seems to know all of them.  It gets to be a contest to find anyone
that can properly format a parameter list, table with footnotes, etc.

And still I find I have to use page breaks.

> pagination algorithm, and tolerate the inadequacies of the algorithm. 
> It really isn't that important.

I have recently had a case where poor pagination caused an
incorrect understanding of the algorithm...

> that they work well without hints.

This is a great idea.  I feel skeptical that the upcoming release
can achieve the goal already, but I might be wrong.

> that says to keep all of a single artwork together, but that still 
> must be violated if the artwork is bigger than the page size. ISTM 
> that boundaries between words, paragraphs, sections, etc. should each 
> have some degree of "stickiness". Then the pagination algorithm can 
> run some sort of minimization algorithm.

Also agreed, but:
a) people don't make artwork that big for text files
b) does "ISTM" translate to be "I suppose that means"?

What if the page break directive were only to be used when the
desired output was text format?

Regards,
Charlie P.

---

From: Loa Andersson <[email-masked]>
Date: Sun, 26 Oct 2014 15:34:08 +0100

> Does this mean that the current text format is disfavored?

Actually I think Julian said:

I have not heard that we are changing any of these parameters for RFCs,
if we are then that would require quite a bit of transparency before
it is doen.

/Loa

--

---

From: Julian Reschke <[email-masked]>
Date: Sun, 26 Oct 2014 18:36:19 +0100

> if we are then that would require quite a bit of transparency before

It seems you have missed the news, then.

In the future, there will be no canonical paginated RFC format anymore. 
The canonical format will be XML, and the production center will 
generate HTML, PDF, and plain text from that. Page breaks in PDF and 
plain text will definitively be in different places.

Best regards, Julian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Oct 2014 07:47:16 +1300

> plain text will definitively be in different places.

I think Charlie and Loa, and probably a lot of other people,
really need to read draft-flanagan-rfc-framework and the various
references that it cites. Numerous trains have already left the
station.

   Brian

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 27 Oct 2014 10:12:58 -0400

> From: Nico Williams <[email-masked]>
> 

Then we are, in effect, going to have to decide who we care about
pleasing and who we do not care about pleasing.

Dale

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 27 Oct 2014 15:31:28 +0100

> pleasing and who we do not care about pleasing.

Or, depending on the complexity of such a solution, we might simply do something that serves all constituencies.

Grüße, Carsten

---

From: Tony Hansen <[email-masked]>
Date: Mon, 27 Oct 2014 11:50:57 -0400

On 10/27/14, 11:26 AM, Joe Hildebrand (jhildebr) wrote:
> I think the only possible way to deal with that mistake is to stop caring
> about precisely where the pagebreaks are, short of "whatever the best
> thing we can automate easily".  I know that's counter-intuitive for a lot
> of folks, particularly those that have worked with the existing tooling
> for a long time, so I'm willing to listen to other ways of thinking about
> this.  Particularly, if anyone wants to chat in Honolulu, I'll make time.

Using Word as an analogy, I've found that 99.99% of all manual page 
breaks can be avoided by judicious use there of "keep with next 
paragraph" and "keep with previous paragraph". Once set, I don't have to 
worry about when text is added and removed above the flagged text, or 
when different page sizes are used. These flags work remarkably well.

Having said that, and moving back to xml2rfc v3, I am a proponent of 
providing these options INSTEAD of a page break option.

In addition to that, I feel that section titles should automatically 
have this flag set, as well as figure captions, table heads and table 
captions. (There might be other places I'm not thinking of.)

I think this provides the ability to automate easily the major cases, 
and work in a way that deals with different output formats reliably.

     Tony Hansen

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 27 Oct 2014 09:02:37 -0700

Hello Tony,

I'm mostly in agreement with you, but 99.99% is an exaggeration.

At least I'd be a lot happier if we had the two directives you
mention, as well as the automatic flag setting you mentioned.

It would also be nice to avoid having paragraphs split so that
only a single word goes on the next page, etc.

I didn't see an answer to my suggestion to have page-break
effective only for the option to resemble current RFC format,
but I might have just missed it.

Regards,
Charlie P.

On 10/27/2014 8:50 AM, Tony Hansen wrote:
> paragraph" and "keep with previous paragraph". Once set, I don't have 
> to worry about when text is added and removed above the flagged text, 
> or when different page sizes are used. These flags work remarkably well.
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 27 Oct 2014 17:04:11 +0100

One of the cognitive problems here is that the XML is both a source and an output (archival) format.
For a source format that is used to generate specific outputs, tweaks are useful.
For an output format, maybe not so much.

I have the same problem with xml2rfc already in a different place.
All my source files of course use Unicode (Universität, —, „, «, all that).
Today, xml2rfc converts this to the necessary ASCII fallbacks for publication (Ari Keränen’s name being the only place where that didn’t work well, so far).
With XML as a publication format, I’ll need a XML to XML processor to do that.
(Maybe I don’t quite understand the future version of the “ASCII-only” approach here, though.)

Tony: Yes, “keeps” are a good way to express author intent, in particular if they come with a “badness” indication.  The way you seem to be suggesting I use them is as a way to represent tweaks as well.  How do I distinguish semantic (intention expressing) keeps from tweaks?

Grüße, Carsten

---

From: Nico Williams <[email-masked]>
Date: Mon, 27 Oct 2014 11:04:51 -0500

On Mon, Oct 27, 2014 at 10:26 AM, Joe Hildebrand (jhildebr)
<[email-masked]> wrote:
> On 10/27/14, 2:31 PM, "Carsten Bormann" <[email-masked]> wrote:

Perhaps.

>>Or, depending on the complexity of such a solution, we might simply do
>>something that serves all constituencies.
>
> I doubt that's possible.  As a first step, you'll need to answer Julian's
> question about what a "page" means in the face of different paper sizes,
> screen sizes/resolutions, font sizes, etc.

Not really.  All we need to define is "page break".

> We've let pagination creep back in to the output formats we're going to
> produce, which I continue to think is a technical mistake for good
> political reasons.  I agree with Julian that once the HTML is being

You're wrong, at least as to some proposals (those that involve
indicating what text is more precious than other text as far as
breaking goes).

> produced consistently, linked to consistently, and we've provided adequate
> tools for diffs and commenting, most people will start with the HTML.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 27 Oct 2014 11:06:03 -0500

On Mon, Oct 27, 2014 at 10:50 AM, Tony Hansen <[email-masked]> wrote:
> Using Word as an analogy, I've found that 99.99% of all manual page breaks
> can be avoided by judicious use there of "keep with next paragraph" and
> "keep with previous paragraph". Once set, I don't have to worry about when
> text is added and removed above the flagged text, or when different page
> sizes are used. These flags work remarkably well.
>

+1.

> In addition to that, I feel that section titles should automatically have
> this flag set, as well as figure captions, table heads and table captions.
> (There might be other places I'm not thinking of.)

+1.

Nico
--

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Mon, 27 Oct 2014 15:26:43 +0000

-- 
Joe Hildebrand

---

From: Julian Reschke <[email-masked]>
Date: Mon, 27 Oct 2014 18:28:50 +0100

> captions. (There might be other places I'm not thinking of.)

For these, no flag is needed. The vocabulary already provides the 
formatter with all the information it needs.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 27 Oct 2014 18:30:06 +0100

> With XML as a publication format, I’ll need a XML to XML processor to do that.

No, you won't, as the new format will allow non-ASCII characters in 
contact information anyway.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 27 Oct 2014 18:31:09 +0100

> Not really.  All we need to define is "page break".

A forced page break will not work, as pages will be of different sizes. 
Defining "page break" doesn't help with that.

Best regards, Julian

---

From: Nico Williams <[email-masked]>
Date: Mon, 27 Oct 2014 12:41:43 -0500

> Defining "page break" doesn't help with that.

For the nth time.  I'm not proposing a forced page break, just "don't
break around here if you can" hints -- hints that can be ignored at
the renderer's convenience.

---

From: Tony Hansen <[email-masked]>
Date: Mon, 27 Oct 2014 15:13:28 -0400

> formatter with all the information it needs.

Exactly my point for this paragraph. But the concept also needs to be 
there and well understood; expressing that concept as a flag that is 
also under user control seems like worth considering.

     Tony

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 27 Oct 2014 21:00:17 +0100

On 27 Oct 2014, at 18:30, Julian Reschke <[email-masked]> wrote:
> No, you won't, as the new format will allow non-ASCII characters in contact information anyway.

Actually, I do, because text is rarely ASCII*).
(Also, human names do turn up in other places than contact information, but that’s secondary.)

Grüße, Carsten

*) See https://svn.tools.ietf.org/svn/wg/core/draft-ietf-core-block-xx.xml for a random example.  This one doesn’t even have µW in it, a unit that happens to be of great importance in the field I’m working in.

---

From: Nico Williams <[email-masked]>
Date: Mon, 27 Oct 2014 15:53:06 -0500

On Mon, Oct 27, 2014 at 09:00:17PM +0100, Carsten Bormann wrote:
> *) See
> https://svn.tools.ietf.org/svn/wg/core/draft-ietf-core-block-xx.xml
> for a random example.  This one doesn’t even have µW in it, a unit
> that happens to be of great importance in the field I’m working in.

+1.  But this is really a different thread, and IIUC the consensus is
set for now.  We'll experiment with author contact info and we'll extend
non-ascii support to other content later.

(IMO that's a bit overly conservative.  Who can't read Unicode nowadays,
at least for common scripts (and math symbols, and...) for which there
are widely-available fonts?  It'd be more interesting to find a subset
of Unicode that is extremely likely to be supported, then permit that
for all RFC content, leaving the remainder of Unicode for author names
and contact information.)

Nico
--

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 27 Oct 2014 22:12:45 +0100

On 27 Oct 2014, at 21:53, Nico Williams <[email-masked]> wrote:
> 
> But this is really a different thread,

Of course, and I didn’t mean to (re-)start that one, although I like Heather’s clarification.

My point in this thread was that it is likely I have to convert from a source XML form to an archival XML form anyway*).  So there is nothing wrong with having things in the source that aren’t meant for wider consumption.

Grüße, Carsten

*) It seems I may also have to filter out XML comments that were used for communicating between authors...

---

From: Nico Williams <[email-masked]>
Date: Mon, 27 Oct 2014 16:24:29 -0500

> My point in this thread was that it is likely I have to convert from a source XML form to an archival XML form anyway*).  So there is nothing wrong with having things in the source that aren’t mean…

Indeed.  There's relatively little harm in metadata that is mostly
ignored.  "Don't break around here if you can" is such metadata.  Add
the vocabulary, then fail to implement if you like, or defer
implementation until it's needed.

> *) It seems I may also have to filter out XML comments that were used for communicating between authors...

Hmmm, do we need comments that get rendered as such, and comments that
by default don't get rendered but which also aren't XML comments?

Nico
--

---

From: Julian Reschke <[email-masked]>
Date: Tue, 28 Oct 2014 10:41:17 +0100

> only a single word goes on the next page, etc.

If the formatter does that, it needs to be fixed. It really has nothing 
to do with the input vocabulary.

Best regards, Julian

---

From: Tony Hansen <[email-masked]>
Date: Tue, 28 Oct 2014 10:30:37 -0400

On 10/28/14, 5:41 AM, Julian Reschke wrote:
> If the formatter does that, it needs to be fixed. It really has 
> nothing to do with the input vocabulary.

Totally agree here. This is normal orphan and widow control.

     Tony Hansen

---

From: <[email-masked]>
Date: Wed, 29 Oct 2014 20:13:36 +0000

Having implemented normal orphan and widow control in the past, I can say that having a hint allowed on items (such as sections especially) that says - please make this at least x lines long to fit on a page is very useful information.  

Jim

Sent from Windows Mail

From: Tony Hansen
Sent: ‎Tuesday‎, ‎October‎ ‎28‎, ‎2014 ‎10‎:‎30‎ ‎AM
Cc: [email-masked], [email-masked]

     Tony Hansen

---

From: Julian Reschke <[email-masked]>
Date: Thu, 30 Oct 2014 21:44:19 +0100

On 2014-10-29 21:13, [email-masked] wrote:
> Having implemented normal orphan and widow control in the past, I can
> say that having a hint allowed on items (such as sections especially)
> that says - please make this at least x lines long to fit on a page is
> very useful information.
>
> Jim

What would be the use case for varying the value of "x"?

Best regards, Julian