IETF Logo Mail Archive

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

Paul Hoffman <paul.hoffman@icann.org> Thu, 04 October 2018 19:38 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26546128D68 for <xml2rfc-dev@ietfa.amsl.com>; Thu, 4 Oct 2018 12:38:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajIKGFZd1Z6C for <xml2rfc-dev@ietfa.amsl.com>; Thu, 4 Oct 2018 12:38:07 -0700 (PDT)
Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B8341277BB for <xml2rfc-dev@ietf.org>; Thu, 4 Oct 2018 12:38:07 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 4 Oct 2018 12:38:04 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Thu, 4 Oct 2018 12:38:04 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Miek Gieben <miek@miek.nl>
CC: "xml2rfc-dev@ietf.org" <xml2rfc-dev@ietf.org>
Thread-Topic: [Ext] Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12, <br>
Thread-Index: AQHUWnk+g6//hyX+2Uq+Fuv/11Upv6UPzOyA//+t+KyAAHkJgA==
Date: Thu, 04 Oct 2018 19:38:03 +0000
Message-ID: <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org>
References: <E1g6wQ8-00057n-85@durif.tools.ietf.org> <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <B63F3A7C-AAB6-4281-BC5F-BC28E9693E43@icann.org> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <a9cbe9b1-1ee4-b60b-bb88-d07d11afa6a3@gmx.de> <20181004192423.xexbgomdqs56pkok@miek.nl>
In-Reply-To: <20181004192423.xexbgomdqs56pkok@miek.nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: multipart/signed; boundary="Apple-Mail=_A796FFBF-4B38-4DBF-BD75-FB5A24A8338F"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/QpBxa_ZPIlKywwO8KR81OshsS9g>
Subject: Re: [xml2rfc-dev] [Ext] Re: RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12, <br>
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Oct 2018 19:38:09 -0000

On Oct 4, 2018, at 12:24 PM, Miek Gieben <miek@miek.nl> wrote:
> 
> [ Quoting <julian.reschke@gmx.de> in "Re: [xml2rfc-dev] RFC 7991 issue #3..." ]
>> On 10/4/2018 7:18 PM, 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
>> 
>> + 0.5 to renaming it, if this helps us to come to a conclusion...
> 
> 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")

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

v2.23.0 | Report a Bug | By Email