Subject: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12, <br>

From: [email-masked]
Date: Mon, 01 Oct 2018 04:31:24 -0700

This captures an issue noted during implementation, also described in
https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation#section-3.1.2

Specification: https://tools.ietf.org/html/rfc7991#section-2.12

---
In Section 2.12, <br>

   A number of elements permits a mixed content model (see Section "Mixed
   Content Model"): <li>, <blockquote>, <dd>, <td>, and <th>.  However,
   when using the simpler of the two content schemas, two of them (<td> and
   <th>) permit inline line breaks through the use of <br> elements; the
   others do not.  This seems terribly arbitrary.

   Recommendation:  Remove the <br> element completely.  Alternatively,
                    permit it to be used all places that 'text' and non-
                    block elements may be used (that is, in inline
                    context).

   Implementation:  The current version of xml2rfc renders <br> as a
                    newline in all inline contexts.
---

Regards,
	Henrik

-- 
This issue is tracked at:
   https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/37

Discussion should take place on this list.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 1 Oct 2018 14:07:55 +0200

>                      newline in all inline contexts.

As far as I recall, we ended up with the limited use of <br> because 
forcing a line break inside a table cell sometimes really is needed, 
while otherwise it's not. I agree consistency is nice, but this may be a 
case where the current approach is the right one.

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 1 Oct 2018 14:37:52 +0200

Hi Julian,

> case where the current approach is the right one.

Experience with the use of the v3 specification is of course very limited
at present, but my awareness of the issue was triggered by attempts to use
<br> by Miek, when he started adapting his pandoc2rfc tool to use the v3
vocabulary.

I would say that even if <br> in running text would rarely be needed, the
confusion Miek ran into is unnecessary, and limiting <br> to use within
table cells, as opposed to removing it altogether or permitting it inline
everywhere is more complex for both authors and formatters to keep track
of and handle.

Hence my proposal.

Best regards,

	Henrik

---

From: Julian Reschke <[email-masked]>
Date: Mon, 1 Oct 2018 15:04:38 +0200

On 10/1/2018 2:37 PM, Henrik Levkowetz wrote:
> ...

Yes, that's the consistency argument. The other side of the argument is 
that we don't want people to control line breaks in floating text (at 
least that's my recollection), but we did agree that it's a necessary 
feature inside table cells.

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 1 Oct 2018 21:53:23 +0200

Hi Miek,

On 2018-10-01 19:11, Miek Gieben wrote:
> Are we still expecting humans to write this XML directly? I ask because the
> number of one-offs is already staggering (esp. with attribute naming and
> the number of them).
> 
> I would hope to see some simplification of the spec, which I this case
> means allowing br in more places or disallowing the element entirely.

The more I think about this, the more I realise it is a very very good
point, and could also be a very important point.

In draft-levkowetz-xml2rfc-v3-implementation-notes, I notice that of the
16 RFC 7991 schema-related issues, 7 address schema irregularities or
inconsistencies of one kind or another.  In order to make this easier on
both people who manually write draft XML, and on tool creators who generate
draft XML from other sources, I think we should make it an explicit goal of
the next revision to simplify and regularize the vocabulary.

Best regards,

	Henrik

> On Mon, 1 Oct 2018, 12:44 Julian Reschke, <[email-masked]> wrote:
> 
>> forcing a line break inside a table cell sometimes really is needed, while
>> otherwise it's not. I agree consistency is nice, but this may be a case
>> where the current approach is the right one.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 1 Oct 2018 20:36:24 +0000

On 2018-10-01 19:11, Miek Gieben wrote:
> Are we still expecting humans to write this XML directly?

Yes. We also expect them to validate it before turning in a draft in XML format.

> I ask because the

Yes. That comes with using any markup language for rich documents. We struggled with this during the development of the v3 spec.

> means allowing br in more places or disallowing the element entirely.

See Julian's response in the thread above. The WG decided that it didn't like <br> because it causes the author to expect things that might not be true in all renderers, such as in the middle of section headings, as a run of <br><br>, and so on. However, there were many use cases for line breaks within a cell in a table because of the limitations on the horizontal space in cells.

> the next revision to simplify and regularize the vocabulary.

In this case, doing so would require us to remove <br> everywhere, I believe, because otherwise the output will surprise some and piss off others.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Oct 2018 17:56:27 +0000

I just thought of something different that might deal with Miek's issue: change the name of the element to <tbr>. That will prevent people who "know" what <br> "means" from expecting it to work because <br> doesn't exist.

If, later, we want to add <br> for running text (with lots of description of what it will and will not do to displayed RFCs), we can do so then.

--Paul Hoffman

---

From: Miek Gieben <[email-masked]>
Date: Tue, 2 Oct 2018 19:03:04 +0100

[ Quoting <[email-masked]> in "Re: [xml2rfc-dev] RFC 7991 issue #3..." ]
>If, later, we want to add <br> for running text (with lots of description of what it will and will not do to displayed RFCs), we can do so then.

What's the problem for just allowing it ~everywhere (ala HTML); and go by the motto: garbage in; garbage out?

I wonder who can honestly say that they can write 7991 XML *without* having the 
spec next to them.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Oct 2018 18:10:33 +0000

> What's the problem for just allowing it ~everywhere (ala HTML); and go by the motto: garbage in; garbage out?

See previous answers. We don't want "garbage in", these are long-lived documents. We want documents that are well-structured and well-searchable and so on.

> I wonder who can honestly say that they can write 7991 XML *without* having the spec next to them.

Most likely not. Nor could they do that with the current v2 format if they did anything more than paragraphs and sections.

--Paul Hoffman

---

From: Jim Schaad <[email-masked]>
Date: Tue, 2 Oct 2018 20:12:16 -0700

> -----Original Message-----
> From: xml2rfc-dev <[email-masked]> On Behalf Of Paul
> Hoffman
> Sent: Tuesday, October 2, 2018 11:11 AM
> To: Miek Gieben <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In
> Section 2.12, <br>
> 
> >> I just thought of something different that might deal with Miek's
issue:
> change the name of the element to <tbr>. That will prevent people who
"know"
> what <br> "means" from expecting it to work because <br> doesn't exist.
> >>
> >> If, later, we want to add <br> for running text (with lots of
description of
> what it will and will not do to displayed RFCs), we can do so then.
> >
> > What's the problem for just allowing it ~everywhere (ala HTML); and go
by
> the motto: garbage in; garbage out?
> 
> See previous answers. We don't want "garbage in", these are long-lived
> documents. We want documents that are well-structured and well-searchable
> and so on.
> 

The main reason that I know of for doing a <br> is to break paragraphs in a
list item.  This is no longer necessary as you can now have more than one
<t> as a child of an item which was not previously possible.   I think this
should be left as is.

Well, I can honestly say that I can currently write about 90% of the v2
grammar without needing to consult a specification for it.  I will admit
that I do use a template as a starting point, but I would assume that would
be normal case for writing v3 documents from scratch as well.   There are
probably some corner cases that might be done better, but that is going to
be true no matter what I use to write documents in.  I find it harder to
remember all of the ways to use markdown than I ever did to write XML.

Jim

> 
> Most likely not. Nor could they do that with the current v2 format if they
did
> anything more than paragraphs and sections.
> 
> --Paul Hoffman

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 3 Oct 2018 11:25:22 +0200

Hi Paul,

On 2018-10-01 22:36, Paul Hoffman wrote:
>> I ask because the number of one-offs is already staggering (esp.
>> with attribute naming and the number of them).
> 
> Yes. That comes with using any markup language for rich documents. We
> struggled with this during the development of the v3 spec.
> 
>> I would hope to see some simplification of the spec, which I this
>> case means allowing br in more places or disallowing the element
>> entirely.
> 
> See Julian's response in the thread above. The WG decided

Umm?  Which WG? Could you point at the discussion?

> that it
> didn't like <br> because it causes the author to expect things that
> might not be true in all renderers, such as in the middle of section
> headings, as a run of <br><br>, and so on. However, there were many
> use cases for line breaks within a cell in a table because of the
> limitations on the horizontal space in cells.

I don't see this.  I think that if there are considerations which makes
<br> useful in for instance a 30-character width context which don't
apply in a 69-character width context or a flowing-text context on a
narrow screen, they need to be laid out explicitly.

Regards,

	Henrik

>> The more I think about this, the more I realise it is a very very
>> good point, and could also be a very important point.
>> 
>> In draft-levkowetz-xml2rfc-v3-implementation-notes, I notice that
>> of the 16 RFC 7991 schema-related issues, 7 address schema
>> irregularities or inconsistencies of one kind or another.  In order
>> to make this easier on both people who manually write draft XML,
>> and on tool creators who generate draft XML from other sources, I
>> think we should make it an explicit goal of the next revision to
>> simplify and regularize the vocabulary.
> 
> In this case, doing so would require us to remove <br> everywhere, I
> believe, because otherwise the output will surprise some and piss off
> others.
> 
> --Paul Hoffman
> 
> 
> 
> _______________________________________________ xml2rfc-dev mailing
> list [email-masked] 
> https://www.ietf.org/mailman/listinfo/xml2rfc-dev
>

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 3 Oct 2018 11:29:41 +0200

Hi Paul,

On 2018-10-02 20:10, Paul Hoffman wrote:
>>> issue: change the name of the element to <tbr>. That will prevent
>>> people who "know" what <br> "means" from expecting it to work
>>> because <br> doesn't exist.
>>> 
>>> description of what it will and will not do to displayed RFCs),
>>> we can do so then.
>> 
>> What's the problem for just allowing it ~everywhere (ala HTML); and
>> go by the motto: garbage in; garbage out?
> 
> See previous answers. We don't want "garbage in", these are
> long-lived documents. We want documents that are well-structured and
> well-searchable and so on.

