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

["HANSEN, TONY L" <[e-mail]>]

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" <[e-mail] on behalf of [e-mail]> wrote:

    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...
    
    On 10/4/18 10:56 AM, Henrik Levkowetz wrote:
    > On 2018-10-04 19:18, Robert Sparks wrote:
    >> 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:
    >>> 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.
    >
    > 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.
    
    
    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
    
    
    _______________________________________________
    xml2rfc-dev mailing list
    [e-mail]
    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=