Subject: Re: [xml2rfc] [rfc-i] will <vspace=n> disappear

From: "Jim Schaad" <[email-masked]>
Date: Thu, 6 Nov 2014 10:48:30 -0800

Sorry for the delay in responding, was on my old mail system.

Some of the places that it could be used for today.

Keeping a preamble or postamble with a figure, since this is no longer part
of the language.

Changing the default behavior if you have multiple sections starting in a
row which do not have text inside of them.  (Yes it is ok to break after the
first two and start the next page with the third one.)

Giving information about where to break a table at.  If you say that this
many lines of the table should be kept together, that gives a hint about
where to break a table up at.

Keeping together paragraphs that need to be kept in a single block without
page breaks (yes this could be done with a simpler - keep with the next
object.)

Jim

> -----Original Message-----
> From: Julian Reschke [mailto:[email-masked]]
> Sent: Thursday, October 30, 2014 1:44 PM
> To: [email-masked]; Tony Hansen
> Cc: [email-masked]; [email-masked]
> Subject: Re: [xml2rfc] [rfc-i] will <vspace=n> disappear
> 
> 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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 06 Nov 2014 23:14:58 +0100

> Keeping a preamble or postamble with a figure, since this is no longer part

Actually it is still part of the language, but has been deprecated. If 
it does something useful (and I confirm it does because I recently 
tested it), we might want to revisit that decision.

> first two and start the next page with the third one.)

Is the rule for this edge case always the same?

> where to break a table up at.

Another way would be to mark up groups of rows.

> page breaks (yes this could be done with a simpler - keep with the next

Use case? Do you have an example?

Best regards, Julian

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 6 Nov 2014 04:03:31 -0800

> Sent: Thursday, November 06, 2014 2:15 PM
> To: Jim Schaad; 'Tony Hansen'
> > Keeping a preamble or postamble with a figure, since this is no longer
> > part of the language.
> 
> Actually it is still part of the language, but has been deprecated. If it
does
> something useful (and I confirm it does because I recently tested it), we
might
> want to revisit that decision.

I consider deprecated items to no longer be part of the language.

> 
> > Changing the default behavior if you have multiple sections starting
> > in a row which do not have text inside of them.  (Yes it is ok to
> > break after the first two and start the next page with the third one.)
> 

This is actually a case of using it to break the rule.  The default rule
would be to always have the multiple section headers tied together into a
single unit without a page break between them.

> 
> > Giving information about where to break a table at.  If you say that
> > this many lines of the table should be kept together, that gives a
> > hint about where to break a table up at.
> 

I don't understand how you think this would work - are you talking about
using the fact you can have multiple tbody elements?  Or are you talking
about having multiple tables?  I don't know how you are suggesting to do
this in the current v3 vocabulary.

> 
> > Keeping together paragraphs that need to be kept in a single block
> > without page breaks (yes this could be done with a simpler - keep with
> > the next
> > object.)
> 

<t  keep-lines=5><em>NOTE:</em>The following is a really bad idea</t>
<t>One way to approach this problem is...</t>

You want to make sure that the NOTE paragraph is always tied to the next
paragraph.  This cannot currently be done.  A page break between these
paragraphs might lead someone to do something they shouldn't.

Jim

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 6 Nov 2014 20:48:17 -0800

I thought the v3 equivalent of preamble etc. was just doing t in figure. 

Sent from mobile

> On 06 Nov 2014, at 14:14, Julian Reschke <[email-masked]> wrote:
> 
> deprecated

---

From: Julian Reschke <[email-masked]>
Date: Fri, 07 Nov 2014 06:39:53 +0100

> I consider deprecated items to no longer be part of the language.

I do.

> single unit without a page break between them.

Ok. How often does this happen in practice?

> this in the current v3 vocabulary.

No, I'm thinking about whether the vocab needs to be more expressive.

> paragraphs might lead someone to do something they shouldn't.

I disagree that breaking here would be a problem.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 07 Nov 2014 06:47:16 +0100

> I thought the v3 equivalent of preamble etc. was just doing t in figure.

Not as per 
<http://tools.ietf.org/html/draft-hoffman-xml2rfc-12#section-2.25>.

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 06 Nov 2014 23:09:44 -0800

Oh, 1.2.3:

>   o  Deprecate <preamble> and <postamble> in favor of simply using <t>.
>      This also deprecates the "align" attribute in <figure>.

Didn't check for consistency (or if this sentence has another possible
meaning than my conjecture above).