I would say that a wish for that is a good reason to make that easy to
accomplish, which seems to me like an argument for more consistency.

> Most likely not. Nor could they do that with the current v2 format if
> they did anything more than paragraphs and sections.

Maybe so, but that's not an argument against aiming for a more consistent
and cleaner specification.  That's just another way of saying that it was
bad before, so we're not going to attempt to make it better now.

Regards,

	Henrik

---

From: Julian Reschke <[email-masked]>
Date: Wed, 3 Oct 2018 13:38:36 +0200

> Umm?  Which WG? Could you point at the discussion?

"Design Team".

> narrow screen, they need to be laid out explicitly.

How did you arrive at 30?

Table cells can get very narrow, like just a few characters, and in that 
case it can be desirable to control line breaks.

FWIW, HTML5 *allows* <br> in many places, but says clearly that it's 
only to be used when the line break has semantic meaning, such as in a poem.

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 3 Oct 2018 13:49:05 +0200

Hi Julian,

>> Umm?  Which WG? Could you point at the discussion?

Ah.  That changes the weight of the argument a bit, though.

I think we're here now to revisit the choices made then, in the light
of experience with implementation and (even better, although not something
we could have counted on) some experience with using the v3 vocabulary,
provided by Miek.

> How did you arrive at 30?

That's an arbitrary choice.  Insert your choice of width, and remember
that when rendering body text to html on a small device, the case could
be similar to the case for a table cell.

> case it can be desirable to control line breaks.

No, it doesn't help the argument that you repeat the statement.

I seriously want to be shown examples where <br> makes sense in a cell
and not in body text.

> only to be used when the line break has semantic meaning, such as in a poem.

But doesn't that approach make more sense that the current limitation?

Please note that my suggestion was to either remove <br> altogether, or
permit it in inline context consistently.  I don't care that much about
which choice we make, but I still haven't seen any concrete example that
shows why it makes sense to disallow it in one context, and not the other.

Best regards :-)

	Henrik

---

From: Julian Reschke <[email-masked]>
Date: Wed, 3 Oct 2018 13:58:43 +0200

> be similar to the case for a table cell.

While that is true for narrow screens (smart phone), it's not really a 
good argument in this context: you don't want to have an *enforced* line 
break - it would affect "regular" rendering as well.

> I seriously want to be shown examples where <br> makes sense in a cell

<https://greenbytes.de/tech/webdav/rfc2629xslt/v3test.xml#n-rfc-7541> is 
an example copied from a real table in an RFC (which back then used 
<artwork> though).

> But doesn't that approach make more sense that the current limitation?

Well, the examples given in the HTML spec do not seem to occur in RFCs 
normally (poems, line breaks in addresses, for which we have other 
notation).

> shows why it makes sense to disallow it in one context, and not the other.

My concern is that when people can't get the table output they want, 
they'll fall back to artwork, which isn't helpful. See 
<https://greenbytes.de/tech/webdav/rfc7541.html#huffman.code>.

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 3 Oct 2018 14:13:19 +0200

> an example copied from a real table in an RFC (which back then used 

Yes, I've run that through the current text processor, and I particularly
looked at it when working on table rendering.

Where is it you need <br> to make this come out right?

> normally (poems, line breaks in addresses, for which we have other 

So the conclusion would be to eliminate <br>, then ...

> <https://greenbytes.de/tech/webdav/rfc7541.html#huffman.code>.

Understood.  I still don't see the problem with permitting <br> generally --
the argument about going to artwork has some validity also for body text
if people can't get the output they want.

Best,

	Henrik

---

From: Julian Reschke <[email-masked]>
Date: Wed, 3 Oct 2018 14:19:33 +0200

> Where is it you need <br> to make this come out right?

In the titles, at least if we want to reproduce what the RFC has.

> if people can't get the output they want.

That is true, but I'm prepared to argue that if they want to enforce a 
line break in running text, they are doing something wrong.

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 3 Oct 2018 14:53:07 +0200

Hi Julian,

> In the titles, at least if we want to reproduce what the RFC has.

Thank you for that.  It provides much better understanding of the case
which prompted the introduction of <br>.

Now, the new v3 feature which cost absolutely most extra work to
implement, by far, was the addition of table rowspan capability.

If it really is imperative to break a column title in one particular
place (and I agree it may be desirable) then why can't it be handled
by using rowspan for the other header cells, and two cells for the
particular column title that needs to be broken in a controlled manner?

And second, why is this a concern in a column header, and not, for instance
in the document title?

This is the result of a too long document title today (an actual example
as rendered by the v3 text renderer):

---
Network Working Group                                       H. Levkowetz
Internet-Draft                                              Elf Tools AB
Intended status: Informational                            3 October 2018
Expires: 6 April 2019

       Implementation notes for RFC7991, "The 'xml2rfc' Version 3
                              Vocabulary"
           draft-levkowetz-xml2rfc-v3-implementation-notes-04
----

This certainly could have been made better by use of <br>.

And I'm sure that I'm not able to predict all other cases where <br> might
be useful, so if we believe it would be useful in some contexts, we should
not limit it to only one narrow context which we've discovered so far.

> line break in running text, they are doing something wrong.

But can we be so sure of that, that it's right to enforce the current
limitation?  Had you thought of the case of a document title, above?

Might there not be other cases?  Maybe it would be better to permit it,
and maybe (at least in some cases) issue a warning?

Best regards,

	Henrik

---

From: Julian Reschke <[email-masked]>
Date: Wed, 3 Oct 2018 17:08:36 +0200

> implement, by far, was the addition of table rowspan capability.

I feel your pain.

> particular column title that needs to be broken in a controlled manner?

Example, please?

>             draft-levkowetz-xml2rfc-v3-implementation-notes-04

In the past, we have worked around that by using non-breaking spaces 
where we want to keep things together. I doubt that the same approach 
would work well in narrow table cells...

> limitation?  Had you thought of the case of a document title, above?

Yes.

> and maybe (at least in some cases) issue a warning?

Or we can wait for this to become an issue.

We *could* analyze the set of RFC XML source documents for where vspace 
is currently used.

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 4 Oct 2018 01:48:28 +0200

>> particular column title that needs to be broken in a controlled manner?

Umm?  Take the table you pointed at, give each header cell rowspan="2",
except the cell(s) where you want a particular line break, and put the
first part in the first cell and the second part in the second cell.

> would work well in narrow table cells...

Why not?  There's no mathematical difference between the two cases.

>> limitation?  Had you thought of the case of a document title, above?

Ok, good.  In that case I really don't understand why <br> wasn't provided
for document titles (and section titles, too, where I've also come across
similar issues for long titles).  

> Or we can wait for this to become an issue.

No, the chance we have to get this right is now.  We have a first iteration,
and thanks for all the work that went into it, but let's now polish it
based on explicit experience, to make it even better.

> We *could* analyze the set of RFC XML source documents for where vspace 

Yes, that would provide additional meaningful data.

Best regards,

	Henrik

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Oct 2018 23:57:34 +0000

Skipping some...

> similar issues for long titles).

Because putting a <br> in running text prevents you from being able to search for the whole phrase. This was one of the explicit reasons to prevent them everywhere, and titles and section names are particularly important examples. You might search for a title of "of Generating Datagrams" but would never think of searching for "of Generating<br>Datagrams" or even .
"of Generating <br>Datagrams"

--Paul Hoffman

---

From: Jim Schaad <[email-masked]>
Date: Wed, 3 Oct 2018 19:28:05 -0700

> From: xml2rfc-dev <[email-masked]> On Behalf Of Henrik
> Levkowetz
> Sent: Wednesday, October 3, 2018 4:48 PM
> To: Julian Reschke <[email-masked]>; Paul Hoffman
> <[email-masked]>; [email-masked]
> >>>> Yes, I've run that through the current text processor, and I
> >>>> particularly looked at it when working on table rendering.
> >>>>
> >> Thank you for that.  It provides much better understanding of the
> >> case which prompted the introduction of <br>.
> >>
> except the cell(s) where you want a particular line break, and put the first part
> in the first cell and the second part in the second cell.
> 
> >> And second, why is this a concern in a column header, and not, for
> >> instance in the document title?
> >>
> >> This is the result of a too long document title today (an actual
> >> example as rendered by the v3 text renderer):
> >>
> >> ---
> >>> That is true, but I'm prepared to argue that if they want to enforce
> >>> a line break in running text, they are doing something wrong.
> >>
> Ok, good.  In that case I really don't understand why <br> wasn't provided for
> document titles (and section titles, too, where I've also come across similar
> issues for long titles).
> 
> >> Might there not be other cases?  Maybe it would be better to permit
> >> it, and maybe (at least in some cases) issue a warning?
> >
> No, the chance we have to get this right is now.  We have a first iteration, and
> thanks for all the work that went into it, but let's now polish it based on explicit
> experience, to make it even better.
> 
> > We *could* analyze the set of RFC XML source documents for where
> > vspace is currently used.
> 

I have a vague memory that Tony did look at this so it might be on the old discussion group list.

Jim

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 4 Oct 2018 06:31:53 +0200

Hi Paul,

On 2018-10-04 01:57, Paul Hoffman wrote:
> Because putting a <br> in running text prevents you from being able
> to search for the whole phrase. This was one of the explicit reasons
> to prevent them everywhere, and titles and section names are
> particularly important examples. You might search for a title of "of
> Generating Datagrams" but would never think of searching for "of
> Generating<br>Datagrams" or even . "of Generating <br>Datagrams"

I'm sorry, but I think this is incorrect.  In rendered context, whether
text/plain, text/html, or application/pdf, this would not be an issue --
the search tools would not see any <br> (in text and pdf because it
would not be part of the text; in html, because html search tools already
disregard html's <br>).

In the context of an editor, working on the xml, a phrase search is just
as likely to fail because the text has been broken across a line, and
contains multi-space indentation, which again would prevent an in-editor
phrase search.  This is a reality I live with every day ,:-)

	Henrik

---

From: Julian Reschke <[email-masked]>
Date: Thu, 4 Oct 2018 08:42:18 +0200

On 10/4/2018 1:48 AM, Henrik Levkowetz wrote:
> .. >> Example, please?

That would require the table style to have little margins and no 
horizontal lines. (the lack of table styling features is another issue).

> ... >> In the past, we have worked around that by using non-breaking spaces

Because then you'd get overflows when the cell gets narrower than the 
longest character sequence that can't be broken. This is not an issue 
for the doc title, because it has lots of room.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 4 Oct 2018 08:43:38 +0200

> phrase search.  This is a reality I live with every day ,:-)