Gruesse, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Fri, 07 Nov 2014 10:57:50 +0100

> meaning than my conjecture above).

I believe the proposed new way is to add <t> *outside* <figure>.

Best regards, Julian

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 7 Nov 2014 07:49:39 -0800

> I believe the proposed new way is to add <t> *outside* <figure>.

Correct (and I'll make that clearer in the next draft). The semantic difference between "this paragraph is part of a figure" vs. "this paragraph talks about the figure" is pretty slim, and doesn't appear to be used in traditional publishing. If you are an author writing "The following shows the call flow", should you have to decide if that's a preamble or a paragraph? Should you have to worry about different formatting if it is a preamble?

--Paul Hoffman

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 7 Nov 2014 08:45:15 -0800

In the terms of traditional publishing, a figure is a Keep. Including other material in the keep means the formatter is instructed to keep it all together. 

Sent from mobile

> On 07 Nov 2014, at 07:49, Paul Hoffman <[email-masked]> wrote:
>

---

From: Nico Williams <[email-masked]>
Date: Fri, 7 Nov 2014 12:51:33 -0600

> Correct (and I'll make that clearer in the next draft). The semantic difference between "this paragraph is part of a figure" vs. "this paragraph talks about the figure" is pretty slim, and doesn't…

Image captions are de rigueur, near as I can tell.  Web pages, papers,
books -- unless I'm dreaming, they all tend to have captions for their
images.  Image captions are often generally in smaller type and with
center alignment -- aligned to the center of the image, not the center
of the surrounding text.

I would agree to losing the alignment attribute on figure captions,
but losing the caption strikes me as a very noticeable -and IMO, bad-
loss.

Even if figure captions can't be rendered in different type than the
surrounding text (e.g., in plain text formatting), knowing that some
text is a caption can help the renderer deal with page breaking (I
know, I know) and floating.  If there's no concept of a figure caption
then floating and flowing around the figure (in output formats that
could manage it) would tend to break conventional (in the
by-convention sense, rather than "common") captions.

Losing the figure preamble is fine -- that I never see.  Losing the
"postamble" and not gaining a caption with similar semantics, that I
mind.

Nico
--

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 07 Nov 2014 12:10:45 -0800

Hello Julian and all,

I'd like to understand the proposed changes to the RFC format.  Can you
or anyone point me to the relevant document(s)?

Thanks in advance,
Charlie P.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 7 Nov 2014 12:37:42 -0800

> or anyone point me to the relevant document(s)?

The discussion is happening on the rfc-interest mailing list (and sometimes leaks to here, but this list is really about the current format and tools only). There has already been a lot of discussion there, certainly much more than here.

The draft of the v3 format is at <https://tools.ietf.org/html/draft-hoffman-xml2rfc>. There are a bunch of related drafts about the output formats, and an RFC <https://tools.ietf.org/html/rfc6949>.

--Paul Hoffman

---

From: Tony Hansen <[email-masked]>
Date: Fri, 07 Nov 2014 21:46:15 -0500

> paragraphs might lead someone to do something they shouldn't.

Wouldn't this be simpler and  better formulated as:

<t  keep-with-next='true'><em>NOTE:</em>The following is a really bad idea</t>
<t>One way to approach this problem is...</t>

     Tony Hansen
     [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 08 Nov 2014 16:18:59 +1300

For the overall picture, https://tools.ietf.org/html/draft-flanagan-rfc-framework
is a good starting point IMHO. It points to all the other relevant drafts.

    Brian

On 08/11/2014 09:37, Paul Hoffman wrote:
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml2rfc
>