Here I agree with Henrik.

Also, why do we allow things like <xref> etc in running text then?

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 4 Oct 2018 10:46:48 +0200

On 2018-10-04 08:42, Julian Reschke wrote:
> horizontal lines.

Of course.  I said in the first release of the text formatter that the
current added horizontal lines would go away; they were there teporarily
to aid debugging of rowspan.

> (the lack of table styling features is another issue).

Agreed.

> for the doc title, because it has lots of room.

I think that in that case, you'd be getting a break at the point you'd
want without the insertion of a <br>.  It's definitely not the case for
the example you gave earlier; that can be handled just as well with the
use of non-breaking space.

However:

  1) would you agree that the use of non-breaking space would be a
     workaround, rather than a proper solution for document and
     section titles, as well as for table cells?

  2) <br> makes it much more convenient to get the desired layout in
     cells than using rowspan and cell-splitting?

  3) <br> would be better than the use of artwork in order to write
     RFC 1605, and probably other April 1st RFCs, too?

  4) Disallowing <br> in all cases except for table cells requires
     (repeatedly, to new author after new author), explaining that an
     obvious usage of an obvious element is forbidden in so-and-so
     case?

All in all, what do we really loose by permitting <br> more generally?

I certainly believe it would make life easier for a lot of authors, and
for the people who would not have to explain again and again why a draft
author cannot use <br> in _that_ particular title or text.

Best regards,

	Henrik

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 4 Oct 2018 18:10:00 +0900

> would work well in narrow table cells...

Using non-breaking spaces means that you may have to put in lots of them.

Henrik's proposal of using rowspan is messing with semantics, so it's 
not a good idea.

What I often wish I had is something I'll tentatively call a soft break 
here. The meaning would be: If you have to break, please try to break 
here and not at some other position.

In the above example, we would put such a soft break after "RFC7991,", 
and would get
                  Implementation notes for RFC7991,
                "The 'xml2rfc' Version 3 Vocabulary"
on short lines, but just a single line if there were enough space.

Regards,   Martin.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 4 Oct 2018 12:22:35 +0200

>       section titles, as well as for table cells?

I think it is a workaround for *document* titles. I don't believe it's 
needed anywhere else. I also don't think we need something new for 
document titles - it's a solved problem.

Yes.

>       RFC 1605, and probably other April 1st RFCs, too?

If they contain poems, maybe. So far April 1st RFCs haven't been a 
design consideration.

If we *need* poems in RFCs, let's have a proper element for them.

>       obvious usage of an obvious element is forbidden in so-and-so

That explanation will be needed in any case. Just because it's allowed 
by the grammar doesn't mean the use is ok. Not having it in the grammar 
will just surface the problem earlier (otherwise likely only in AUTH48 
which is *very* late).

> author cannot use <br> in _that_ particular title or text.

The point being: when we discussed this we decided we don't want to give 
authors control over line breaking; except in this specific exception in 
table cells.

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 4 Oct 2018 15:01:42 +0200

> authors control over line breaking; except in this specific exception in 

Julian, what you're saying here makes me sad.  I read this as you saying
that since the design team made one decision, you're not going to accept
any changes even if to other people, with new experience, another decision
makes more sense.  Because this point is not speaking to any arguments
about the usefulness and consistency of <br> at ail, it is saying that
since your decision was such then, it has to be such now.

In that case, what is the meaning with having these discussions at all?

Are you open only to make changes that you felt were necessary already
before the implementation and user experience came in?

Disappointed,

	Henrik

---

From: Julian Reschke <[email-masked]>
Date: Thu, 4 Oct 2018 15:32:51 +0200

> before the implementation and user experience came in?

No - that's not what I'm saying.

I tried to explain how we got to the current spec. You also haven't 
convinced me that any of the alternatives (forbid <br> in table cells, 
or allow it in more places) makes the vocabulary better.

I don't have any more control over the process than you have, I'm just 
offering my opinion.

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 4 Oct 2018 15:56:30 +0200

Hi Julian,

> or allow it in more places) makes the vocabulary better.

That I haven't convinced you is fine.  You haven't convinced me either; I
feel it's a wart to stick <br> into one single particular place in the
schema and disallow it everywhere else.  It violates the principle of
least surprise[1], for an author.

However, that it was possible to read the paragraph above, 

  "... we decided we don't want to give authors control over line breaking ..."

as an argument in the case, is not good.  If we are going to have a reasoned
argument based on new information, then referring back to "... we decided ..."
as part of the argumentation is just going to get us stuck.

> I don't have any more control over the process than you have, I'm just 

Ack.  No worries.

	Henrik

-----

[1] https://en.wikipedia.org/wiki/Principle_of_least_astonishment

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 Oct 2018 14:25:19 +0000

> phrase search.  This is a reality I live with every day ,:-)

Neither of those is what I was referring to: I was referring to searching the corpus of RFCs or Internet Drafts.

--Paul Hoffman

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 4 Oct 2018 16:34:57 +0200

> Neither of those is what I was referring to: I was referring to searching the corpus of RFCs or Internet Drafts.

Using which search tool?

	Henrik

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 Oct 2018 14:52:37 +0000

>> Neither of those is what I was referring to: I was referring to searching the corpus of RFCs or Internet Drafts.

grep for now, hopefully something more formal later when the corpus has more XML.

--Paul Hoffman

---

From: Julian Reschke <[email-masked]>
Date: Thu, 4 Oct 2018 17:06:50 +0200

> grep for now, hopefully something more formal later when the corpus has more XML.

That doesn't make sense.

Using grep to search in markup files doesn't work reliably -- <br> 
wouldn't make things any more worse than they are already.

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 4 Oct 2018 17:25:50 +0200

> grep for now, hopefully something more formal later when the corpus has more XML.

In that case, if you want to do phrase searches, you'll still have to deal
with these elements embedded in the phrase: 

  bcp14, cref, em, eref, iref, list, relref, strong, sub, sup, tt, xref

(I've excluded some deprecated elements).  Adding <br> to the set doesn't
seem to make any difference to how you have to write your grep expression,
and the same thing would go for a future custom search tool.

	Henrik

---

From: Robert Sparks <[email-masked]>
Date: Thu, 4 Oct 2018 12:18:27 -0500

I didn't see a response to this.

If we decide that preserving the "only in tables" idea, this avoids the 
argument about causing authors unnecessary confusion.

If it's clearly a bad idea, please capture why on the list for later.

RjS

On 10/2/18 12:56 PM, Paul Hoffman wrote:
> _______________________________________________
> xml2rfc-dev mailing list
> [email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Thu, 4 Oct 2018 19:32:17 +0200

> If it's clearly a bad idea, please capture why on the list for later.

+ 0.5 to renaming it, if this helps us to come to a conclusion...

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 4 Oct 2018 19:56:48 +0200

On 2018-10-04 19:18, Robert Sparks wrote:
>> description of what it will and will not do to displayed RFCs), we
>> can do so then.

So, Miek's original issue, as communicated to me, as I understood it,
found reasonable, and tried to capture in #37, was that <br> was generally
unavailable, but the functionality existed specifically within table cells.

Miek has also raised a related issue, #41, about not having so many special
cases in the schema.

Finally, <br> is a known tool for authors acquainted with HTML, if they
have a situation where default layout doesn't do the right thing.

So renaming <br> to <tbr> will deal with the expectation of <br> being
generally useful, since it's not called <br> any more.  It will probably
leave some authors without remedy for the case of controlling table
column title breaks, as they won't think to look for <tbr> if <br> doesn't
work.

The renaming will not do anything for issue #41, and it will also do nothing
to address the need for a straightforward capability like <br> in other
contexts.

So I don't see this a clean solution, and the parts it solves also introduces
new drawbacks.

I tried to capture what I felt was the essence of the problem in my proposed
resolution, of either permitting <br> widely, or removing it.  I still don't
care much either way, but <tbr> seems to provide neither the cleanness of
removing <br> it completely, or permitting it more generally.

	Henrik

---

From: Miek Gieben <[email-masked]>
Date: Thu, 4 Oct 2018 20:24:23 +0100

[ Quoting <[email-masked]> in "Re: [xml2rfc-dev] RFC 7991 issue #3..." ]
>>If we decide that preserving the "only in tables" idea, this avoids 
>>the argument about causing authors unnecessary confusion.
>>

Henrik is better w/ words than I am, and he put forth my thoughts well.

How about: just allowing <br>, but the renderer decides what to do with it?
(Or is that an even worse solution wrt to "least surprise")

/Miek

--
Miek Gieben

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 Oct 2018 19:38:03 +0000

On Oct 4, 2018, at 12:24 PM, Miek Gieben <[email-masked]> wrote:
>>> If we decide that preserving the "only in tables" idea, this avoids the argument about causing authors unnecessary confusion.
>>> 

My personal feeling that "renderer decides what to do with it" is worse, particularly in this case. In particular, at least in the past, different web browsers did different things with "<br><br>", and I shudder to think how this should affect the plain-text output.

One of the design goals for v3 was to get rid of markup that had no semantic meaning to the documents. We mostly succeeded at that, but clearly failed to clean up some of it (such as by allowing <br> in table cells). I still think this is a good goal, and if we want to be consistent, we should just rid of <br>.

--Paul Hoffman

---

From: Miek Gieben <[email-masked]>
Date: Thu, 4 Oct 2018 20:39:39 +0100

[ Quoting <[email-masked]> in "Re: [Ext] Re: [xml2rfc-dev] RFC 799..." ]
>One of the design goals for v3 was to get rid of markup that had no semantic meaning to the documents. We mostly succeeded at that, but clearly failed to clean up some of it (such as by allowing <br…

If that's technically possible: +1 for removing <br> entirely

/Miek

--
Miek Gieben

---

From: Julian Reschke <[email-masked]>
Date: Thu, 4 Oct 2018 23:33:03 +0200

On 2018-10-04 21:39, Miek Gieben wrote:
>> One of the design goals for v3 was to get rid of markup that had no 
>> semantic meaning to the documents. We mostly succeeded at that, but 
>> clearly failed to clean up some of it (such as by allowing <br> in 
>> table cells). I still think this is a good goal, and if we want to be 
>> consistent, we should just rid of <br>.
> 

Misleading.

HTML can focus on semantic markup, because it has a sister technology to 
deal with presentation (CSS). We don't have that, so we need to consider 
common cases where a default presentation just isn't good enough.

I'm very surprised that people have no problem adding an attribute for 
hanging list presentation but then at the same time object to enforced 
line breaks in table cells.

Best regards, Julian

---

From: Miek Gieben <[email-masked]>
Date: Thu, 4 Oct 2018 22:53:31 +0100

[ Quoting <[email-masked]> in "Re: [xml2rfc-dev] [Ext] Re: RFC 799..." ]
>HTML can focus on semantic markup, because it has a sister technology 
>to deal with presentation (CSS). We don't have that, so we need to 
>consider common cases where a default presentation just isn't good 
>enough.
>

Well... I don't who "people" are here, but with my current markdown to xml 
translator I don't see why there is *any* need to allow someone to fiddle with 
the defaults of a hanging list (or definition list).

To me, a large sticking point is that the current spec is pretty pendantic in 
what it allows (by virtue of the schema), but then there are these hidden 
(attributes) fields that *do* allow an author to fiddle with the output.

/Miek

--
Miek Gieben

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 4 Oct 2018 23:54:44 +0200

Hi Julian,

> line breaks in table cells.

For me, it's not that.  It is adding <br> for that case, and not for
others where it would be just as useful.  It's the inconsistency.

Best regards,

	Henrik

---

From: Julian Reschke <[email-masked]>
Date: Fri, 5 Oct 2018 06:35:10 +0200

On 2018-10-04 23:53, Miek Gieben wrote:
> ...
> To me, a large sticking point is that the current spec is pretty 
> pendantic in what it allows (by virtue of the schema), but then there 
> are these hidden (attributes) fields that *do* allow an author to fiddle 
> with the output.
> ...

"hidden"?

---

From: Heather Flanagan <[email-masked]>
Date: Fri, 5 Oct 2018 16:13:30 -0700

Hola a todos!

Apologies for letting this thread get a bit out of hand. Airplanes and 
small, on-site meetings are not conducive to handling active threads.

This isn't an IETF WG, but we're going to work along those models for 
sake of clarity. Consider me the WG chair for the purpose of consensus 
calls and breaking deadlock decisions.

My comments and decision on what to do with <br> below...

> removing <br> it completely, or permitting it more generally.

The design team had a goal of requiring semantic meaning for all tags 
(we didn't quite get there, but it was a design goal) and getting the 
author out of the business of fiddling with the rendering. The team was 
probably a bit too focused on the latter, and didn't take into account 
some of the use cases that have been discussed on that thread. Still, it 
is an important consideration since it impacts the time the editors have 
to spend on layout as opposed to content (granted, these aren't always 
mutually exclusive).

So, all that said, I'm particularly concerned about the ambiguity that 
<br> is introducing here, making tooling that much more complicated. 
After reading all the arguments, I'm going to say we remove <br> 
entirely from the XML v3 spec. It's not adding enough value to support 
the confusion it's causing.

Thank you all for a well-rounded discussion of the issues!

Heather

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 6 Oct 2018 15:04:29 +0200

Hi Heather,

> calls and breaking deadlock decisions.

Thank you.  Much appreciated :-)  And good to have a decision on issue #37.

Will you be summarizing where we stand on the other issues that have been
posted to the list last week?  I expect to post a new batch of 5 on Monday.

Best regards,

	Henrik

---

From: Heather Flanagan <[email-masked]>
Date: Sat, 6 Oct 2018 08:03:20 -0700

> posted to the list last week?  I expect to post a new batch of 5 on Monday.

Decisions are definitely good things! And I'm looking forward to the 
next batch - we are all working out some kinks on how we discuss these 
items, but that's not terribly surprising, and it will improve as we 
move ahead. That said, my current plan is to step in only where 
consensus is not clear. For issues like 34, 35, 36, and 39, the 
consensus seems straightforward. Any reason not to stay with that plan? 
If an issue is closed prematurely because of a misread on consensus, 
definitely make sure I'm aware (in case I miss it myself).

-Heather

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 6 Oct 2018 18:32:50 +0200

Bringing this issue to the list.  The issue was raised by Miek:
https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/31

This issue starts out by stating one problem, namely that <table>
has no provisions for having a caption.  The discussion subsequently
sorts this out, pointing to the use of the <name> element for a table
in order to provide the caption.

In order to make this clearer, Section 2.54 probably should mention
the usage of <name> to provide a caption, and section 2.32 should
include 'table' in the initial list of places it can be used (not only
texttable).  Section 1.3.3, bullet 7 could also mention the use of
<name> to provide a caption.

The discussion subsequently mentions the discrepancy between table and
figure permitting <name>, while <artwork> doesn't.  To clarify this,
it might be good to point out in Section 2.5. <artwork> that there is
no separate numbering space for artwork; in order to caption and number
a piece of artwork it has to be wrapped in a <figure> so that it can
get a Figure number.

Finally the discussion moves on to the alignment of table captions.

There are 2 issues here:

 - one schema issue, which is whether to permit left/center/right
   alignment of tables.  It is permitted for artwork, and was permitted
   for texttable, but it not permitted for <table>.

 - The alignment of the table caption.  This is not covered in the
   specification, but xml2rfc 2.10.2 centers the caption, while the
   table (lacking any alignment specification) is left-aligned.  For
   narrow tables, this mis-alignment of caption and table does not look
   good.  The next release of xml2rfc will center the caption under the
   table, before placing the combined table and caption.

To sum up:  I think there are some improvements that could be made to
the document text, to clarify the use of <name> to provide <table>
captions.  There is one unresolved schema issue (align keyword for
<table>) and one layout issue which will be fixed in the next xml2rfc
release.

Best regards,

	Henrik

---

From: Jim Schaad <[email-masked]>
Date: Sat, 6 Oct 2018 10:10:09 -0700

> Sent: Saturday, October 6, 2018 9:33 AM
> To: XML Developer List <[email-masked]>
> Subject: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, In Section
> 2.54, <table>
> 
> This issue starts out by stating one problem, namely that <table> has no
> provisions for having a caption.  The discussion subsequently sorts this out,
> pointing to the use of the <name> element for a table in order to provide the
> caption.
> 
> In order to make this clearer, Section 2.54 probably should mention the usage
> of <name> to provide a caption, and section 2.32 should include 'table' in the
> initial list of places it can be used (not only texttable).  Section 1.3.3, bullet 7
> could also mention the use of <name> to provide a caption.
> 
> The discussion subsequently mentions the discrepancy between table and figure
> permitting <name>, while <artwork> doesn't.  To clarify this, it might be good
> to point out in Section 2.5. <artwork> that there is no separate numbering
> space for artwork; in order to caption and number a piece of artwork it has to
> be wrapped in a <figure> so that it can get a Figure number.
> 

This is going to violate the least surprise rule.  Since v2 centers tables by default, I think that should be the case in v3 as well.  The question then becomes what are the advantages/disadvantages of allowing for left and right aligned tables. 

>    table, before placing the combined table and caption.

What is the rule you have for doing the alignment of figure captions?  I think that the same rules should apply to both figures and tables.

> 
> To sum up:  I think there are some improvements that could be made to the
> document text, to clarify the use of <name> to provide <table> captions.  There
> is one unresolved schema issue (align keyword for
> <table>) and one layout issue which will be fixed in the next xml2rfc release.

+1 on adding the align to the table, but the default needs to be center.  If we allow it for figures then it should also be allowed for tables.

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 6 Oct 2018 19:39:14 +0200

On 2018-10-06 19:10, Jim Schaad wrote:
> This is going to violate the least surprise rule. Since v2 centers
> tables by default, I think that should be the case in v3 as well.

I fully agree.  Not making it so is a mistake from my side.  Will fix in
the next release.

> The
> question then becomes what are the advantages/disadvantages of
> allowing for left and right aligned tables.

Right.  (And also the issue of permitting it in the past, but not now.)

> What is the rule you have for doing the alignment of figure captions?
> I think that the same rules should apply to both figures and tables.

Till now, both have been centered.  That can be changed.

> +1 on adding the align to the table, but the default needs to be
> center. If we allow it for figures then it should also be allowed for
> tables.

Makes sense to me.

	Henrik

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 6 Oct 2018 20:15:22 +0200

On Oct 6, 2018, at 18:32, Henrik Levkowetz <[email-masked]> wrote:
> <table>

In document vocabularies, it generally has turned out to be not so bright to use attributes to store text to be rendered, as sooner or later you will want this text to have more structure (which attributes can’t).

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Sat, 6 Oct 2018 12:26:47 -0700

> From: Henrik Levkowetz <[email-masked]>
> Sent: Saturday, October 6, 2018 10:39 AM
> To: Jim Schaad <[email-masked]>; 'XML Developer List' <xml2rfc-
> [email-masked]>
> Subject: Re: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, In
> Section 2.54, <table>
> 
> >> Subject: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, In
> >> Section 2.54, <table>
> >>
> >> This issue starts out by stating one problem, namely that <table> has
> >> no provisions for having a caption.  The discussion subsequently
> >> include 'table' in the initial list of places it can be used (not
> >> only texttable).  Section 1.3.3, bullet 7 could also mention the use of <name>
> to provide a caption.
> >>
> >> The discussion subsequently mentions the discrepancy between table
> >> and figure permitting <name>, while <artwork> doesn't.  To clarify
> >> this, it might be good to point out in Section 2.5. <artwork> that
> >> there is no separate numbering space for artwork; in order to caption
> >> and number a piece of artwork it has to be wrapped in a <figure> so that it
> can get a Figure number.
> >>
> I fully agree.  Not making it so is a mistake from my side.  Will fix in the next
> release.
> 
> > The

No, I would not change this.  I would keep the centering for the caption.  The next interesting question the caption is wider than the table should it be wrapped to the table width or run on past the edge of the table.  I don't think that I have a preference

Jim

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 6 Oct 2018 23:53:29 +0200

On 2018-10-06 21:26, Jim Schaad wrote:
>>> What is the rule you have for doing the alignment of figure
>>> captions? I think that the same rules should apply to both
>>> figures and tables.
> No, I would not change this.  I would keep the centering for the
> caption.  The next interesting question the caption is wider than the
> table should it be wrapped to the table width or run on past the edge
> of the table.  I don't think that I have a preference

I don't (at least currently) have a strong preference.  The current
code wraps the title to fit within the table width.

Best regards,

	Henrik

---

From: Heather Flanagan <[email-masked]>
Date: Tue, 9 Oct 2018 11:00:42 -0700

> code wraps the title to fit within the table width.

I'm not entirely sure how this issue differs from the table alignment 
discussed in issues 40 and 9?

-Heather

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 9 Oct 2018 20:20:07 +0200

Hi Heather,

> discussed in issues 40 and 9?

In the previous release of xml2rfc, the table caption, e.g., "Table 1: Foo"
underneath the table, was always centered on the page in text format,
while the table was left-aligned (the left-alignment was an error, though,
a leftover from the artwork alignment).  That is, the table and caption
was rendered and aligned individually.

As a result of the discussion above, and the table alignment issue, the
latest release does the following:

 1) render the table as a block
 2) render the caption, with wrapping, with the same max width as the table
 3) center the caption under the table, as a new composite block
 4) align the block of table + caption left, center, or right on the page.

The discussion above concerned steps 2 and 3 above, while issues 40 and 9
concerned 4.

Best regards,

	Henrik

---

From: Jim Schaad <[email-masked]>
Date: Tue, 9 Oct 2018 11:22:03 -0700

> From: xml2rfc-dev <[email-masked]> On Behalf Of Heather
> Flanagan
> Sent: Tuesday, October 9, 2018 11:01 AM
> To: [email-masked]
> >>>> captions? I think that the same rules should apply to both figures
> >>>> and tables.
discussed
> in issues 40 and 9?

The first was where do you place the table on the page.  This one is how do
you place the caption in the table.

Jim

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 9 Oct 2018 20:26:58 +0200

> you place the caption in the table.

Much more succinct than my reply :-)

	Henrik

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 20 Oct 2018 01:33:05 +0000

Sorry to reopen, but I'm not clear on the result. We have consensus on something, but I'm not clear how to implement it.

> Much more succinct than my reply :-)

Is the result to simply add text that says "the caption will appear centered", or is the result to add a new attribute such as "alignCaption" with the default being "center".

If the latter, should this same new attribute be added to <figure> as well?

--Paul

---

From: Jim Schaad <[email-masked]>
Date: Fri, 19 Oct 2018 20:50:01 -0700

> From: Paul Hoffman <[email-masked]>
> Sent: Friday, October 19, 2018 6:33 PM
> To: Henrik Levkowetz <[email-masked]>
> Cc: Jim Schaad <[email-masked]>; Heather Flanagan <rse@rfc-
> editor.org>; [email-masked]
> Subject: Re: [Ext] [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC
7991, In
> Section 2.54, <table>
> 
> Sorry to reopen, but I'm not clear on the result. We have consensus on
> something, but I'm not clear how to implement it.
> 
> 
> Is the result to simply add text that says "the caption will appear
centered", or
> is the result to add a new attribute such as "alignCaption" with the
default
> being "center".

I think that this is just text and no new attributes.  "The caption will
appear centered and the same width as the table."

Jim

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 20 Oct 2018 05:51:56 +0200

> centered", or is the result to add a new attribute such as
> "alignCaption" with the default being "center".

The caption will be centred under the table, and the combined table and
caption will be aligned according to the 'align' attribute on <table>.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 20 Oct 2018 05:54:03 +0200

Hi Jim,

> appear centered and the same width as the table."

That's the way I've implemented it, but I have a reservation for the case
when the table is very narrow.  I'd prefer to leave the tool writer some
wriggle room for that case, and not prescribe that the caption must be the
same width as the table.

Best regards,

	Henrik

---

From: Jim Schaad <[email-masked]>
Date: Fri, 19 Oct 2018 21:13:34 -0700

> Sent: Friday, October 19, 2018 8:54 PM
> To: Jim Schaad <[email-masked]>; 'Paul Hoffman'
> <[email-masked]>
> Cc: 'Heather Flanagan' <[email-masked]>; [email-masked]
> Subject: Re: [Ext] [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, In
> Section 2.54, <table>
> 
> Hi Jim,
> 
> >> Sorry to reopen, but I'm not clear on the result. We have consensus
> >> on something, but I'm not clear how to implement it.
> >>
> >>
> >> >>> From: xml2rfc-dev <[email-masked]> On Behalf Of
> >> >>> Heather Flanagan
> >> >>> Subject: Re: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC
> >> >>> 7991,
> > In
> >> >>> Section 2.54, <table>
> >> >>>
> >> >>>
> >> >>>>> No, I would not change this.  I would keep the centering for
> >> >>>>> the caption.  The next interesting question the caption is
> >> >>>>> wider than
> > the
> >> >>>>> table should it be wrapped to the table width or run on past
> >> >>>>> the
> > edge
> >> >>>> I don't (at least currently) have a strong preference.  The
> >> >>>> current code wraps the title to fit within the table width.
> >> >>>>
> >> >>>
> >> >> The first was where do you place the table on the page.  This one
> >> >> is
> > how do
> > I think that this is just text and no new attributes.  "The caption
> > will appear centered and the same width as the table."
> 
> That's the way I've implemented it, but I have a reservation for the case when
> the table is very narrow.  I'd prefer to leave the tool writer some wriggle room
> for that case, and not prescribe that the caption must be the same width as the
> table.

I agree with that - every time that I have written this I have always had to think twice.

Jim

---

From: Heather Flanagan <[email-masked]>
Date: Sat, 20 Oct 2018 08:55:26 -0700

> caption will be aligned according to the 'align' attribute on <table>.

Yes, this.

-Heather

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Mon, 29 Oct 2018 00:58:03 +0000

(Trying to catch up with some of these emails.) Yes, I DID do extensive analysis of the use of <vspace/> in existing XML files, but I cannot find the emails that I sent back then.

The gist of the analysis was that the only use of <vspace/> that both 1) had considerable use and 2) couldn't be handled through other means, was within table cells. There was a move afoot at the time to remove the capability entirely, and these counterarguments are what lead to the inclusion of <br/> at least for the limited use within tables that we got. I don't think those use cases have gone away and we should not remove the ability to force a line break when it is absolutely needed. I don't really care whether that ability is spelled <vspace/>, <br/>, <tbr/> or whatever.

I'll keep looking for the emails and the results of my analysis back then.

	Tony

On 10/3/18, 10:28 PM, "xml2rfc-dev on behalf of Jim Schaad" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    Jim

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Mon, 29 Oct 2018 01:02:23 +0000

Given this, should I continue to look for my analysis that I raised during the design process that led us to conclude that <br/> functionality WAS required for certain use cases, and that there was no  clean alternative way of handling it?

	Tony

On 10/5/18, 7:13 PM, "xml2rfc-dev on behalf of Heather Flanagan" <[email-masked] on behalf of [email-masked]> wrote:

    Hola a todos!

    

    

    Heather

    _______________________________________________
    xml2rfc-dev mailing list
    [email-masked]
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_xml2rfc-2Ddev&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=Kz8VdgPVctDNSNPJ6PsBaw&m=Hn9lsPHrzvNdfoVyB0kknzkBkxuVQmnb964pWfpaVLw&s=tNB69KsbmtsAZxtwgKDPoY7tDQcLhQis-YgPBctGtSU&e=

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Mon, 29 Oct 2018 01:05:02 +0000

My druthers would have been to allow it anywhere.

	Tony

On 10/4/18, 5:55 PM, "xml2rfc-dev on behalf of Henrik Levkowetz" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Julian,

    Best regards,
    
    	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 30 Oct 2018 10:28:19 +0100

> My druthers would have been to allow it anywhere.

I agree.  Although my primary point was consistency, I've had to deal
with long document titles that would have benefited from having <br>
available.

	Henrik