From nobody Mon Oct 1 03:59:04 2018 Return-Path: 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 C4F58130E55 for ; Mon, 1 Oct 2018 03:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 8Gr5PN4YWstE for ; Mon, 1 Oct 2018 03:59:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82A49130E4B for ; Mon, 1 Oct 2018 03:59:00 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:61483 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g6vul-0000g1-TM for xml2rfc-dev@ietf.org; Mon, 01 Oct 2018 03:59:00 -0700 To: xml2rfc-dev@ietf.org From: Henrik Levkowetz Message-ID: Date: Mon, 1 Oct 2018 12:58:46 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jGuu3VIddlgeHxBNqMCesphg0PNPnBomE" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc-dev] Specification issues found during implementation of RFC7991 etc. 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 10:59:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jGuu3VIddlgeHxBNqMCesphg0PNPnBomE Content-Type: multipart/mixed; boundary="lSChDF6KcAvm7JWG1GbwS8cjl8qEgNhWa"; protected-headers="v1" From: Henrik Levkowetz To: xml2rfc-dev@ietf.org Message-ID: Subject: Specification issues found during implementation of RFC7991 etc. --lSChDF6KcAvm7JWG1GbwS8cjl8qEgNhWa Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I'm about to start posting individual issues found during implementation of the V3 specifications to the list. These have been described in draft-levkowetz-xml2rfc-v3-implementation-no= tes, which I'll continue to update, but in order to facilitate discussion of individual issues, I'll be posting them to the list one by one, in chunks= of 5. I'll also add the issues to the issue trackers on github. Some of the issues will overlap or match already registered issues, in wh= ich case we can close the new ones as duplicates, with reference to the earli= er issue. I'll still post them here and to the issue tracker, in order to trigger discussion and capture the implementation experience. Best regards, Henrik --lSChDF6KcAvm7JWG1GbwS8cjl8qEgNhWa-- --jGuu3VIddlgeHxBNqMCesphg0PNPnBomE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlux/eYACgkQTptXS4+7 Fxrz9w/9FyroTb+MLCK2x1sGI5/FzFAiXcrcNWEodDyHCiH88kuDtqboruux2Mc9 AN+q1WNl5HP5PWluG+sQxr13UvWy57o5vaPkO6LpRWTUebOUn8lpbW1/X2L8mopg AELj/GLX3TCNi7QcdWQWdA0WQimPIG+ayCFWeYbwb3vUQLhYz+ZDpyOXDLkOhJc6 38cQcxMI93lu6DmpOZ+/PGlDJDfU4B7YAyrTDtsKBXsGgbRQosSwhneJbE+evzlM vUqfR+6sl8Qs8z2vycNQbkG4xvf+jSvPXW5CvSDX0UuXUdDNE/x39kyfcRgTdI/V C5mYqIIK6mw8oZ1Z1CGChRgx35aL4vuz8R0hGv1V+R4WpwrVjMjaZVfK9TQT2zfU zCYNBYYsdLxqE9Y0InEsOCk1Sf6uQSHnwODNAUWLXzqIYc3wbenJjorstYNFE9ZO gPNK1Vp0QB/Yt1kanQGHXuReilXwzI6VdPIIQaDCnYXdWN0TofaHiypd1H4G+hpP rq2Rfl+ALuC7ATVdf14X+Ep0G9cpcHhSZT5x3BCmwN28QgtWoqzkK5BUo61BKFV6 wu02MydnlYTGjtt18f5TTOdezQSwIXSbWhSz9U7EV3l0BjwxWup0QXUQxCVZnQsc /kd2rJ1b/8nCgvFo3+08aUfNZiuXFc1+jVh8wad76TZyO6v64eE= =2SlH -----END PGP SIGNATURE----- --jGuu3VIddlgeHxBNqMCesphg0PNPnBomE-- From nobody Mon Oct 1 04:28:04 2018 Return-Path: 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 12882130E98 for ; Mon, 1 Oct 2018 04:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 6zvRB5fHF4O2 for ; Mon, 1 Oct 2018 04:27:46 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD5C4130E8E for ; Mon, 1 Oct 2018 04:27:46 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:61542 helo=tannat.localdomain) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g6wMb-0004SO-PF for xml2rfc-dev@ietf.org; Mon, 01 Oct 2018 04:27:46 -0700 From: Henrik Levkowetz To: XML Developer List Message-ID: Date: Mon, 1 Oct 2018 13:27:37 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WJURagd7wNsS6cVXsx04E9Ow2pa5c2Jv4" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on durif.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc-dev] RFC 7991 issue #21: Schema Issue, RFC 7991, In Section 2.5.5, "name" Attribute 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 11:28:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WJURagd7wNsS6cVXsx04E9Ow2pa5c2Jv4 Content-Type: multipart/mixed; boundary="bkaHECuxagmr1DC5geP3c8G3qhD80wvQK"; protected-headers="v1" From: Henrik Levkowetz To: XML Developer List Message-ID: Subject: RFC 7991 issue #21: Schema Issue, RFC 7991, In Section 2.5.5, "name" Attribute --bkaHECuxagmr1DC5geP3c8G3qhD80wvQK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This captures an issue noted during implementation, also described in https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation#sec= tion-3.1.1 Specification: https://tools.ietf.org/html/rfc7991#section-2.5.5 --- "A filename suitable for the contents (such as for extraction to a local file)." Given the existing use of "name" on , this attribute name has a semantic dissonance. Recommendation: Deprecate "name" for use on and , and instead use "file", which for will b= e explicitly rendered, as established as best current practice for YANG modules (see for instance RFC 6087 [RFC6087]) Implementation: The current version of xml2rfc uses "name". --- Regards, Henrik --=20 This issue is tracked at: https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/36 Discussion should take place on this list. --bkaHECuxagmr1DC5geP3c8G3qhD80wvQK-- --WJURagd7wNsS6cVXsx04E9Ow2pa5c2Jv4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAluyBKkACgkQTptXS4+7 FxqpzA/7BncgUDaqMp4PMNx6/Hzec6aAfzztTWueWlEf78KboaLivTX9b7fFG4gV r78PV+Oh2ZebWQAOOeP9C+0I8P2ndM76OXI+AXo0D/zRrIuMHWILeImLnfrmibcv w/+bURRNHw7Ms4fbsRp+q3HdVrOuiXOaA77ori4s7Xq2ANIRBWNyv9hG83LkoYmr 8gXf379Gjs1KxfN6PprjnW96sERy09gGoFgAo47Ir9n8WZ/vNcbDz4oMD/0CCkvC 6eK3V+ahymYjAVZJdxIUF39SAfM3Yi1u0Q7pSFHhZMtKHBAUaHJOqMvaZOolL7ud sRSrKujVyDekQBaKUukBFOKq3YlvgJh5zlkKW3SnUr/Uphe8KmfUkOVMBqLF3Bto /JTWNf2RGoGGTFfgXKEmsxq1h4pAJl9QKUlY4/cMW79neDcHOyGmVb+X2IC40wHm YFjn7Uv030aiVyZfePkF3om94NP2F6upn/nNvH5r2tefY0hc1+kDcvmaQu/3WK86 DwBEIrV9Fg8kI0OrkIBkgYQEjV9cVMRq0zJARHxNoE9dYamVjw5Rm8z7kHfQpWMi ACPPtbWbEJ7g97Jl5lq9qSB28feJAgvSpsUdSVm/wFE9XnR8C+1nc/t4D9FNWtfZ AVX1sGi1Qf6aUKxeXJph1BEiZ5agia9meb3DNItqDFgJROX6EqI= =EUkL -----END PGP SIGNATURE----- --WJURagd7wNsS6cVXsx04E9Ow2pa5c2Jv4-- From nobody Mon Oct 1 04:31:28 2018 Return-Path: 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 658A0130E5F for ; Mon, 1 Oct 2018 04:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_MANY_HDRS_LCASE=0.01, URIBL_BLOCKED=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 2FDGGTOYgCDu for ; Mon, 1 Oct 2018 04:31:24 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7378B130DEB for ; Mon, 1 Oct 2018 04:31:24 -0700 (PDT) Received: from localhost ([::1]:40259 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1g6wQ8-00057n-85 for xml2rfc-dev@ietf.org; Mon, 01 Oct 2018 04:31:24 -0700 to: xml2rfc-dev@ietf.org from: henrik@levkowetz.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Message-Id: Date: Mon, 01 Oct 2018 04:31:24 -0700 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 11:31:27 -0000 VGhpcyBjYXB0dXJlcyBhbiBpc3N1ZSBub3RlZCBkdXJpbmcgaW1wbGVtZW50YXRpb24sIGFsc28g ZGVzY3JpYmVkIGluCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sZXZrb3dldHot eG1sMnJmYy12My1pbXBsZW1lbnRhdGlvbiNzZWN0aW9uLTMuMS4yCgpTcGVjaWZpY2F0aW9uOiBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzk5MSNzZWN0aW9uLTIuMTIKCi0tLQpJbiBT ZWN0aW9uIDIuMTIsIDxicj4KCiAgIEEgbnVtYmVyIG9mIGVsZW1lbnRzIHBlcm1pdHMgYSBtaXhl ZCBjb250ZW50IG1vZGVsIChzZWUgU2VjdGlvbiAiTWl4ZWQKICAgQ29udGVudCBNb2RlbCIpOiA8 bGk+LCA8YmxvY2txdW90ZT4sIDxkZD4sIDx0ZD4sIGFuZCA8dGg+LiAgSG93ZXZlciwKICAgd2hl biB1c2luZyB0aGUgc2ltcGxlciBvZiB0aGUgdHdvIGNvbnRlbnQgc2NoZW1hcywgdHdvIG9mIHRo ZW0gKDx0ZD4gYW5kCiAgIDx0aD4pIHBlcm1pdCBpbmxpbmUgbGluZSBicmVha3MgdGhyb3VnaCB0 aGUgdXNlIG9mIDxicj4gZWxlbWVudHM7IHRoZQogICBvdGhlcnMgZG8gbm90LiAgVGhpcyBzZWVt cyB0ZXJyaWJseSBhcmJpdHJhcnkuCgogICBSZWNvbW1lbmRhdGlvbjogIFJlbW92ZSB0aGUgPGJy PiBlbGVtZW50IGNvbXBsZXRlbHkuICBBbHRlcm5hdGl2ZWx5LAogICAgICAgICAgICAgICAgICAg IHBlcm1pdCBpdCB0byBiZSB1c2VkIGFsbCBwbGFjZXMgdGhhdCAndGV4dCcgYW5kIG5vbi0KICAg ICAgICAgICAgICAgICAgICBibG9jayBlbGVtZW50cyBtYXkgYmUgdXNlZCAodGhhdCBpcywgaW4g aW5saW5lCiAgICAgICAgICAgICAgICAgICAgY29udGV4dCkuCgogICBJbXBsZW1lbnRhdGlvbjog IFRoZSBjdXJyZW50IHZlcnNpb24gb2YgeG1sMnJmYyByZW5kZXJzIDxicj4gYXMgYQogICAgICAg ICAgICAgICAgICAgIG5ld2xpbmUgaW4gYWxsIGlubGluZSBjb250ZXh0cy4KLS0tCgpSZWdhcmRz LAoJSGVucmlrCgotLSAKVGhpcyBpc3N1ZSBpcyB0cmFja2VkIGF0OgogICBodHRwczovL2dpdGh1 Yi5jb20vcmZjLWZvcm1hdC9kcmFmdC1pYWIteG1sMnJmYy12My1iaXMvaXNzdWVzLzM3CgpEaXNj dXNzaW9uIHNob3VsZCB0YWtlIHBsYWNlIG9uIHRoaXMgbGlzdC4= From nobody Mon Oct 1 04:35:50 2018 Return-Path: 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 4F8BC130DFA for ; Mon, 1 Oct 2018 04:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_MANY_HDRS_LCASE=0.01, URIBL_BLOCKED=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 vmenye_Wwi27 for ; Mon, 1 Oct 2018 04:35:47 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FADE120072 for ; Mon, 1 Oct 2018 04:35:47 -0700 (PDT) Received: from localhost ([::1]:40365 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1g6wUN-0002BH-Et for xml2rfc-dev@ietf.org; Mon, 01 Oct 2018 04:35:47 -0700 to: xml2rfc-dev@ietf.org from: henrik@levkowetz.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Message-Id: Date: Mon, 01 Oct 2018 04:35:47 -0700 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc-dev] RFC 7991 issue #38: Schema Issue, RFC 7991, In Section 2.20,
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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 11:35:50 -0000 VGhpcyBjYXB0dXJlcyBhbiBpc3N1ZSBub3RlZCBkdXJpbmcgaW1wbGVtZW50YXRpb24sIGFsc28g ZGVzY3JpYmVkIGluCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sZXZrb3dldHot eG1sMnJmYy12My1pbXBsZW1lbnRhdGlvbiNzZWN0aW9uLTMuMS4zCgpTcGVjaWZpY2F0aW9uOiBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzk5MSNzZWN0aW9uLTIuMjAKCi0tLQpJbiBT ZWN0aW9uIDIuMjAsIDxkbD4KCiAgIFRoZSBjdXJyZW50IHNwZWNpZmljYXRpb24gc2F5czoKCiAg ICAgICJUaGUgImhhbmdpbmciIGF0dHJpYnV0ZSBkZWZpbmVzIHdoZXRoZXIgb3Igbm90IHRoZSB0 ZXJtIGFwcGVhcnMgb24KICAgICAgdGhlIHNhbWUgbGluZSBhcyB0aGUgZGVmaW5pdGlvbi4gIGhh bmdpbmc9InRydWUiIGluZGljYXRlcyB0aGF0IHRoZQogICAgICB0ZXJtIGlzIHRvIHRoZSBsZWZ0 IG9mIHRoZSBkZWZpbml0aW9uLCB3aGlsZSBoYW5naW5nPSJmYWxzZSIKICAgICAgaW5kaWNhdGVz IHRoYXQgdGhlIHRlcm0gd2lsbCBiZSBvbiBhIHNlcGFyYXRlIGxpbmUuIgoKICAgVGhpcyBkb2Vz IG5vdCBtYXRjaCBlc3RhYmxpc2hlZCB0eXBvZ3JhcGhpYyB0ZXJtaW5vbG9neS4gIEluIHR5cG9n cmFwaGljCiAgIHRlcm1pbm9sb2d5LCAiaGFuZ2luZyBpbmRlbnQiIGRlc2NyaWJlcyB0aGUgY2Fz ZSB3aGVyZSB0aGUgaW5kZW50YXRpb24KICAgb2YgdGhlIHNlY29uZCBhbmQgc3Vic2VxdWVudCBs aW5lcyBvZiBhIHBhcmFncmFwaCBpcyBncmVhdGVyIHRoYW4gdGhlCiAgIGluZGVudGF0aW9uIG9m IHRoZSBmaXJzdCBsaW5lLiAgV2hldGhlciB0aGUgZGVmaW5pdGlvbiBpbiBhIGRlZmluaXRpb24K ICAgbGlzdCBzdGFydHMgb24gdGhlIGZpcnN0IGxpbmUgb3Igbm90IGhhcyBub3RoaW5nIHRvIGRv IHdpdGggdGhlIHByZXNlbmNlCiAgIG9mIGhhbmdpbmcgaW5kZW50OyBvdXIgZGVmaW5pdGlvbiBs aXN0cyB3aWxsIF9hbHdheXNfIGhhdmUgaGFuZ2luZwogICBpbmRlbnQuCgogICBUaGUgJ2hhbmdp bmcnIGF0dHJpYnV0ZSBhbHNvIGRlc2NyaWJlcyBzb21ldGhpbmcgZGlmZmVyZW50IGZyb20gd2hh dCB0aGUKICAgdGVybSBoYXMgYmVlbiB1c2VkIHRvIGRlc2NyaWJlIGluIHRoZSB2ZXJzaW9uIDIg dm9jYWJ1bGFyeS4gIFRoaXMgd2lsbAogICBiZSBjb25mdXNpbmcgdG8gdXNlcnMuCgogICBBIG1v cmUgZGVzY3JpcHRpdmUgbmFtZSBmb3IgdGhlIGF0dHJpYnV0ZSB3ZSdyZSB0YWxraW5nIGFib3V0 IHdvdWxkIGJlCiAgICdzdGFydC1kZWZpbml0aW9uLW9uLWZpcnN0LWxpbmUnLCBidXQgdGhhdCdz IHVud2llbGR5LiAgTWF5YmUKICAgJ25ld2xpbmU9ImZhbHNlIicgdG8gc3RhcnQgdGhlIGRlZmlu aXRpb24gb24gdGhlIGZpcnN0IGxpbmUsIG9yCiAgIHNvbWV0aGluZyBsaWtlICdkZWZpbml0aW9u LXN0YXJ0PSJmaXJzdCInPwoKICAgUmVjb21tZW5kYXRpb246ICBDaGFuZ2UgdGhpcyB0byBhIGRp ZmZlcmVudCB0ZXJtIHRoYXQgaXMgbW9yZQogICAgICAgICAgICAgICAgICAgIGRlc2NyaXB0aXZl IGFuZCBkb2VzIG5vdCB1c2UgdHlwb2dyYXBoaWNhbGx5IGluY29ycmVjdAogICAgICAgICAgICAg ICAgICAgIHRlcm1pbm9sb2d5LgoKICAgSW1wbGVtZW50YXRpb246ICBUaGUgY3VycmVudCB2ZXJz aW9uIG9mIHhtbDJyZmMgc3RpbGwgdXNlcyAiaGFuZ2luZyIuCi0tLQoKUmVnYXJkcywKCUhlbnJp awoKLS0tClRoaXMgaXNzdWUgaXMgdHJhY2tlZCBhdDoKICAgaHR0cHM6Ly9naXRodWIuY29tL3Jm Yy1mb3JtYXQvZHJhZnQtaWFiLXhtbDJyZmMtdjMtYmlzL2lzc3Vlcy8zOAoKRGlzY3Vzc2lvbiBz aG91bGQgdGFrZSBwbGFjZSBvbiB0aGlzIGxpc3Qu From nobody Mon Oct 1 04:36:29 2018 Return-Path: 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 52268130DFA for ; Mon, 1 Oct 2018 04:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_MANY_HDRS_LCASE=0.01, URIBL_BLOCKED=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 zPM66zJ4pD1r for ; Mon, 1 Oct 2018 04:36:25 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B6A7120072 for ; Mon, 1 Oct 2018 04:36:25 -0700 (PDT) Received: from localhost ([::1]:40376 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1g6wUz-0002Cp-91 for xml2rfc-dev@ietf.org; Mon, 01 Oct 2018 04:36:25 -0700 to: xml2rfc-dev@ietf.org from: henrik@levkowetz.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Message-Id: Date: Mon, 01 Oct 2018 04:36:25 -0700 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, New Section 2.20.4, "indent" Attribute 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 11:36:28 -0000 VGhpcyBjYXB0dXJlcyBhbiBpc3N1ZSBub3RlZCBkdXJpbmcgaW1wbGVtZW50YXRpb24sIGFsc28g ZGVzY3JpYmVkIGluCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sZXZrb3dldHot eG1sMnJmYy12My1pbXBsZW1lbnRhdGlvbiNzZWN0aW9uLTMuMS40CgotLS0KTmV3IFNlY3Rpb24g Mi4yMC40LCAiaW5kZW50IiBBdHRyaWJ1dGUKCiAgIFRoZSBkZXByZWNhdGlvbiBvZiB0aGUgImhh bmdJbmRlbnQiIGF0dHJpYnV0ZSBvbiA8bGlzdD4gbGVhdmVzIG5vCiAgIG9wcG9ydHVuaXR5IHRv IGNvbnRyb2wgdGhlIHNpemUgb2YgdGhlIGhhbmdpbmcgaW5kZW50LiAgSW4gc29tZQogICBkZWZp bml0aW9uIGxpc3RzLCBpdCBpcyBkZXNpcmFibGUgdG8gaGF2ZSBhIHdpZGUgaW5kZW50YXRpb24s IGluIG9yZGVyCiAgIHRvIGNsZWFybHkgc2hvdyB0aGUgdGVybXMsIGluIG90aGVyIGNhc2VzIGl0 IGlzIG1vcmUgaW1wb3J0YW50IHRvIGFsbG93CiAgIGZvciBhIGxhcmdlciB0ZXh0IHZvbHVtZSB0 aGFuIHRoZSB3aWR0aCBvZiB0aGUgdGVybXMgd291bGQgYWxsb3cuCgogICBSZWNvbW1lbmRhdGlv bjogIEFkZCBhbiAiaW5kZW50IiBhdHRyaWJ1dGUgb24gPGRsPiB0byBjb250cm9sIHRoZSBzaXpl CiAgICAgICAgICAgICAgICAgICAgb2YgdGhlIGhhbmdpbmcgaW5kZW50LgoKICAgSW1wbGVtZW50 YXRpb246ICBUaGUgY3VycmVudCB2ZXJzaW9uIG9mIHhtbDJyZmMgZG9lcyBub3Qgc3VwcG9ydCB0 aGUKICAgICAgICAgICAgICAgICAgICBhdHRyaWJ1dGUsIGJ1dCBoYXMgYWxsIHRoZSB1bmRlcmx5 aW5nIGZ1bmN0aW9ucyBuZWVkZWQKICAgICAgICAgICAgICAgICAgICB0byBhcHBseSBzdWNoIGFu IGF0dHJpYnV0ZS4gIEludGVybmFsbHksIGFuIGluZGVudGF0aW9uCiAgICAgICAgICAgICAgICAg ICAgaXMgY2FsY3VsYXRlZCBiYXNlZCBvbiBsZW5ndGggb2YgdGhlIDxkdD4gdGV4dCBhbmQgdGhl CiAgICAgICAgICAgICAgICAgICAgc2V0dGluZ3Mgb2Ygc29tZSBvZiB0aGUgb3RoZXIgYXR0cmli dXRlcy4KLS0tCgpSZWdhcmRzLAoJSGVucmlrCgotLS0KVGhpcyBpc3N1ZSBpcyB0cmFja2VkIGF0 OgogICBodHRwczovL2dpdGh1Yi5jb20vcmZjLWZvcm1hdC9kcmFmdC1pYWIteG1sMnJmYy12My1i aXMvaXNzdWVzLzM5CgpEaXNjdXNzaW9uIHNob3VsZCB0YWtlIHBsYWNlIG9uIHRoaXMgbGlzdC4= From nobody Mon Oct 1 04:36:49 2018 Return-Path: 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 D2678130E60 for ; Mon, 1 Oct 2018 04:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 gnc49nfUoD_7 for ; Mon, 1 Oct 2018 04:36:44 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC964120072 for ; Mon, 1 Oct 2018 04:36:44 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:61550 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g6wVH-0004pw-Ve for xml2rfc-dev@ietf.org; Mon, 01 Oct 2018 04:36:44 -0700 To: XML Developer List References: From: Henrik Levkowetz Message-ID: Date: Mon, 1 Oct 2018 13:36:36 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0QFis80IxMWVBagPQ28k0FedIwpuqSSFp" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #36: Schema Issue, RFC 7991, In Section 2.5.5, "name" Attribute 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 11:36:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0QFis80IxMWVBagPQ28k0FedIwpuqSSFp Content-Type: multipart/mixed; boundary="BvffTMGdll7UcnNe7hxCSt8D488PP924K"; protected-headers="v1" From: Henrik Levkowetz To: XML Developer List Message-ID: Subject: Re: [xml2rfc-dev] RFC 7991 issue #36: Schema Issue, RFC 7991, In Section 2.5.5, "name" Attribute References: In-Reply-To: --BvffTMGdll7UcnNe7hxCSt8D488PP924K Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Oops. Slight tooling problem. The subject line of the previous version gave the wrong issue number. (The link at the bottom of the message used= the right one). On 2018-10-01 13:27, Henrik Levkowetz wrote: This captures an issue noted during implementation, also described in https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation#sec= tion-3.1.1 Specification: https://tools.ietf.org/html/rfc7991#section-2.5.5 --- "A filename suitable for the contents (such as for extraction to a local file)." Given the existing use of "name" on , this attribute name has a semantic dissonance. Recommendation: Deprecate "name" for use on and , and instead use "file", which for will b= e explicitly rendered, as established as best current practice for YANG modules (see for instance RFC 6087 [RFC6087]) Implementation: The current version of xml2rfc uses "name". --- Regards, Henrik --=20 This issue is tracked at: https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/36 Discussion should take place on this list. --BvffTMGdll7UcnNe7hxCSt8D488PP924K-- --0QFis80IxMWVBagPQ28k0FedIwpuqSSFp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAluyBsQACgkQTptXS4+7 FxprRQ/+KsBlkewE/wHNkR4/PzuPZo8US7qMJT8IOXlNzih6H1LtmspS8vaUqYyk VdYSv0Ls6IYcvzL/nQbixvQ2U0h6MMG8M3SOjTYp8jmcK4IqS8vptnOXesI9qfrU 4wAzX0U3x62SbfBmzrJKiQzMVcYPZRemJZBoQSTbkpVnCx38nQ2QpQ/Teb6cXh42 lzVLLM0LaXUzhwr8il/hh9HgZQDMwNn0uOi3REXoP36wShEzZeaqIdU78o+MIKjv 0EQumID/pk3RlPTsLlK6EYY2s481znaAcU1suiMfIVvJqQSiJ7L5CRPf/V4hdO2j KJT+gL4KDfW9KRnfiskHETMYYGVnzDZ7z5t+fqNH9gu6qvvUqRpR9F89kYGpw/CS 3tXGe8rn1q+660QDaYNZW5zBm2iGbARzJMxeg/Oy6UjPdOysA3xNRl+8oKMiEF8l S/EfqJLQqzCEiXPISimmTvFtIVn3N0cf3hVVBamhb53/PXhQOkioKZsRMvnuTR1r VX895S/GVISTtOubNB5feHRek3IQSrKSzNxGISDnf7Ln5Z9JuGqmVCS5fR4DhQQX 5aR0w0HG8ehoH7cRyh3/oKbwETk/4kgkK9Oq38aJ3JE1GvpxeMoOmwnRmKsS2N9R 0ucV6ABor0AsBZqo8hRAGCQyXvNJDPfwnLIoEzVZJTFF3DegK7A= =b4Z/ -----END PGP SIGNATURE----- --0QFis80IxMWVBagPQ28k0FedIwpuqSSFp-- From nobody Mon Oct 1 04:36:57 2018 Return-Path: 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 4506B130E60 for ; Mon, 1 Oct 2018 04:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_MANY_HDRS_LCASE=0.01, URIBL_BLOCKED=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 0_287gSOkWwx for ; Mon, 1 Oct 2018 04:36:53 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A66D130E78 for ; Mon, 1 Oct 2018 04:36:53 -0700 (PDT) Received: from localhost ([::1]:40388 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1g6wVR-0006Oi-4Z for xml2rfc-dev@ietf.org; Mon, 01 Oct 2018 04:36:53 -0700 to: xml2rfc-dev@ietf.org from: henrik@levkowetz.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Message-Id: Date: Mon, 01 Oct 2018 04:36:53 -0700 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc-dev] RFC 7991 issue #40: Schema Issue, RFC 7991, New Section 2.54.2 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 11:36:56 -0000 VGhpcyBjYXB0dXJlcyBhbiBpc3N1ZSBub3RlZCBkdXJpbmcgaW1wbGVtZW50YXRpb24sIGFsc28g ZGVzY3JpYmVkIGluCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sZXZrb3dldHot eG1sMnJmYy12My1pbXBsZW1lbnRhdGlvbiNzZWN0aW9uLTMuMS41CgotLS0KTmV3IFNlY3Rpb24g Mi41NC4yCgogICBUaGUgdmVyc2lvbiAzIHNjaGVtYSBkZXByZWNhdGVzIHRoZSBwcmV2aW91c2x5 IGF2YWlsYWJsZSAnYWxpZ24nCiAgIGF0dHJpYnV0ZSBmb3IgdGhlIHRhYmxlcywgYW5kIHRoZSBW MiB0byBWMyBjb252ZXJ0ZXIgd2lsbCByZW1vdmUgdGhpcwogICBhdHRyaWJ1dGVzIGlmIHVzZWQu ICBUaGlzIG1ha2VzIGEgcHJldmlvdXMgZmVhdHVyZSB0aGF0IHdhcyBhcHByZWNpYXRlZAogICBi eSBzb21lIGF1dGhvcnMgdW5hdmFpbGFibGUuICBJbiB0aGUgdGV4dCBmb3JtYXR0ZXIsIHRoZSBl ZmZlY3QgaXMKICAgc2ltcGx5IHRvIG1ha2UgYWxsIHRhYmxlcyBsZWZ0LWFsaWduZWQsIHdoaWNo IG1heSBub3QgYmUgdGhlIG1vc3QKICAgcmVhZGFibGUgYW5kIHBvbGlzaGVkIG91dHB1dCwgYnV0 IGZvciB0aGUgSFRNTCBmb3JtYXR0ZXIgaXQgYWxzbwogICBwb3RlbnRpYWxseSByZW1vdmVzIHRo ZSBvcHRpb24gb2YgbGV0dGluZyB0ZXh0IGZsb3cgYXJvdW5kIHNtYWxsZXIKICAgdGFibGVzIGlu IGEgY29udHJvbGxlZCB3YXkuCgogICBSZWNvbW1lbmRhdGlvbjogIE1ha2UgdGhlICdhbGlnbicg YXR0cmlidXRlIGZvciB0YWJsZXMgYXZhaWxhYmxlIGFnYWluLgoKICAgSW1wbGVtZW50YXRpb246 ICBJbXBsZW1lbnRlZCBidXQgaW5hY3RpdmUgaW4gdGhlIGN1cnJlbnQgdmVyc2lvbiBvZgogICAg ICAgICAgICAgICAgICAgIHhtbDJyZmMuICBUaGUgY3VycmVudCB0ZXh0IGZvcm1hdHRlciBjb2Rl IGFscmVhZHkgaGFzCiAgICAgICAgICAgICAgICAgICAgc3VwcG9ydCBmb3IgdGhlICdhbGlnbicg YXR0cmlidXRlIGZvciB0aGVzZSBlbGVtZW50czsKICAgICAgICAgICAgICAgICAgICBidXQgc2lu Y2UgdGhlIHNjaGVtYSBkb2VzIG5vdCBwZXJtaXQgdGhlIGF0dHJpYnV0ZSBmb3IKICAgICAgICAg ICAgICAgICAgICA8dGFibGU+LCB0aGUgY29kZSBpcyBuZXZlciBpbnZva2VkLgotLS0KClJlZ2Fy ZHMsCglIZW5yaWsKCi0tLQpUaGlzIGlzc3VlIGlzIHRyYWNrZWQgYXQ6CiAgIGh0dHBzOi8vZ2l0 aHViLmNvbS9yZmMtZm9ybWF0L2RyYWZ0LWlhYi14bWwycmZjLXYzLWJpcy9pc3N1ZXMvNDAKCkRp c2N1c3Npb24gc2hvdWxkIHRha2UgcGxhY2Ugb24gdGhpcyBsaXN0Lg== From nobody Mon Oct 1 04:45:55 2018 Return-Path: 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 C64F9130DEB for ; Mon, 1 Oct 2018 04:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 dObGm10V690h for ; Mon, 1 Oct 2018 04:45:50 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEA89126DBF for ; Mon, 1 Oct 2018 04:45:49 -0700 (PDT) Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LrevR-1fkMFt0bcb-013MBK; Mon, 01 Oct 2018 13:45:32 +0200 Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LrevR-1fkMFt0bcb-013MBK; Mon, 01 Oct 2018 13:45:32 +0200 To: Henrik Levkowetz , xml2rfc-dev@ietf.org References: From: Julian Reschke Message-ID: Date: Mon, 1 Oct 2018 13:45:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:EJ771dyxRLPFKh8vxO08CMcG8vBrOuQMyzWATVvYFY6/afohnCp //WNLhlwv7sPPBA/N8kenczZL6LxqFnar9GrypKA7PpxEv6b47QxFY+7t6pnS6CqjzhmAv2 yeK7mFRs9dThLjALe67sCC8QTbdjt+i6FaS/sO4XZa6buJHxb/r2HURtja0tXLkBppWLwN3 cbRn86z9Hc6kj8/Jku1rw== X-UI-Out-Filterresults: notjunk:1;V01:K0:O9WG8iMJ0aY=:MYhmCZifeGZP1KzqYKLuye bUYmJ/J1tcDY1sazZsu8fsBnQy7Ta+l9Gix8TUt0TjSXOh55IOM2XnrUWJM4wXhwk/aKo27HL mgE43h9Zu34k4NN7HCfMxdKXZdgh8DSHy4w3Y6GXX6/e2xfe/pfoxR2upGy43y5nIJNHs1tWO 905x5i4EeraMJPr8EyaSSGto1K5nBTH5s7lJc20DkAmRLN6LzN8c93lp5Hr5DBXEllto7RxEG 11J5vZR2xbu8BvDyyYLVA5F+aJXPFH4VGrd+yEDU5W2YjYsLqk5h5CF2S480/hfZCvZoldFav I8bgeCOLDxhwTgjXhJ+EHRfhlQfdMTSCf/vMrLGuyOA53TOq5aNuGo9ND/UIYf32BM5GZUFUz yldJxTjNqnruZtT41e2sulkz7XWJD1DDWsP7pOpNUj77tScwA2fbu6oU5dAj7vfDmUifLm9t+ GfW0E7R2NXAy2GBd/NDvYdlGXZj0sEK3fbJgQhztjywUCDSdb0KN4a1RbF/9MHSkMXrU8X6dP ryhZ6FHstz2jNFcVVvYnZJi0VnLV/IIpJPn1bXqD/eLOix8TPZ23z5fKgNqZFBEo6V0hbfKgj wLgN8yRNFk6D5tYpPu8aaeusi1f3ftCUC7cOBD/R8tw7oUcPZojNXqdARhetFnjDkyyiP9+JD XNrt8cXkd/gyifI8yITQdeQ40EuDbJD8Xbo1SSD72RNzCRuESCWj698qCNd0YQfmHJgWIn3Kq 3BMytprspzEDCZcviwpFAX5Ct6zdGIrd+/hGbREkFCVVItPZCXw4n2FOTpn9X50yNryGHe6LC nQ+AG8b1hdR9eaZDZ+rFdK+APVA+v4Pp5x4YIPeGOZzMtG816w= Archived-At: Subject: Re: [xml2rfc-dev] Specification issues found during implementation of RFC7991 etc. 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 11:45:53 -0000 On 10/1/2018 12:58 PM, Henrik Levkowetz wrote: > Hi, > > I'm about to start posting individual issues found during implementation > of the V3 specifications to the list. > > These have been described in draft-levkowetz-xml2rfc-v3-implementation-notes, > which I'll continue to update, but in order to facilitate discussion of > individual issues, I'll be posting them to the list one by one, in chunks > of 5. I'll also add the issues to the issue trackers on github. > ... Can we please *where* we'll discuss things? Parallel discussions in both venues would be unfortunate... > ... Best regards, Julian From nobody Mon Oct 1 04:58:59 2018 Return-Path: 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 81025130E4C for ; Mon, 1 Oct 2018 04:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 RoTqRyk7rwlU for ; Mon, 1 Oct 2018 04:58:55 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72AD0120072 for ; Mon, 1 Oct 2018 04:58:55 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:61623 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g6wqk-0006OR-RN; Mon, 01 Oct 2018 04:58:55 -0700 To: Julian Reschke , xml2rfc-dev@ietf.org References: From: Henrik Levkowetz Message-ID: Date: Mon, 1 Oct 2018 13:58:47 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="u2GCD5GqJ5W0ceCSfM864tVmQQrXrfMGa" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] Specification issues found during implementation of RFC7991 etc. 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 11:58:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --u2GCD5GqJ5W0ceCSfM864tVmQQrXrfMGa Content-Type: multipart/mixed; boundary="38boF16dJ6frLIrMf8X34pKq5jTmxoFuS"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , xml2rfc-dev@ietf.org Message-ID: Subject: Re: [xml2rfc-dev] Specification issues found during implementation of RFC7991 etc. References: In-Reply-To: --38boF16dJ6frLIrMf8X34pKq5jTmxoFuS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Julian, On 2018-10-01 13:45, Julian Reschke wrote: > On 10/1/2018 12:58 PM, Henrik Levkowetz wrote: >> Hi, >>=20 >> I'm about to start posting individual issues found during implementati= on >> of the V3 specifications to the list. >>=20 >> These have been described in draft-levkowetz-xml2rfc-v3-implementation= -notes, >> which I'll continue to update, but in order to facilitate discussion o= f >> individual issues, I'll be posting them to the list one by one, in chu= nks >> of 5. I'll also add the issues to the issue trackers on github. >> ... >=20 > Can we please *where* we'll discuss things? Parallel discussions in bot= h=20 > venues would be unfortunate... Heather posted a message about this earlier: https://mailarchive.ietf.org/arch/msg/xml2rfc/lCKusXCBrPcX-UazKirg4pCrfHs= Accordingly, I've also indicated in each of the issue postings that discussion should happen on the list Best regards, Henrik --38boF16dJ6frLIrMf8X34pKq5jTmxoFuS-- --u2GCD5GqJ5W0ceCSfM864tVmQQrXrfMGa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAluyC/cACgkQTptXS4+7 FxoKYA//Va4d7ug4yrZrT+pDUknItx2BnlgJP6QQnyhvdZ+lfr4ED09hii+1qw3x i/ArhGBavLlHvX/SRrgaCIT4n/lfhpJd6Qxv19QigDCVG1ORqOKFHBJgTv+F2k6F PxHQafOkKqBy2ugwFm/GZRj8ur9SWxgE00DKX20MFVdjB8Ywvp0VI4XyFfz7iRAw uC7Vs0m9k2WcMIY7gI/YIwabmlh15/zDafEqN/yh413NqHRyqsSWfX1U5+OKLu2l J5YubLYqFYTMoxJiNUgR8chnzIfN/lw0cGkPBytilMwQXAHvU/c852c+J6/4I3oD SeZlKUv2zNX328lVPoAhQQ0qsVxG0MTIeXrbOAfXC+ICksddYTFMv4+BAjzclPJ8 kBsVQIOnRjYvUgPf9On5AnT9KlEgh9N9M9KpryycjziU7e9jFHoC1r0ypen0LA5e +EDFhdNkNmGhei8AarXzlpXCLL6kHebnALa09idw6QV5b0Fdrq7VQkovsSoYfNFe x0qi+1AOyBCGM1gUgHJJBZZQFhSdtbDZSYFkxJ6+KdL8LACqinmUP/oueUWr/hSC eKe3iVkaA25B5Cj3rMfIgaya5Y9xWpviAzu3oZ/OGH60rR84m2fuBZQt52c8/9xc A+yWsezcX8RqtjVEx/LygnMFXJSt1vom9M45mVQ+B42wcVmd8pU= =IAki -----END PGP SIGNATURE----- --u2GCD5GqJ5W0ceCSfM864tVmQQrXrfMGa-- From nobody Mon Oct 1 05:07:25 2018 Return-Path: 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 EC0E0130E4C for ; Mon, 1 Oct 2018 05:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 5RT5KxJ9YDsP for ; Mon, 1 Oct 2018 05:07:19 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8408130E5F for ; Mon, 1 Oct 2018 05:07:18 -0700 (PDT) Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Md31i-1gO4O535gQ-00I9Ry; Mon, 01 Oct 2018 14:07:03 +0200 Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Md31i-1gO4O535gQ-00I9Ry; Mon, 01 Oct 2018 14:07:03 +0200 To: Henrik Levkowetz , xml2rfc-dev@ietf.org References: From: Julian Reschke Message-ID: <3c910bce-604c-1deb-2a70-6aad434c8385@gmx.de> Date: Mon, 1 Oct 2018 14:07:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:MYdpBXqaFhj+KVq/+rzNwDT9G/gOWKxWME4GbrynzKTbaqr9CsI WB65Vr8NvKnINBEk4R7AsZviJmf3xCYpU4NY1oQQEytL4IOlTw/LhYglzo5t0TbQMc2z2L2 IDF09NQe4y4fYGR1x+YuG9MTEjrac8Mf7q5zKnbxXuLKhwBiwUSVuf2pZPDl/IfJxCHvsA5 vS8TEdyyKHSjtJ8qD01zQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:kF4i7/gt+nU=:MeDbV68uuYmzboPuY0AwiX jKQNBJfYA4634Kf+G6neacNTLO8dBa4zLZptbkcJUbEpya4D99hMKRvrQD8iQjBgZU+kvgh+/ Iup0GXZHOq9jW/709QMLXgw4R0P0OKuU7BcSOUxKeAOrjQKxJWlJ1sbS/2uvX7VKLIRzAFC1y R874Tbyg41EHFSoUvRRk/H9kZ/EQkegck1KtaCqhBcJ10x8CCn3USqk9vBGK9ZzjNyIu6jxEI XKffzVMNFLvw2yy6VD5EXZWgKuNToOmotE1Iue5FF9L+8wJUi/UBGNoNq+97whE7zdBo9E5WR P01SbgHT0KNiraV/s/uKt+/2N+sotpoZZf77GaVnIekgmBgFlItK7QyVgkVgOeem4w6NdbPlC mCDahoOzSSMqeqi2c6eUgxCjLkn8ztDeOPnwN1huG5JuQDr69FvnpVkz/kQLkBufHc9UTBg2I IVJAqXlzwA+UjFtfaRyYq3mJdAVdufvdRDsJ++OQbyltv4WQqGCfsS6OrhNCDtxCfFEBeTOY0 dM9IMZOQR5J7AW47LCNvk32svfm3q67Mg8nPBrU93zyRIc53MfTYtAkOjm1R5Z/FO/7Ayol5Z e9EGSpz7c3gt0jbu92frQq+Ac2IFaReS2kj0Iug92yRNvwcEkDuyrwbCh/bWhog1uYF84iec/ Rx1RS1pzgrg94NZigqtUCHgdMY+yziKEVc5NJL+Bizy3IxzdmfoyArrTKqodKyc5HpQvbqzZ7 GgVoZi4DZJf3exnOeyT/c1fSNI8vPcad9eYQ2Amod01c6ZWj2FBkVI/33sQ99T7AfsO3WMKhM OwaVf6gsVjBXNXUzvRx+SpizDsnLVnwENBcSgTAF54a6TTk4wU= Archived-At: Subject: Re: [xml2rfc-dev] Specification issues found during implementation of RFC7991 etc. 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 12:07:23 -0000 On 10/1/2018 1:58 PM, Henrik Levkowetz wrote: > Hi Julian, > > On 2018-10-01 13:45, Julian Reschke wrote: >> On 10/1/2018 12:58 PM, Henrik Levkowetz wrote: >>> Hi, >>> >>> I'm about to start posting individual issues found during implementation >>> of the V3 specifications to the list. >>> >>> These have been described in draft-levkowetz-xml2rfc-v3-implementation-notes, >>> which I'll continue to update, but in order to facilitate discussion of >>> individual issues, I'll be posting them to the list one by one, in chunks >>> of 5. I'll also add the issues to the issue trackers on github. >>> ... >> >> Can we please *where* we'll discuss things? Parallel discussions in both >> venues would be unfortunate... > > Heather posted a message about this earlier: > https://mailarchive.ietf.org/arch/msg/xml2rfc/lCKusXCBrPcX-UazKirg4pCrfHs > > Accordingly, I've also indicated in each of the issue postings that > discussion should happen on the list > ... Ah ok. Sorry for the noise. Best regards, Julian From nobody Mon Oct 1 05:08:13 2018 Return-Path: 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 5B441120072 for ; Mon, 1 Oct 2018 05:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 EYfu4jwkyt8q for ; Mon, 1 Oct 2018 05:08:09 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960A7130DF0 for ; Mon, 1 Oct 2018 05:08:08 -0700 (PDT) Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LejNC-1fNThF3X5S-00qQ36; Mon, 01 Oct 2018 14:07:55 +0200 Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LejNC-1fNThF3X5S-00qQ36; Mon, 01 Oct 2018 14:07:55 +0200 To: henrik@levkowetz.com, xml2rfc-dev@ietf.org References: From: Julian Reschke Message-ID: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> Date: Mon, 1 Oct 2018 14:07:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:zDn2kERUji/nbdCqJKg6JQ2MkBcRk5R9M6vD5tfBCKWDSMUp6Af 90cpBxBb1qzbJunq84hpCqlr1APlnpZhJ8PBGGmQwbV/LAHfrBkUVwBE57CJV7l+j45NvN4 HcU0H3p/ZjF0IxC9LRXVjSleUr+XQKD304cDOpieR4Dsctd2wwTXbm21OFrsRkkYznTGj4F 30yQiSE6BEvHhbqQXXK+A== X-UI-Out-Filterresults: notjunk:1;V01:K0:8bGThWbypq8=:nsdux5n7A+xPd4DyhJVfMF bX81DY+R6I7GaDIZ69V/tB9yDm+FF0tU76l5394sBO+yctbnQX/YP3uy043nin6Sh4P53hbMN esFkwguQqx94AMMKDCB7F4gl0vHVroV1Gbw788LqjI9LU21o0Pa5EmJomZ6Vgp0cnU5+GL81C enzi9YMqPeXjThJ8HrhuBukOF4tWtHRUq4qPc8f+BnldXfhFG8hC7LYM0KCe7R/G7HZ6+YlXq rd3eMf83IKnAi6x/8fdWC9VoOWJ1F1FRKlp5ZtaV4eoxvJtplq9AVjwq4WeI2+dg6WRO5mBOF DzW4X9d5Fr9G6D+pavlX7mJohXI6CP9s7dt/BCLNbxgMeZ14y+L7jsMeX9f+qEmY+O+SL2Asn AaE4CPp1NhRJuNkhip4cWDbyYvO8X+4FEK4c6T9bcvpjj/rcp2zuPipImol4/C59JNLg6Io5f 3RDawKTRCzhdKxkHHWSTtW6ERZz3JfZ0XEthoiaE+YOrIvCcbV1mWZ7EHwv4Y2YuDc4zvK+jZ 2gBCXV7HJ0zq7oN0Ea1omiO9W4kpR03AjGnGptpQmY0MzinuElBA+NtIf8SSwIMwS43iKa6d/ 3sxFh9revdxB80edrPLchttZ7B669WoEqOqjd0rSSbAH9kMjENcNr9wISRQDc5JRrI5uzSv6T zQfStm9hJtMNGjfYemsuQbZwoU9jJ3CEjN96D7dR0HlycCy3lcS2nGha79hWPDDA7fg0mX+T8 NUgazKbieByo4VWjrVIbNu+Da1vTcdwqoo0Innb9R6GKIEA4zfOHODWgCDDgqSBYQr8KxeMj2 x+CAx4+NRZYGk8cpZEVca1BB2KoRWf3Fz+bUL0vp8pyGQBg5uE= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 12:08:12 -0000 On 10/1/2018 1:31 PM, henrik@levkowetz.com wrote: > 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,
> > A number of elements permits a mixed content model (see Section "Mixed > Content Model"):
  • ,
    ,
    , , and . However, > when using the simpler of the two content schemas, two of them ( and > ) permit inline line breaks through the use of
    elements; the > others do not. This seems terribly arbitrary. > > Recommendation: Remove the
    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
    as a > newline in all inline contexts. > --- As far as I recall, we ended up with the limited use of
    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 nobody Mon Oct 1 05:09:36 2018 Return-Path: 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 C34E6130E5D for ; Mon, 1 Oct 2018 05:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 v7jQxMWgnUKy for ; Mon, 1 Oct 2018 05:09:31 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 252CA120072 for ; Mon, 1 Oct 2018 05:09:30 -0700 (PDT) Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lr32V-1fTETs0Wjj-00eaj7; Mon, 01 Oct 2018 14:09:19 +0200 Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lr32V-1fTETs0Wjj-00eaj7; Mon, 01 Oct 2018 14:09:19 +0200 To: henrik@levkowetz.com, xml2rfc-dev@ietf.org References: From: Julian Reschke Message-ID: Date: Mon, 1 Oct 2018 14:09:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:KR2F5dQdzyeXcTYArEERHqrP60APwFxeit0WenND5tQZn/1ywxn d5zo9SlgzmrDcECQuG1seTauBDOE+qIanr6b6Ntf76QIinyJmAWRF2J7xUkQW3bElxXpOip dpMFPMef5w4VGiBtdZoGVJJtjSUAgOYjQGV7YyJPouVCodb6rTUdTMeDRrxHWioeLXhQtXo lw55Coir7zebiC+a+Xi3g== X-UI-Out-Filterresults: notjunk:1;V01:K0:zWTMNt4OCOE=:aFB4aOWJ7e1z6thKWeYMKU v3z72T8rDKgge+VAfDKjdbQI6Ja8ArH+WtKuDfI191F2uLyRkmOMvGs8elDc1QoU4x3mBI7k6 LdSoArEoYuZqD62Xd8ahRwnzt4gvnsV6/0aY60/RIOmbOZmYhFfwDeQ0zsYO8xyefvLOz1XyV uQZVlusdsee6VTeHq77vsNc+66saAX2FLVenoTdCpT/i8Gmyp+ROnVJw6AIQFyYN7Jt6JRqPi UWvpyHNXPSv8QAee9cvNh4Nb1l0irk8kgga1yDXMS5kvcmS0rL7sIYH2B+9IDGx3S3ghhecVz mVHAHlOJE8g0lS0gPPYtPTC40ViILwIKyJ4b46dSORAB3nGDuN86WDwLHw2DRZbs7rhiCHY+D ixuDHyDwzME0f/YbgCdkN90q0b5FKjzAVKbqzvdD82LRZ7XcAS2AqrN2wg3giRYYrkfHOg10z 2IkqMlkOQvUuuR/giI3t2fINeLCGb9iKfAWmLl8V81gKZvgBdbDuOVQaPWVsN5wnmczB7Fsqe JLI6+kP5fP5l8JnlH61iAHc/PLaAvePZtHjAUjDDqoxWDTAwRoRUb6d1KQryleyEKu2NUlH+6 Z7rF8iEvKY06XsvOvZ8ujSVShKtrH7EA7PMqdZ+IdyX5hBcHCOEuKTh0ra0JUcgZ0D9NNNIT2 Spy5IQj+KmFEj2b/TqFlIGIL3xmzgutfAK5krS+hn38GupiKXrNrN5zBpHKsmTYNa8Vz9Cn+s WWBSX82v5uDc4blbHuoc2bJWlT5kO7wYBUOrgHzwSUs264FKUPafqICyLkS7+v87buwJGQ0pW j1lqHMnI4d4AabAVhBGL9IAneLXInBDjHcP7wWxBS9v62xdbxU= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, New Section 2.20.4, "indent" Attribute 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 12:09:34 -0000 On 10/1/2018 1:36 PM, henrik@levkowetz.com wrote: > This captures an issue noted during implementation, also described in > https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation#section-3.1.4 > > --- > New Section 2.20.4, "indent" Attribute > > The deprecation of the "hangIndent" attribute on leaves no > opportunity to control the size of the hanging indent. In some > definition lists, it is desirable to have a wide indentation, in order > to clearly show the terms, in other cases it is more important to allow > for a larger text volume than the width of the terms would allow. > > Recommendation: Add an "indent" attribute on
    to control the size > of the hanging indent. > > Implementation: The current version of xml2rfc does not support the > attribute, but has all the underlying functions needed > to apply such an attribute. Internally, an indentation > is calculated based on length of the
    text and the > settings of some of the other attributes. > --- > ... I agree that this would be useful - however we'll need to define it in a way that works well with non-monospaced fonts. Best regards, Julian From nobody Mon Oct 1 05:10:28 2018 Return-Path: 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 B78A7130E72 for ; Mon, 1 Oct 2018 05:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 mcSpGTRASsr6 for ; Mon, 1 Oct 2018 05:10:21 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27CDB120072 for ; Mon, 1 Oct 2018 05:10:20 -0700 (PDT) Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lr32V-1fTEQd3hjP-00eaP8; Mon, 01 Oct 2018 14:10:08 +0200 Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lr32V-1fTEQd3hjP-00eaP8; Mon, 01 Oct 2018 14:10:08 +0200 To: Henrik Levkowetz , XML Developer List References: From: Julian Reschke Message-ID: Date: Mon, 1 Oct 2018 14:10:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:O5gfOT5o2pt6V+qOYoamejGOlmmDtQhG/tyI+XmMDB6uSaH2tfN lV/aZnnq3ir2SabpFdkK8JD5BIFSdNmXmfjOX3D0WJHYqerymegGt9aAtogO0epsJF0Pv3h mIP7VPtNljb1JlbMxc8dZWqi6NOJgdL4Ts2Cw7xNt0SQTPrjPoPk31AL3fpaCmVdx3JnxBR nwyW8fGhIHuLx9u3uuX4A== X-UI-Out-Filterresults: notjunk:1;V01:K0:KjuCyi1IWxs=:ccbjjgcXBeDdwetPiiKW/0 vu2sobejJbi0B0lMQx/iVzPCA8p25bzoOPtHyxmFgReuEEBIxphQ5z+RHDIv96FGL2LZ10zf4 t7LmfAQYNNsS8ozHdvPC7imU7tVM4bQMGExCke9J4UGkrZcOk+LAUyDYnyllmHApPX0bel8w1 YYQN98zqtjiao5/ySmInAzsCTQDnSvMxLV+s1ZyNW2pQwMItzfYNvevhTxqplfSzX6O6V+tnh cbkD5Jtl25HOvwr9/lJUyVSaK0NMhc5++1nk8kSozz0zJ1hJRKyb3PXnEVaALje6t3zFaAr9D 6y1o1RdXrN57u1VuJ8xFqKdEZyxhl0Mvc2doV7a6s1Mlz9+ydyB4ESdu5AHV0uFuEMQtuA3+n yuv2k1wNkfJBcZr1TeLDYHRjRdHE1GYFKbvjgCrb9SZoHo3rP8SP6lsrJu6sM8ksHsVfVvE1d /N2FKSG/W6sSfCvrZLSKJa6WU+4srJJ7cxkGjt74OA8Z8qwb/bQM2PR2CDrLUXLsabIZm27H/ wgcm9zVDvk61XE/PT9NxjqEF/qvoqDE0k+grpylPvJdYGuuZbpPX46xwxxQDOkyP1i8/bL+79 Ys2qFC2nzA+HHB0dP3kJV6utnnY8zojJHgLHSEsdE0ZtDAWwyHoBjoBI1c3VAhIQPb2v5l345 uuNygql3OzuB2ZRxcQqW3cNNzZH1pl8lxHTSk84ahZ547o+Dv80hZhJ+yYn4WxmWiLnd5Jhfw yLzQYs2R6HUuDnIx0pkHqQOnVgwal/w3mKs5yrZmk5PfmHQAyTqEI3xE8lCqN6z16/DT486xp /QD3oR9W1UkoLkEdCSn5zi3phbcSCXJ3Z29h3DNATmEKYmE+mo= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #36: Schema Issue, RFC 7991, In Section 2.5.5, "name" Attribute 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 12:10:26 -0000 On 10/1/2018 1:36 PM, Henrik Levkowetz wrote: > ... > > "A filename suitable for the contents (such as for extraction to a > local file)." > > Given the existing use of "name" on , this attribute name > has a semantic dissonance. > > Recommendation: Deprecate "name" for use on and , > and instead use "file", which for will be > explicitly rendered, as established as best current > practice for YANG modules (see for instance RFC 6087 > [RFC6087]) > > Implementation: The current version of xml2rfc uses "name". > --- > ... I would avoid making changes that aren't strictly necessary, thus keep the name as-is. I also disagree with coupling the sourcecode tagging to the presence of a (file)name. This violates the principle of least surprise. There are good reasons for providing names, such as for automatic extraction during build time (for instance for running check scripts), which have absolutely nothing to do with the presentation in text or other formats. Best regards, Julian From nobody Mon Oct 1 05:11:20 2018 Return-Path: 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 38AC5130DCE for ; Mon, 1 Oct 2018 05:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 QXPhNiGH3XWM for ; Mon, 1 Oct 2018 05:11:16 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CBFE120072 for ; Mon, 1 Oct 2018 05:11:15 -0700 (PDT) Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LsD9n-1fjntS1SdL-013u8N; Mon, 01 Oct 2018 14:11:01 +0200 Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LsD9n-1fjntS1SdL-013u8N; Mon, 01 Oct 2018 14:11:01 +0200 To: henrik@levkowetz.com, xml2rfc-dev@ietf.org References: From: Julian Reschke Message-ID: <58b7afb2-53a4-8ee0-ba99-6d4a90c561af@gmx.de> Date: Mon, 1 Oct 2018 14:11:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:711HdokXwTU8EWmvyWuJ+4OCRW4lF/WA35i98sbp7CPcT2CWWYE go+0WJppgEncOcqYAt0+yMuIs0l+B6205B0xd3gqsYspQW0r8bzqYA1utAgPGf1We48CJcL RuMnLQ+IJJ1NLZHuRqU6UZxp29D6Cp4u1gPUgalUGNFVwCgUJZ6WyxXmhoaopNZqtg+8/mh hQ3i9DBccjCAm91bJtWJg== X-UI-Out-Filterresults: notjunk:1;V01:K0:rq0qv+2F/4I=:v5R923Fxb4XcEfDrQBBGeG GkZYCrWDjsXtWxQd6rEeKblEv4qlqXTCBQBllDlJseTy8Rdr4QSMdZf299mN3M31l+UTkXoB8 ERqB8yqeTFlPoKOZYr+VkI8KpBJUidCFdYMpWaH5Fp73gyjCFqAzFimrgOOGJAqkQgzs8DEhz /h0uL9btT4ONd0StdCmeO+IqDpuHyPqV5RJzRIoizRn1mVvb+fqffzUD973H5HVCB7zAxrHJg GlvePE5mt1LabSivpD1V4i+ckmIAsROdljwIlrs6tvOTbZS/21cut0CPMF2hQ8K3twkkhpGEi 063kdowfoPQ98nSktqtta/SPS6Yg8F/2vMQp069+4qdP04P3GtF17gD3yf+mPbwJAMoqO9gSe e4o2Lw+XkvwbwnFJ+1Jvb0/a0FB6tBiOLRtUNYST+yGmygNe7tJ54eDr51g29PiOAhd9kj+Pb th8pDAHLiX3Bg6vfJ+aZm3DOp7+j4CkUt7UmpoKOEGi9qqo+4iz6PLH6n+4gr99spV45HsD7i 1qjhjKh6K8yacQbmEhalquiWBFQGGuuAcDsDy2+Q7QjzkWoHXko9HXQs6kX0L474B+IO6YXYD zxS84KTtQhm7Ll+W1vldLPgQp7hNV6RuNKb2lK8bfaJSEfkKtNW81gfzqVtfJ7U+QkgrJkDF/ BVWmdG227AmkEaVqZqNd2hsk8uE/D5gBsubijZwfLjICuk8GVvLVz1KOHO696IE4yyz/l+/mK OqmakfZt4njwzKo6UPuKHNmeFe98UB2CZStM0OGz89CG1tZNw+F+zOpQgfvcYc265aUP6MbOT Htzmb22r4Q8qjQnDVbLrgpHgFwHOsOfoJb6h0FE/6hiMiSkMSc= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #40: Schema Issue, RFC 7991, New Section 2.54.2 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 12:11:19 -0000 On 10/1/2018 1:36 PM, henrik@levkowetz.com wrote: > This captures an issue noted during implementation, also described in > https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation#section-3.1.5 > > --- > New Section 2.54.2 > > The version 3 schema deprecates the previously available 'align' > attribute for the tables, and the V2 to V3 converter will remove this > attributes if used. This makes a previous feature that was appreciated > by some authors unavailable. In the text formatter, the effect is > simply to make all tables left-aligned, which may not be the most > readable and polished output, but for the HTML formatter it also > potentially removes the option of letting text flow around smaller > tables in a controlled way. > > Recommendation: Make the 'align' attribute for tables available again. > > Implementation: Implemented but inactive in the current version of > xml2rfc. The current text formatter code already has > support for the 'align' attribute for these elements; > but since the schema does not permit the attribute for > , the code is never invoked. > --- > ... +1, but duplicates #9. Best regards, Julian From nobody Mon Oct 1 05:38:05 2018 Return-Path: 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 BADC7130E61 for ; Mon, 1 Oct 2018 05:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 9h_B_4zAEYm0 for ; Mon, 1 Oct 2018 05:38:01 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74249130E60 for ; Mon, 1 Oct 2018 05:38:01 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:61713 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g6xSa-0006nb-GO; Mon, 01 Oct 2018 05:38:00 -0700 To: Julian Reschke , xml2rfc-dev@ietf.org References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> From: Henrik Levkowetz Message-ID: <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> Date: Mon, 1 Oct 2018 14:37:52 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8RrRxSLcfdigoqmm4spDJBXrkSjJp3sWb" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 12:38:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8RrRxSLcfdigoqmm4spDJBXrkSjJp3sWb Content-Type: multipart/mixed; boundary="jKXhWNsJt0pjBgjaa6u34RusAPpm6wNdD"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , xml2rfc-dev@ietf.org Message-ID: <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> In-Reply-To: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> --jKXhWNsJt0pjBgjaa6u34RusAPpm6wNdD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Julian, On 2018-10-01 14:07, Julian Reschke wrote: > On 10/1/2018 1:31 PM, henrik@levkowetz.com wrote: >> This captures an issue noted during implementation, also described in >> https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation#= section-3.1.2 >>=20 >> Specification: https://tools.ietf.org/html/rfc7991#section-2.12 >>=20 >> --- >> In Section 2.12,
    >>=20 >> A number of elements permits a mixed content model (see Section "M= ixed >> Content Model"):
  • ,
    ,
    ,
    • , and . Howeve= r, >> when using the simpler of the two content schemas, two of them ( and >> ) permit inline line breaks through the use of
    elements; = the >> others do not. This seems terribly arbitrary. >>=20 >> Recommendation: Remove the
    element completely. Alternativel= y, >> permit it to be used all places that 'text' and n= on- >> block elements may be used (that is, in inline >> context). >>=20 >> Implementation: The current version of xml2rfc renders
    as a >> newline in all inline contexts. >> --- >=20 > As far as I recall, we ended up with the limited use of
    because=20 > forcing a line break inside a table cell sometimes really is needed,=20 > while otherwise it's not. I agree consistency is nice, but this may be = a=20 > 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 us= e
    by Miek, when he started adapting his pandoc2rfc tool to use the v3 vocabulary. I would say that even if
    in running text would rarely be needed, the= confusion Miek ran into is unnecessary, and limiting
    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 --jKXhWNsJt0pjBgjaa6u34RusAPpm6wNdD-- --8RrRxSLcfdigoqmm4spDJBXrkSjJp3sWb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAluyFSEACgkQTptXS4+7 FxrumRAAhRE2pEZwSKJJK+oGkH1JXM+QnL2H7ytUiO0R0AUwbIUSAf5Uy/PsfESN dZndWKlQ4abfeUcJKWnIb4dICm7vSRnp7EpKrueoOQ7pibUVAKZXaV1deq9X6JUd qnqVTaM861oaTDh90gNRkGy5hcud1TN/TJBuXfCgdLF/PeePe3hKnmJK0/UuPfNa s7Ok9x8NODiG10aek9KAFR5XmbBbl7IPBdsZLlJDM1wyUCYMavlkfFXCT06Wu1w8 yEzG2bwzbluGjBvh1mKw9rTpp8T2NIZ45gJi69QTqux3tWGHbitMRrZsnAYIVNUp urYc8nZhd8bxdmuxgDjIhnOeo9LRDRcokpS68SJrh9cYja302XmV5I1jsX05y8Pe 0TX0vcJ/+rW7SLAisCXO7poyTV6BiAjv9C+N9RFtDZwmUZ2yT+91jpqGZy4xN9gz +YZduODAsoH+fdtrRBslgie0J/A7xgzyP8AA30avnE31PL2iT8mxqD1tbaoSurvs kB2NI4hOwvkD+nlLxzXHvM2AOA7Brx2CkmeSd47Qq6H8viofZejzCe2sZhlS5ZG/ A9ODT8U9cHXXSRYBOn3OVP32/oSW9BmUMgvB1uPviXSCN6ivLGYfQwZfJ2KyMPPS YFcFscLsHLlZtpxhJdmhOKheOuAvl/6QnG+NzHQ+mYTHSLFMP7s= =/O3i -----END PGP SIGNATURE----- --8RrRxSLcfdigoqmm4spDJBXrkSjJp3sWb-- From nobody Mon Oct 1 05:40:06 2018 Return-Path: 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 A6CC1130E60 for ; Mon, 1 Oct 2018 05:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 q7oVJHwJ3oyX for ; Mon, 1 Oct 2018 05:39:55 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 148A5130E61 for ; Mon, 1 Oct 2018 05:39:55 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:61717 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g6xUQ-0003ME-GM; Mon, 01 Oct 2018 05:39:54 -0700 To: Julian Reschke , xml2rfc-dev@ietf.org References: From: Henrik Levkowetz Message-ID: Date: Mon, 1 Oct 2018 14:39:47 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nOlDQCasKesNLiNvIU6sFFNvS2qB6OEhd" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, New Section 2.20.4, "indent" Attribute 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 12:39:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nOlDQCasKesNLiNvIU6sFFNvS2qB6OEhd Content-Type: multipart/mixed; boundary="jV3IMbWGnBDk2LNHmpxoo1lIaha0pNKAP"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , xml2rfc-dev@ietf.org Message-ID: Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, New Section 2.20.4, "indent" Attribute References: In-Reply-To: --jV3IMbWGnBDk2LNHmpxoo1lIaha0pNKAP Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Julian, On 2018-10-01 14:09, Julian Reschke wrote: > On 10/1/2018 1:36 PM, henrik@levkowetz.com wrote: >> This captures an issue noted during implementation, also described in >> https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation#= section-3.1.4 >>=20 >> --- >> New Section 2.20.4, "indent" Attribute >>=20 >> The deprecation of the "hangIndent" attribute on leaves no >> opportunity to control the size of the hanging indent. In some >> definition lists, it is desirable to have a wide indentation, in o= rder >> to clearly show the terms, in other cases it is more important to = allow >> for a larger text volume than the width of the terms would allow. >>=20 >> Recommendation: Add an "indent" attribute on
    to control the = size >> of the hanging indent. >>=20 >> Implementation: The current version of xml2rfc does not support t= he >> attribute, but has all the underlying functions n= eeded >> to apply such an attribute. Internally, an inden= tation >> is calculated based on length of the
    text an= d the >> settings of some of the other attributes. >> --- >> ... >=20 > I agree that this would be useful - however we'll need to define it in = a=20 > way that works well with non-monospaced fonts. Agreed. What about specifying indentation as a number that would indicate charact= ers in monospaced output, and en-space otherwise? Best, Henrik --jV3IMbWGnBDk2LNHmpxoo1lIaha0pNKAP-- --nOlDQCasKesNLiNvIU6sFFNvS2qB6OEhd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAluyFZMACgkQTptXS4+7 FxolPBAAihMe7Lsvd61RI0kbXxWowZVx2xEb8E/vuMV1aQ/jTn//13XBJQQBmcHt gOJw9ezy7MkBKVVVVq8VuwJUUQJwOb9pTWVp8CaGDJBktJsGc7SM5xerb8noKtK6 NdBMcBB/3lk9xhkTj5bIfpUxqGIJnobrCaWOapRgMJJeJHBusvx01qBazNNPtudR kNVnICcAs0LSoUlo1YB73M1eIF+0zw2BVnsZ0sZ31eSfkIj1xVr6dZUeaMuvWPNP 8N/WPRaarwcY7/5bt9omc8CWJrxb2R4+gX269I/42ngcppBgGireqVxRobTLno6m zszTBtV0go4ve7wXjEno6KEQtYrvAnd4AxQe364L2IUbZGZbSDue5tt2qDh7GKH2 XziMIPaez0SI+UrKerc0IXjq0EkfFI+ThAi6zebXv36RgqRVCcK12YZdoXfSmu11 LIDnBU2F9gpuMRiTLLX5Gk7syw0d6YAJwP3UPSufVsJQwiZ9O62S6Sys7cR7IwO/ kes/iMC45T1JMPgbKIDovy11oqVjOU66DN9zIV8weIbbZ7dk18wUCdV4FPsRikpl dP5mmIiPmz3+GaTMsxDcWmFHP/IVlCdIdUoRS6jTeYh0nYfOyqdJjb1FTMrRnOde QzXJIlh6Ujr668cCq7/ZOMcYp+fIwlataX33nD6sxJx3rUq7q2M= =EWrR -----END PGP SIGNATURE----- --nOlDQCasKesNLiNvIU6sFFNvS2qB6OEhd-- From nobody Mon Oct 1 05:45:31 2018 Return-Path: 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 1394B130E60 for ; Mon, 1 Oct 2018 05:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 EoZPmI68EKup for ; Mon, 1 Oct 2018 05:45:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0F2130DDC for ; Mon, 1 Oct 2018 05:45:27 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:61722 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g6xZm-0006Wo-HY; Mon, 01 Oct 2018 05:45:26 -0700 To: Julian Reschke , XML Developer List References: From: Henrik Levkowetz Message-ID: <66f634b8-1789-cb13-02cc-08dcbdeda373@levkowetz.com> Date: Mon, 1 Oct 2018 14:45:18 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kjRVdBBIf432Ei30g36Vtbl4jG9jMOVkp" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #36: Schema Issue, RFC 7991, In Section 2.5.5, "name" Attribute 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 12:45:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kjRVdBBIf432Ei30g36Vtbl4jG9jMOVkp Content-Type: multipart/mixed; boundary="sJ9ehU2bHLTiAX7jLlub1NM1oftuhm6Aj"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , XML Developer List Message-ID: <66f634b8-1789-cb13-02cc-08dcbdeda373@levkowetz.com> Subject: Re: [xml2rfc-dev] RFC 7991 issue #36: Schema Issue, RFC 7991, In Section 2.5.5, "name" Attribute References: In-Reply-To: --sJ9ehU2bHLTiAX7jLlub1NM1oftuhm6Aj Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Julian, On 2018-10-01 14:10, Julian Reschke wrote: > On 10/1/2018 1:36 PM, Henrik Levkowetz wrote: >> ... >>=20 >> "A filename suitable for the contents (such as for extraction t= o a >> local file)." >>=20 >> Given the existing use of "name" on , this attribute n= ame >> has a semantic dissonance. >>=20 >> Recommendation: Deprecate "name" for use on and , >> and instead use "file", which for wi= ll be >> explicitly rendered, as established as best curre= nt >> practice for YANG modules (see for instance RFC 6= 087 >> [RFC6087]) >>=20 >> Implementation: The current version of xml2rfc uses "name". >> --- >> ... >=20 > I would avoid making changes that aren't strictly necessary, thus keep = > the name as-is. I think now, before actual use of v3 starts in earnest is the only chance= we have to make changes like this. So if the change makes sense, let's do it, rather than live forever with something which is (even if only slightly) less appropriate. > I also disagree with coupling the sourcecode tagging to the presence of= =20 > a (file)name. This violates the principle of least surprise. There are = > good reasons for providing names, such as for automatic extraction=20 > during build time (for instance for running check scripts), which have = > absolutely nothing to do with the presentation in text or other formats= =2E On the coupling with sourcecode tagging, it was not my intention here to argue for that. FWIW, in the next release of xml2rfc the insertion of will be controlled by an attribute "markers", with the default being "false". Expansion of "file" or "name" would occur only for markers=3D"true". The "markers" attribute is of course also something we'll have to decide on, quite apart from this issue's proposed change of "name" to "file". Best regards, Henrik --sJ9ehU2bHLTiAX7jLlub1NM1oftuhm6Aj-- --kjRVdBBIf432Ei30g36Vtbl4jG9jMOVkp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAluyFt8ACgkQTptXS4+7 FxrFmxAApeBhAy/jUwZgtZLueXozGmif+Bs8sS76GQJNfsG1Q180oDedm6qZ3anG 5GUYrqPw5SJpidSqXLltfW48Cs/YBq/VIll5IwMSJ3nzaB09ORp1SQpwkdRJ0YKp GzushGYLUD/AIqcIRBrygECs4n2Zn0z9hVQNQzCKppWY5CwWcrWRPFzs26AOVyWV QUqF4F+ZOyedqR2KgmApnI0CbhLmd4PrmPEofsz7DzXyYvyRDPFNNAt6wDqepomu ilyf99Es45AXpoExXbWaEJH4Ky3ZwpHY7y0xnRB3Z/NJwab48IbiWK449/3anqfy cosE1/XKMhQN9WYg27ZrlTD73QfvwkiJXb/WboWpZ6DZuQAsDMsmgnZwY23CfnYq 3sXIHp4S9pbHjDtagfuguu3hwFm9VBMMSjp63sS/6rPn/G/5sjiTjcnqkER3GcKQ Gq9jDvbM8GII/A5VNmv+3WcwiJ/EkXcFRaoQTNObxzFC7Y4bQNP8BLpwiIT75B1p 3EGftQsUUL5bd/CBl/RIQIlUKzXon1HDWECOlI9BKbTq+x1aKf80stY+2/iIVDya KDm6bnpN4mnHL6jGInTv8HjnC+bDCrCwSa6Whp2/RsGPKp1sTPYiLcF5yUxTQolw 8pt5iX8/4H83Y4nd5D3smbHrk3jQwaxpczMzae1+GhkI+5cFXUw= =ms+F -----END PGP SIGNATURE----- --kjRVdBBIf432Ei30g36Vtbl4jG9jMOVkp-- From nobody Mon Oct 1 05:45:53 2018 Return-Path: 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 7B77B130E66 for ; Mon, 1 Oct 2018 05:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 K6ynkZXKu1ia for ; Mon, 1 Oct 2018 05:45:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75347130E60 for ; Mon, 1 Oct 2018 05:45:49 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:61724 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g6xa8-0000sO-N7; Mon, 01 Oct 2018 05:45:49 -0700 To: Julian Reschke , xml2rfc-dev@ietf.org References: <58b7afb2-53a4-8ee0-ba99-6d4a90c561af@gmx.de> From: Henrik Levkowetz Message-ID: <761f6c13-8964-ab27-2899-3d3ca1d7ab97@levkowetz.com> Date: Mon, 1 Oct 2018 14:45:41 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <58b7afb2-53a4-8ee0-ba99-6d4a90c561af@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4wW2gLsSoVUECo0uUrha2wixckmPO55NK" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #40: Schema Issue, RFC 7991, New Section 2.54.2 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 12:45:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4wW2gLsSoVUECo0uUrha2wixckmPO55NK Content-Type: multipart/mixed; boundary="pKPrhk6eLq3hvFqN0T39tMUmxJh7jiRhk"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , xml2rfc-dev@ietf.org Message-ID: <761f6c13-8964-ab27-2899-3d3ca1d7ab97@levkowetz.com> Subject: Re: [xml2rfc-dev] RFC 7991 issue #40: Schema Issue, RFC 7991, New Section 2.54.2 References: <58b7afb2-53a4-8ee0-ba99-6d4a90c561af@gmx.de> In-Reply-To: <58b7afb2-53a4-8ee0-ba99-6d4a90c561af@gmx.de> --pKPrhk6eLq3hvFqN0T39tMUmxJh7jiRhk Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-10-01 14:11, Julian Reschke wrote: > On 10/1/2018 1:36 PM, henrik@levkowetz.com wrote: >> This captures an issue noted during implementation, also described in >> https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation#= section-3.1.5 >>=20 >> --- >> New Section 2.54.2 >>=20 >> The version 3 schema deprecates the previously available 'align' >> attribute for the tables, and the V2 to V3 converter will remove t= his >> attributes if used. This makes a previous feature that was apprec= iated >> by some authors unavailable. In the text formatter, the effect is= >> simply to make all tables left-aligned, which may not be the most >> readable and polished output, but for the HTML formatter it also >> potentially removes the option of letting text flow around smaller= >> tables in a controlled way. >>=20 >> Recommendation: Make the 'align' attribute for tables available a= gain. >>=20 >> Implementation: Implemented but inactive in the current version o= f >> xml2rfc. The current text formatter code already= has >> support for the 'align' attribute for these eleme= nts; >> but since the schema does not permit the attribut= e for >> , the code is never invoked. >> --- >> ... >=20 > +1, but duplicates #9. Ack. Henrik --pKPrhk6eLq3hvFqN0T39tMUmxJh7jiRhk-- --4wW2gLsSoVUECo0uUrha2wixckmPO55NK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAluyFvUACgkQTptXS4+7 Fxq6aBAAk+vkxImC7o/7PSXVYthBRnpeEQulZ4jFAgLHp8Km5mKf5Pm1ddsqrH1+ WCu+YHmSZClAMmoXUYLfEvSKuXtWYfuGX7WPGI1+Qq/0Kt3p3gwOvDxQFW0/VtMe /SeRAPVGUsGqSYOP2JGTpqFOxbBWqzddEU4hIeGP220yRRHBw6+cy3otyDJQ/8M0 o2qRs+oa4QuvNo4uYAPFlLSlrBoqHvFtJZNLfShz4i28znqBjMMX62ZoVZpQem2O R9XcQgWT0xw//e4SN9D353Lfn/QLnYQsaFyRsQLXoQWDSe6KTWzhJTFymM0vU2ct jXRmJHvMQ5pyxpYzteO+jjmTmSGPn3LCnC/fiMnHLH1J6I5oJwyQano28ICtk5FG hcUi2Mr6uN1RvkXcSgG/tJPVZRLqyQrluz3hHpac4cTvv7eK7fW0CYCxSfvjZx5r BivevYaINEEqa4wCLHJ7Q6/1RpIMp/RcB473+ORRxGnSaaBqH5btP/fnUE40UiYk 32MLYcKwvsD4YzwN/xtv0VnlNRJbgBHZAOd3g/oncr8jpsFFaSa5ODQ5nidPs/H0 dRLz1mAmSPW4ojJ/f69qYZAeKTCFID8ikuan+cz5GamqnRZUdkzuBnHzy471JRlC MGg4znGZWkkAV+tqJC3R4PI94h6U7mXm4eXSL+46o56q6F4CrQA= =bq6D -----END PGP SIGNATURE----- --4wW2gLsSoVUECo0uUrha2wixckmPO55NK-- From nobody Mon Oct 1 06:05:16 2018 Return-Path: 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 1CD3E130E68 for ; Mon, 1 Oct 2018 06:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 dUC9qKSQf_iJ for ; Mon, 1 Oct 2018 06:04:56 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7A08130E69 for ; Mon, 1 Oct 2018 06:04:55 -0700 (PDT) Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MWkZL-1gDMZf0OPD-00Xtat; Mon, 01 Oct 2018 15:04:40 +0200 Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MWkZL-1gDMZf0OPD-00Xtat; Mon, 01 Oct 2018 15:04:40 +0200 To: Henrik Levkowetz , xml2rfc-dev@ietf.org References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> From: Julian Reschke Message-ID: <6af53098-ed88-52b0-a1c4-27dad547ee8c@gmx.de> Date: Mon, 1 Oct 2018 15:04:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:bCz3LKhVN/QVg2HwdC9i6zGtsBDWmo0HFhccSG9NgtZmPQH4BBV vqgLXnIRFZXLZd4Kof7WBwKFD/xSluCxbRrY9YoHnrHwoq536E5D36dSaBJpVtbCQeLvQI5 tffsUvfMtq81GLZ7TfBtU3X4nPDfwlTQZz0BqZAXiOmMYVOPDbYmhiC2lVzCxri4Rn+RcNq oskwtFL3v+KC8WsSCQtoQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:HCcsTQA6ZaY=:bAPXZZL6Uf1exu0Hhj+odO r4gYF5vs7gODXDtQlf6+bVgBH8f7OjcvpbytCe76EDUZVzjK8BLozCeIDymfO6qP2k2BwdB7Y 0V+bMxFYh41vpdgV7YrRhUSLPUFclIlIszcP7sxnXHA1EJ7KhEek8FJXXsUJ3FkJ7hMwumUpo d+D0rFGc2Zrd2vfhWzfzG1rg3Re5RGyx00gN2iv8fGk0BzTykn67dJ5Psy81bXxJRkI08T5Xg /S8EkAgBa0jByAiTNekME+WV1xW4n7gZU+rzAKn98/LMHOuqkaO1L7Uqhny9YU8ccgQ5Ihee0 mCCf2aGjr1q6telvu0XSTzCJTwNfJdy/zn7CbXXWeDJnZ75M/iqBQ3s3u6bdRCPrP9AMoDeFq PE+GLlMRwQPGgw8uXOjYFuEB/uB7RxH/wbI5it44/TiB+5c+r1YJv98f0tu0FXksU4dAug9Y/ XTIjslDAkRy1xZjFygvGQkjYQ6zNfiSdBZlR/2lTLwhlXtwbFdXNeDdoF+OuPm5ddJZrZe120 LbV1ASOGdNA8MOQHOvvV81QwLE7aQocJo6+79ubOzu9WAzHxxjVuzI4sOIEt6SuDodwtqOa+x XffGD/i1Oqy2u/YJpiVjXp80IkYRTb1TIPoWW1isQusVr6vuvQSyVdCULLikhTlpeQBUXIdBa rVXLLpbxTHueegjGJFBHlc39uFSLiSS1uWYeEAreQE1Y0mfJompHHaSfqRHxR8Yxz6pq4syEU F2WFn6FqKTrogSCiWeTA+yY7PRliOkNkmdPHvtXj0biI+jy2ZYGRMi+iQxQWhIE6DkNgEsWFC MwdqaNS9XoVgJicxj2QjOABlWOqjewBfERuZ0v/1iDd456OQng= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 13:05:12 -0000 On 10/1/2018 2:37 PM, Henrik Levkowetz wrote: > Hi Julian, > > On 2018-10-01 14:07, Julian Reschke wrote: >> On 10/1/2018 1:31 PM, henrik@levkowetz.com wrote: >>> 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,
    >>> >>> A number of elements permits a mixed content model (see Section "Mixed >>> Content Model"):
  • ,
    ,
    ,
    • , and . However, >>> when using the simpler of the two content schemas, two of them ( and >>> ) permit inline line breaks through the use of
    elements; the >>> others do not. This seems terribly arbitrary. >>> >>> Recommendation: Remove the
    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
    as a >>> newline in all inline contexts. >>> --- >> >> As far as I recall, we ended up with the limited use of
    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. > > 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 >
    by Miek, when he started adapting his pandoc2rfc tool to use the v3 > vocabulary. > > I would say that even if
    in running text would rarely be needed, the > confusion Miek ran into is unnecessary, and limiting
    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. > ... 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 nobody Mon Oct 1 06:05:55 2018 Return-Path: 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 785C7130E69 for ; Mon, 1 Oct 2018 06:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 0LscuC3HmOPu for ; Mon, 1 Oct 2018 06:05:50 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2B8E130E67 for ; Mon, 1 Oct 2018 06:05:49 -0700 (PDT) Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MeLKt-1gNEX10rhX-00QD4n; Mon, 01 Oct 2018 15:05:36 +0200 Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MeLKt-1gNEX10rhX-00QD4n; Mon, 01 Oct 2018 15:05:36 +0200 To: Henrik Levkowetz , xml2rfc-dev@ietf.org References: From: Julian Reschke Message-ID: Date: Mon, 1 Oct 2018 15:05:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:d/gAS7YRArkx2je1extMEQNvlligeOlf8EHd1eLXrNwHxyJVuEi UfFwT1BSla+NRS0q9ToCh4VPeXCPsF13z/E4BdkT+sI30v1PJ/iXoRcQfgEW0usali0nbar /jwNeKcxmnX5UtWIFS82JZtgByU8uEMyPlsbgbMobAKS6Dl72KpSRKkB5LRvHy86htWly3o li2Y9URxMQd3fHSvNQ69g== X-UI-Out-Filterresults: notjunk:1;V01:K0:hcxfBsFCfKI=:aR4VCfOuVoP+x3lUGkJf8Z Y1ZIpbD039F20TptXkaH+tXIFkmwe6HSiw/vtkjhdS5LS2NreWcO7JgVTon1g0fSpq7CH2pg4 7vltMKXfMpmlsuya0ZfdG2/oLY55scDC4eXR2ViwyJ5fissFYiUZEmB8RIPwVNvgBjIbCs42o dQKoLw0si0YUwBvSANfHDyCP7/kPUVecsFslxSh1lyh668HvG6QyZrVI4LJ1CdWZvBi3d50Ni r2eHYXCDK67+D2Zy0v8k2fMkduw1L7MUr/ijWYFlzKntFw9oOrnBC9NVPs1LQqmSKrFeFSy3O QqYgNx4SlBiQYhd9JR+0epr9prCAS1o6vD8SlY7mqtDSUbMM/2gZoKG+baSTtrcZsti77HKoP 6c0bATAfzWh7bZXOTJV6nmC9dEk8qQgNYrBA36Xr/jVj+66YetfNbiQZzA36c7BgwmSZDRqFc QpV97TAwLXu4GS1kVsxOGgCLR6oRNoNko7FTDH+THQra6hlXe1DevsFyPlK96HjW3A3dg8D9x EBtlOsHvsciPXoXfBez0rDYoEtQmL5m6MPkr/T/rxoMP7A3Nj3R1tO54yRtWVfEEHBMDMpwTT PUH/+HtVg3drrqRFP8/7VCsAeOMiI5YzCD/czjpg+dOVZzgZYQtefe0fSPwxO5YIUKI0X/xgQ M/KY/lhN//bO4b1TBuvQzbweT1EF2WqceH9Fn9xFCBsgQrHLMcVrTGB+Vw/ETXXB9GQjvKaN5 6mc7iRUAIWXONLB7jWzgJ5iDlkxQlC4rL+7Tc055Ud5La0/kLGf8DcQghKBFIvls/KdI/A57N ccqWL7FnFL6V6pioDiXQkI7BGQuqFQ0lYS+yEVnRdwL8Y+PKCo= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, New Section 2.20.4, "indent" Attribute 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 13:05:53 -0000 On 10/1/2018 2:39 PM, Henrik Levkowetz wrote: > Hi Julian, > > On 2018-10-01 14:09, Julian Reschke wrote: >> On 10/1/2018 1:36 PM, henrik@levkowetz.com wrote: >>> This captures an issue noted during implementation, also described in >>> https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation#section-3.1.4 >>> >>> --- >>> New Section 2.20.4, "indent" Attribute >>> >>> The deprecation of the "hangIndent" attribute on leaves no >>> opportunity to control the size of the hanging indent. In some >>> definition lists, it is desirable to have a wide indentation, in order >>> to clearly show the terms, in other cases it is more important to allow >>> for a larger text volume than the width of the terms would allow. >>> >>> Recommendation: Add an "indent" attribute on
    to control the size >>> of the hanging indent. >>> >>> Implementation: The current version of xml2rfc does not support the >>> attribute, but has all the underlying functions needed >>> to apply such an attribute. Internally, an indentation >>> is calculated based on length of the
    text and the >>> settings of some of the other attributes. >>> --- >>> ... >> >> I agree that this would be useful - however we'll need to define it in a >> way that works well with non-monospaced fonts. > > Agreed. > > What about specifying indentation as a number that would indicate characters > in monospaced output, and en-space otherwise? Works for me. Best regards, Julian From nobody Mon Oct 1 06:07:17 2018 Return-Path: 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 BFEA1130E61 for ; Mon, 1 Oct 2018 06:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Kws1sUbUzK-p for ; Mon, 1 Oct 2018 06:07:14 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EEBD130E02 for ; Mon, 1 Oct 2018 06:07:13 -0700 (PDT) Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Ldttv-1fOrS90e4B-00j0V4; Mon, 01 Oct 2018 15:07:02 +0200 Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Ldttv-1fOrS90e4B-00j0V4; Mon, 01 Oct 2018 15:07:02 +0200 To: Henrik Levkowetz , XML Developer List References: <66f634b8-1789-cb13-02cc-08dcbdeda373@levkowetz.com> From: Julian Reschke Message-ID: Date: Mon, 1 Oct 2018 15:07:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <66f634b8-1789-cb13-02cc-08dcbdeda373@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:/VBgNq7rMUv8W04dmEPc7upLhIjRcb1uyZmeHgs92l2xDFKikEj Q0/YJZvZRfkea8IwRD7TZ4RSRBvIdLSFXON62lXLERm2fGYbDJ1C5jvUn5aZhk2bGFOVMsh N0o69RkG7/fzZBbBaWlVLDl9zMvSZLSHsyzHbo2P6weZRR44s0OJQx665jhA/BZBHo72obe INvip/EZJCWD0EMN68ghQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:7UBS+zoSfQg=:muZCRQOCud2YbZfq3LPi39 YA3O1u7Y0z/ugX5Uqh3axHrkEpsVvaz0H8KwzeBcgweO4UDN1ENBAvfrqLAa/1ZMgqEMHT7x/ 9Vq+jztzrlNOq8CI1E2UmvEq9uBH9rZvAjpZ0HFqgiLB7LYFPm5CT0/zk64JaleWedglPvF+m Wwkt4wX4hr/It0eg2c+l7EMPBzuNawGmbOSfmT5jSUDbxZ5sg/t3G7DqDgpE3Jt2kx0F8juHd uYHkMlgmOl0qwZC2NPTdTKdntQUqjEYVEG5A8vY6WocHcR2UxAJmqFFoSOWoTyy9MAPZ7zG4n WKqme5SeqJAN0J1/phI3GWwx7O60i2J4oSClnOfSrnU2Ge6MlzU9P68HbWel/ZtYBscgu3hEw orXo0g6aAQV1oZoiVWCswHDXm07LhV8lxAOwwpthcD/GS+Jq+QpfaFa7xIigYYLiIhaeh83Ci OU3fT8q8RhLWvMVWs31kz8DrfkCQhv4ttYtotpZ4XtLx0wPpcvN8gP8sZFgbORuCLPR1lY6Or JonokaQyiL3neN/6doOYOSwOcs7ag1M3WlxuIkNawhUF/2gjDMfEUDl6VPboS+cB5Ff1uvdEa Vs5v4EEGi/hjE4Qkt9+5U/IalA5ZmytuPO/w8UNknMC8JrS0gOMEZVY39HCZXo/puxMhUQ8nh COmvWdS5eRWBfzP/geGJpplqVksSjpjrnkIsSCcl+y5EpfIYH8ooyAQFm+W77qTlH4+1kk/xf maBPynUzC9alJeEg6As0iR8vxz9EGieFzN1W9kQDxn2ZSnhW7ZK1Nc4YwKy8KdPUCmN/5c1Dl GO+i6AkAlDznDrjuNjR+5n4MdmgyPffc08PHV1KDCzcCuR4bNA= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #36: Schema Issue, RFC 7991, In Section 2.5.5, "name" Attribute 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 13:07:16 -0000 On 10/1/2018 2:45 PM, Henrik Levkowetz wrote: > Hi Julian, > > On 2018-10-01 14:10, Julian Reschke wrote: >> On 10/1/2018 1:36 PM, Henrik Levkowetz wrote: >>> ... >>> >>> "A filename suitable for the contents (such as for extraction to a >>> local file)." >>> >>> Given the existing use of "name" on , this attribute name >>> has a semantic dissonance. >>> >>> Recommendation: Deprecate "name" for use on and , >>> and instead use "file", which for will be >>> explicitly rendered, as established as best current >>> practice for YANG modules (see for instance RFC 6087 >>> [RFC6087]) >>> >>> Implementation: The current version of xml2rfc uses "name". >>> --- >>> ... >> >> I would avoid making changes that aren't strictly necessary, thus keep >> the name as-is. > > I think now, before actual use of v3 starts in earnest is the only chance > we have to make changes like this. So if the change makes sense, let's > do it, rather than live forever with something which is (even if only > slightly) less appropriate. Well, @name has been around for over a decade, it's not a V3 thing. If this was new, I'd be more likely to agree. >> I also disagree with coupling the sourcecode tagging to the presence of >> a (file)name. This violates the principle of least surprise. There are >> good reasons for providing names, such as for automatic extraction >> during build time (for instance for running check scripts), which have >> absolutely nothing to do with the presentation in text or other formats. > > On the coupling with sourcecode tagging, it was not my intention here > to argue for that. FWIW, in the next release of xml2rfc the insertion > of will be controlled by an attribute "markers", with the > default being "false". Expansion of "file" or "name" would occur only > for markers="true". > > The "markers" attribute is of course also something we'll have to decide > on, quite apart from this issue's proposed change of "name" to "file". Ok, then I misread that point. Best regards, Julian From nobody Mon Oct 1 06:27:17 2018 Return-Path: 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 C0C66130DFA for ; Mon, 1 Oct 2018 06:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ajackaDyPP-o for ; Mon, 1 Oct 2018 06:27:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CFE5130DDC for ; Mon, 1 Oct 2018 06:27:14 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:61893 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g6yED-0002RH-Fb; Mon, 01 Oct 2018 06:27:13 -0700 To: Julian Reschke , XML Developer List References: <66f634b8-1789-cb13-02cc-08dcbdeda373@levkowetz.com> From: Henrik Levkowetz Message-ID: <3559f29f-38b5-4af3-f92d-d6c2a24a073f@levkowetz.com> Date: Mon, 1 Oct 2018 15:27:04 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jEmR3RIQ9fTeWKLwdORV27sLJ89pE4G4l" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #36: Schema Issue, RFC 7991, In Section 2.5.5, "name" Attribute 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 13:27:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jEmR3RIQ9fTeWKLwdORV27sLJ89pE4G4l Content-Type: multipart/mixed; boundary="o5HsAKo79t6R27RfVdTIrdcvOKjchsBsq"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , XML Developer List Message-ID: <3559f29f-38b5-4af3-f92d-d6c2a24a073f@levkowetz.com> Subject: Re: [xml2rfc-dev] RFC 7991 issue #36: Schema Issue, RFC 7991, In Section 2.5.5, "name" Attribute References: <66f634b8-1789-cb13-02cc-08dcbdeda373@levkowetz.com> In-Reply-To: --o5HsAKo79t6R27RfVdTIrdcvOKjchsBsq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Julian, On 2018-10-01 15:07, Julian Reschke wrote: > On 10/1/2018 2:45 PM, Henrik Levkowetz wrote: >> Hi Julian, >>=20 >> On 2018-10-01 14:10, Julian Reschke wrote: >>> On 10/1/2018 1:36 PM, Henrik Levkowetz wrote: >>>> ... >>>> >>>> "A filename suitable for the contents (such as for extractio= n to a >>>> local file)." >>>> >>>> Given the existing use of "name" on , this attribut= e name >>>> has a semantic dissonance. >>>> >>>> Recommendation: Deprecate "name" for use on and , >>>> and instead use "file", which for = will be >>>> explicitly rendered, as established as best cu= rrent >>>> practice for YANG modules (see for instance RF= C 6087 >>>> [RFC6087]) >>>> >>>> Implementation: The current version of xml2rfc uses "name". >>>> --- >>>> ... >>> >>> I would avoid making changes that aren't strictly necessary, thus kee= p >>> the name as-is. >>=20 >> I think now, before actual use of v3 starts in earnest is the only cha= nce >> we have to make changes like this. So if the change makes sense, let'= s >> do it, rather than live forever with something which is (even if only >> slightly) less appropriate. >=20 > Well, @name has been around for over a decade, it's not a V3 thing. If = > this was new, I'd be more likely to agree. Umm? For the specific purpose of specifying the name of a file for extraction of artwork or sourcecode? This is the specific case I'm thinking of here. Best, Henrik --o5HsAKo79t6R27RfVdTIrdcvOKjchsBsq-- --jEmR3RIQ9fTeWKLwdORV27sLJ89pE4G4l Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAluyIKkACgkQTptXS4+7 FxpcvRAAozJsEUXB/r/CDe/EfGTBvs0HOR1LzqOPRmPLtQAIuqwxT/4COqwAnBRJ 6xanYj0wFwEUTiFFHq5sf7tzWzBupPLJ6eaaSG2LanqpwpiobmGcMIrF1d+abMty f/DJCH0ahSJSDFVxteguey+zG/NglSZfyxjYFGjGa9uj90blVZDqpm7n132RM8Tu 7bOt3nGt7vc0Al3pzjO6HYrUcevfiMxjI2OGn29+4sX88KdJ13fO75i3fzSrWYp0 d6GWNq8ODBoe9lh8T+aa/+kev3sWK3K7B5h+1H2B1oEmrZC8moqLHxWFWCDKdVrK wc51QkoRatD5zhNeI06mCzOquX9aH+ZSAj0pnCsopZhtEpweNwk+ccxTUYUgYUIt AHfAxrtdoeLCj+Coew2fSuPfGQG554Pfsw/oAkNpzbso2z/Zel8QC7tljhcXlqib Rqp4E/hdBx9TwHiudbwUjiIVYHa3dWJwy3ZdWgzdoyIIsggQV9/2+4372d+/khtj DTq4pgwSS1Wh3aBNbC0hpZQDPu9ZRRyiSr3FO1Uq2Q/lWRioznt8635aoGID6HBT Z64kjj0328pqCEcu40uBQODUeB5MiBOQxTaCzyyAspeUI9QFz9pUqw4pzzmBTIdB OYNWnL4E5Bqum9+PUyuTRRS0p1i5jK3BZvrDI6VLzkBkfR+TW3E= =KklW -----END PGP SIGNATURE----- --jEmR3RIQ9fTeWKLwdORV27sLJ89pE4G4l-- From nobody Mon Oct 1 07:07:29 2018 Return-Path: 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 31DC5130E96 for ; Mon, 1 Oct 2018 07:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 o4UBDh3Jl3YI for ; Mon, 1 Oct 2018 07:07:15 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B9CF130E82 for ; Mon, 1 Oct 2018 07:07:15 -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; Mon, 1 Oct 2018 07:07:13 -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; Mon, 1 Oct 2018 07:07:13 -0700 From: Paul Hoffman To: "xml2rfc-dev@ietf.org" Thread-Topic: Specification issues found during implementation of RFC7991 etc. Thread-Index: AQHUWZAMdA7sOmIfhkKxh/3NeU7gcQ== Date: Mon, 1 Oct 2018 14:07:12 +0000 Message-ID: <8400AE8F-BA51-4F6C-A642-FD05C670C492@icann.org> 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=_1241F71A-5820-4836-975A-E18B6D4D5C5E"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [xml2rfc-dev] Specification issues found during implementation of RFC7991 etc. 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 14:07:27 -0000 --Apple-Mail=_1241F71A-5820-4836-975A-E18B6D4D5C5E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for getting these threads going, Henrik! To everyone: as document author, I would really appreciate getting input = from at least a handful of people on every issue. Clearly, Julian and I = have opinions on most of the topics, but I suspect that many of you = might as well. Please feel free to speak early and often on the issues = you see here. FWIW, Henrik has agreed to issue these proposed changes in batches each = week. There are a lot of them. We don't want to burn you out, and we = really do want this to be a community consultation. To help people keep track of the changes, I'll issue a new draft with = what I think is the consensus on the issues every few weeks. When I do, = I'll mark the GitHub issue as closed, but that doesn't mean it is cannot = be opened again as the document progresses. --Paul Hoffman --Apple-Mail=_1241F71A-5820-4836-975A-E18B6D4D5C5E Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAwMTE0MDcxMlowIwYJKoZIhvcNAQkEMRYEFPGjUCAm5gFfEA3Fzp53oEetbv+xMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQCIBZdTaz16uVDIYkePhAGbCO+y2EFJyQscbMrvjYTQ1wdQIf/1+/iM87ygzDWYWHQ/QNkC 6oO4zw3aLSmzhTYqqWhykMJYiPE2H2YcSHsLboSRaVplWClwRBd8kcnCn3XQ99vq056MNvir/L0r A1GHyhRDK58Qbp3kScMk2G44KhfrufqxGTsyfOuf9iHHx7F4zMj1f4oZpbpbih19sM2T81VPHxLh TzBtD9re/hlBcZMDG1QbPO31ojj5iDmcsOMuUN1ZFnLGVR4pq8MnwJE4sB8nJ6iOAuIOUSzv3gqz NHx0280R+JzikoE7HnQMwsba1pT2Ujo0NpunCyFBxRGWAAAAAAAA --Apple-Mail=_1241F71A-5820-4836-975A-E18B6D4D5C5E-- From nobody Mon Oct 1 07:10:42 2018 Return-Path: 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 D1672130DFA for ; Mon, 1 Oct 2018 07:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 tHu26Dbu3yoD for ; Mon, 1 Oct 2018 07:10:38 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FBF4130DDC for ; Mon, 1 Oct 2018 07:10:38 -0700 (PDT) Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lrw2c-1fjUuJ3GaE-013dEh; Mon, 01 Oct 2018 16:10:22 +0200 Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lrw2c-1fjUuJ3GaE-013dEh; Mon, 01 Oct 2018 16:10:22 +0200 To: Henrik Levkowetz , XML Developer List References: <66f634b8-1789-cb13-02cc-08dcbdeda373@levkowetz.com> <3559f29f-38b5-4af3-f92d-d6c2a24a073f@levkowetz.com> From: Julian Reschke Message-ID: <377cbc50-6c2f-9a62-872d-f578116693ed@gmx.de> Date: Mon, 1 Oct 2018 16:10:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <3559f29f-38b5-4af3-f92d-d6c2a24a073f@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:93gnBoNXfg2O01MG0XdtmFFGwXEcGROVAmOGzqBMjHo/+C1CDkO xK6hmOPiheHrD6BCiyAGg1V6OUnYYGINxhezuv8xzGaZPioVys4WRieHukDmbzYvYw5VAac vr962icriYURogY4q+QpN7bCx4j/hHPZgPwkBKZlmNeona89z4NslyLW3mDPLoih99qI5QS i3j7XMDTnrh+ex88oH6/Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:GzoB3WcCjbw=:wTpDzva3UiPHBpSAjH9V2d atPXT8c2VpnD4RS/N3yRjVLVVNdzdvcenKDcxmWN/Na2+3DD7WmL1S8zeDX5ajSmvK8zXYn1b oglfHVJMPRWKDE+Vi030KbHIn0riRtcQEM91i/dLwoEv+UTHWhzoDQFptSXgAWa3+oC0D2+Zj Qr3paw+G/Rlcy4mXraivDwPL5jBbGMLlivHzdB9r6JV+1CjuxzlsIsAOtU3B8Eb4npTWX7770 PitR1AV/ltgzdOhOeAr3X5Qz03Qcaz1wBknw4o+6MsuHRxtkdNG6hhMRFRTVfBgIbHI0FaGUX FVtiYow3/3PL6p+ISrhg2lfcB+DIugCX9Lav6WGG9HwE3/Emd64RMPFBM/3tJBgsax+3IkXWd 11k3btiS8HSJTjbgXuvD9uhm8tSttQstY1MSU7D28EFMSKpD9DGBdnOIMac4zPKjaD55dcO6d xlbTLxOWMMHQDB+9Nr3RczXeViJE/6pYqeOeVOXfXMNSzUyJkHUaBYOx2c3XH5Kl/V69ZtZY6 v3+B/1eaGjNvnJqGEQ2xpYZ4+Xg+EdzmHcB0OyY/prXhPd1n61pdfJISVThwJTqZThL2tQr/2 tPnae+b3uiwzt9qVR04fy5Mlo4Gwm+ZB1etKemiiRtFvFfFE9arnXJvLriUn4DYzCY2WV3JS+ JkY6ZA05oPBWkLsPiTQcxMt3hEsivrLTO2vrwVjWhKlnJEWxC3/eekvD5hkicoFa4LQ9XOged rZ9nclsEoy+mVsGZ2hbSEk0l3LYA6o7ebAOud9FBBatr1OJaZ59+zslQAjySGAGaf79XgvJCQ pyv19Jkv94h0td/sJbCBmfNQDyDYRSUbvO1uTy/OC8Qu7YFsGk= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #36: Schema Issue, RFC 7991, In Section 2.5.5, "name" Attribute 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 14:10:41 -0000 On 10/1/2018 3:27 PM, Henrik Levkowetz wrote: > Hi Julian, > > On 2018-10-01 15:07, Julian Reschke wrote: >> On 10/1/2018 2:45 PM, Henrik Levkowetz wrote: >>> Hi Julian, >>> >>> On 2018-10-01 14:10, Julian Reschke wrote: >>>> On 10/1/2018 1:36 PM, Henrik Levkowetz wrote: >>>>> ... >>>>> >>>>> "A filename suitable for the contents (such as for extraction to a >>>>> local file)." >>>>> >>>>> Given the existing use of "name" on , this attribute name >>>>> has a semantic dissonance. >>>>> >>>>> Recommendation: Deprecate "name" for use on and , >>>>> and instead use "file", which for will be >>>>> explicitly rendered, as established as best current >>>>> practice for YANG modules (see for instance RFC 6087 >>>>> [RFC6087]) >>>>> >>>>> Implementation: The current version of xml2rfc uses "name". >>>>> --- >>>>> ... >>>> >>>> I would avoid making changes that aren't strictly necessary, thus keep >>>> the name as-is. >>> >>> I think now, before actual use of v3 starts in earnest is the only chance >>> we have to make changes like this. So if the change makes sense, let's >>> do it, rather than live forever with something which is (even if only >>> slightly) less appropriate. >> >> Well, @name has been around for over a decade, it's not a V3 thing. If >> this was new, I'd be more likely to agree. > > Umm? For the specific purpose of specifying the name of a file for > extraction of artwork or sourcecode? This is the specific case I'm > thinking of here. Yes. "A filename suitable for the contents (such as for extraction to a local file). This attribute generally isn't used for document generation, but it can be helpful for other kinds of tools (such as automated syntax checkers, which work by extracting the source code)." -- ...and, previously...: "Finally, the "artwork" element has two optional attributes: "name" and "type". The former is used to suggest a filename to use when storing the content of the "artwork" element, whilst the latter contains a suggestive data-typing for the content." -- From nobody Mon Oct 1 07:23:45 2018 Return-Path: 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 628B0130DDC for ; Mon, 1 Oct 2018 07:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 MOeS04GN0ww3 for ; Mon, 1 Oct 2018 07:23:41 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53883130DC8 for ; Mon, 1 Oct 2018 07:23:41 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:62553 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g6z6q-0001HI-5i; Mon, 01 Oct 2018 07:23:40 -0700 To: Julian Reschke , XML Developer List References: <66f634b8-1789-cb13-02cc-08dcbdeda373@levkowetz.com> <3559f29f-38b5-4af3-f92d-d6c2a24a073f@levkowetz.com> <377cbc50-6c2f-9a62-872d-f578116693ed@gmx.de> From: Henrik Levkowetz Message-ID: Date: Mon, 1 Oct 2018 16:23:32 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <377cbc50-6c2f-9a62-872d-f578116693ed@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TRcdLgao1HnQMdQjIGiPtROJBQIhRfAJe" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #36: Schema Issue, RFC 7991, In Section 2.5.5, "name" Attribute 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 14:23:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TRcdLgao1HnQMdQjIGiPtROJBQIhRfAJe Content-Type: multipart/mixed; boundary="CGfLPG9Og6BNJJeBpjcPTk6NA8les2tR6"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , XML Developer List Message-ID: Subject: Re: [xml2rfc-dev] RFC 7991 issue #36: Schema Issue, RFC 7991, In Section 2.5.5, "name" Attribute References: <66f634b8-1789-cb13-02cc-08dcbdeda373@levkowetz.com> <3559f29f-38b5-4af3-f92d-d6c2a24a073f@levkowetz.com> <377cbc50-6c2f-9a62-872d-f578116693ed@gmx.de> In-Reply-To: <377cbc50-6c2f-9a62-872d-f578116693ed@gmx.de> --CGfLPG9Og6BNJJeBpjcPTk6NA8les2tR6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Julian, On 2018-10-01 16:10, Julian Reschke wrote: > On 10/1/2018 3:27 PM, Henrik Levkowetz wrote: >> Hi Julian, >>=20 >> On 2018-10-01 15:07, Julian Reschke wrote: >>> On 10/1/2018 2:45 PM, Henrik Levkowetz wrote: >>>> Hi Julian, >>>> >>>> On 2018-10-01 14:10, Julian Reschke wrote: >>>>> On 10/1/2018 1:36 PM, Henrik Levkowetz wrote: >>>>>> ... >>>>>> >>>>>> "A filename suitable for the contents (such as for extrac= tion to a >>>>>> local file)." >>>>>> >>>>>> Given the existing use of "name" on , this attri= bute name >>>>>> has a semantic dissonance. >>>>>> >>>>>> Recommendation: Deprecate "name" for use on and <= sourcecode>, >>>>>> and instead use "file", which for will be >>>>>> explicitly rendered, as established as best= current >>>>>> practice for YANG modules (see for instance= RFC 6087 >>>>>> [RFC6087]) >>>>>> >>>>>> Implementation: The current version of xml2rfc uses "name".= >>>>>> --- >>>>>> ... >>>>> >>>>> I would avoid making changes that aren't strictly necessary, thus k= eep >>>>> the name as-is. >>>> >>>> I think now, before actual use of v3 starts in earnest is the only c= hance >>>> we have to make changes like this. So if the change makes sense, le= t's >>>> do it, rather than live forever with something which is (even if onl= y >>>> slightly) less appropriate. >>> >>> Well, @name has been around for over a decade, it's not a V3 thing. I= f >>> this was new, I'd be more likely to agree. >>=20 >> Umm? For the specific purpose of specifying the name of a file for >> extraction of artwork or sourcecode? This is the specific case I'm >> thinking of here. >=20 > Yes. >=20 > "A filename suitable for the contents (such as for extraction to a loca= l=20 > file). >=20 > This attribute generally isn't used for document generation, but it can= =20 > be helpful for other kinds of tools (such as automated syntax checkers,= =20 > which work by extracting the source code)." --=20 > >=20 > ...and, previously...: >=20 > "Finally, the "artwork" element has two optional attributes: "name" and= =20 > "type". The former is used to suggest a filename to use when storing th= e=20 > content of the "artwork" element, whilst the latter contains a=20 > suggestive data-typing for the content." -- > Ah! Ok. I've closed the issue. Best regards, Henrik --CGfLPG9Og6BNJJeBpjcPTk6NA8les2tR6-- --TRcdLgao1HnQMdQjIGiPtROJBQIhRfAJe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAluyLeQACgkQTptXS4+7 FxpFIg/+IsR9qQTRz7m7EVcoxPehz71IrN3Z7Hyxf2w3PwpBr6NLlxFlbupSFwhq seWnvZiNdT7lHZ28pP5ixsxf4Om3t701yqwiWY7HrPYbvULNjEyjUj+OpwxFNWeR n8opeDmxe1ltVClnpIK6U1pHCnQxX6ICXCPben6gVpEzy3Cat5LArs/gIndLO9gq KHjkjummoenQ3KJSJHFSWVDSxgKHyidZ9EJ4eyQcCkPYTfnMvlHZtoAtp4cUS/iM 1nMhj8hqkK4SS/zaKPRaQ4EHVyzRW9rt/ytULsBAQ9B8UnpRpAaY/ewh3Mf6Ef5+ +B1aB0zYHdqVaN5yaysjcDiDPp2Bu2BYVvFPIq2RHdG4hrLXNb8Go0VwPzsKSl1Z zU9V/neFtERBmbrGBNd6MQslgh5SgXkYLGpu63WZjmJ1+IAAPldPGVKmSbtiA2Pf YjeKokLzURzDHuwG4dvFJikT3KBQi4Kt1+duFjvqbi13X1xATHEmsXKmnDic284E qmcifDhhQzoAXNGQp7gGpPUfxitLToSOH6hngeyb+eoB1xdZQIPxj/e65czc7fZ6 obc5ht9ixtOISG11GQXcll892hgNx1+xZlEHgSAIyueGGwoZU6+qKFMgGAufgGSw vbqkxwSpK10kOrQjX0SonsuORnnc0Yd4nrSmHC29ZZ1+ACJlZ44= =2/w9 -----END PGP SIGNATURE----- --TRcdLgao1HnQMdQjIGiPtROJBQIhRfAJe-- From nobody Mon Oct 1 12:53:34 2018 Return-Path: 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 3086E130E19 for ; Mon, 1 Oct 2018 12:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 83_vjxWR0d7k for ; Mon, 1 Oct 2018 12:53:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C50B61293FB for ; Mon, 1 Oct 2018 12:53:31 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:64288 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g74G2-0003d8-T7; Mon, 01 Oct 2018 12:53:31 -0700 From: Henrik Levkowetz To: xml2rfc-dev@ietf.org, Miek Gieben References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> Cc: Julian Reschke Message-ID: <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> Date: Mon, 1 Oct 2018 21:53:23 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jGc9WuSg3Aoda1NehKhKRF72ub6OLSeQa" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: julian.reschke@gmx.de, miek@miek.nl, xml2rfc-dev@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 19:53:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jGc9WuSg3Aoda1NehKhKRF72ub6OLSeQa Content-Type: multipart/mixed; boundary="Lp2Gx54lWG52XoFpmNduEEC3AimigLAd0"; protected-headers="v1" From: Henrik Levkowetz To: xml2rfc-dev@ietf.org, Miek Gieben Cc: Julian Reschke Message-ID: <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> In-Reply-To: <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> --Lp2Gx54lWG52XoFpmNduEEC3AimigLAd0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 an= d > the number of them). >=20 > 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 genera= te 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, wr= ote: >=20 >> As far as I recall, we ended up with the limited use of
    because >> forcing a line break inside a table cell sometimes really is needed, w= hile >> otherwise it's not. I agree consistency is nice, but this may be a cas= e >> where the current approach is the right one. --Lp2Gx54lWG52XoFpmNduEEC3AimigLAd0-- --jGc9WuSg3Aoda1NehKhKRF72ub6OLSeQa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAluyezMACgkQTptXS4+7 FxqYjRAA1FxqIQHN+R1+ZtvItnIuKWg8bN4OBk7NjOMGdeV9FNmkPC2nvxt5f7sx 2aKe2UmDufF2/wRHlwfJfmDzbHxJrBuTByfQwdiqQYK67V8zXJuoPfMC7vpYSVOp kaegnKC8uPYwS3hnzIslZM0fYodXU1+QvKHWeh4miPwuK0dxfWV465NIsU8UHK6B a9ECPQipeApdSWZnu+3Q+i+cCwcGKYlx7wIc+Eh1mV3YHT+pkjzezeVXmR+0vQYM qm/ivhazmCLIkzHcJIwq5szglj1Mn/1CqD03DKlUH9trzYo7cPxhSpbgQOp4jvWu cqkseEWQ8jDDkm9EgdUrPmfXB6UEMRqHJdHwQd3pTUetEZwKuhUTHCrr2Ae8uUae HryoZRCb15ZHNUJFkPYouYN0nWQ/7pVcXa1moAoph96CPOK7fjc0ATil8rFGNNJT WOWuBWibOvhcq8JfxSwR0RzByuXJcc37S2jGxeQfsaIe2mIOkUN8xOohimkj/fSy RuJMQCqrs2umloTtV2crZIceQE1MQ3EjuYUN5xnpufxCqfoB3Krj/ive6P6KDDac WDRM4ZIgMXvO1o/qazvDanbhgEcBMIsjbn9Gob5FZ0q0sRTzuMdnfNjD6DFa/rva jRmHpn+ynOl1kzm+NL4xNO+WsMkkBAy0SfYxXlhvFsnwqxa9w6k= =fUyE -----END PGP SIGNATURE----- --jGc9WuSg3Aoda1NehKhKRF72ub6OLSeQa-- From nobody Mon Oct 1 13:36:31 2018 Return-Path: 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 BDC261252B7 for ; Mon, 1 Oct 2018 13:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 VDmXxW9W4fsp for ; Mon, 1 Oct 2018 13:36:27 -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 8E4A0130E00 for ; Mon, 1 Oct 2018 13:36:27 -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; Mon, 1 Oct 2018 13:36:25 -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; Mon, 1 Oct 2018 13:36:25 -0700 From: Paul Hoffman To: "xml2rfc-dev@ietf.org" Thread-Topic: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    Thread-Index: AQHUWcZr/O3rvzByzk+q6exnhUAmmA== Date: Mon, 1 Oct 2018 20:36:24 +0000 Message-ID: <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> In-Reply-To: <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> 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=_0BAF09B8-E8B5-41DF-8D97-32D638A25869"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 20:36:30 -0000 --Apple-Mail=_0BAF09B8-E8B5-41DF-8D97-32D638A25869 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 > 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 that it didn't = like
    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

    , 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. On Oct 1, 2018, at 12:53 PM, Henrik Levkowetz = wrote: > 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. >=20 > 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
    everywhere, I = believe, because otherwise the output will surprise some and piss off = others. --Paul Hoffman= --Apple-Mail=_0BAF09B8-E8B5-41DF-8D97-32D638A25869 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAwMTIwMzYyNFowIwYJKoZIhvcNAQkEMRYEFKk4GPVyViRZL+l0oYKBySAU7YdeMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQB9Mowv4AL+FJQXvFIC/1MrD0fK0SUKQjsehYZqIKnTcXRADGwkeml8aBxJM9MLcuTxwotF YCDykwFokzIvtg63K2EKl58JnQNHjrs6CmrHy8sCi9+63RWVVilntCqsa4iSuHUog7hbFH8Dwl60 O705M3Anq6ezc5JV516jifLdwaYc7nY9w6Wm8oC6iiLd1RjtlpQdv9slOsK31LbZYJI2u/nA+Cs7 7SaLlsOOxYwH3Zb1alnqswrM1pbk64/ZfVn4JDh1D54Pc4BS+9fxc7hXP8KqE2AwvqEcCDlQJbHS WbEc39dCAxR4nHr10wo7gXVoSy3DsswSTR15788be91wAAAAAAAA --Apple-Mail=_0BAF09B8-E8B5-41DF-8D97-32D638A25869-- From nobody Tue Oct 2 09:35:35 2018 Return-Path: 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 2854E130EAA for ; Tue, 2 Oct 2018 09:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 YQkPv1WPUt7d for ; Tue, 2 Oct 2018 09:35:30 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68B1F130E7B for ; Tue, 2 Oct 2018 09:35:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 445A21D06E5 for ; Tue, 2 Oct 2018 09:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcxNfKrXk5dy for ; Tue, 2 Oct 2018 09:35:19 -0700 (PDT) Received: from Heathers-MacBook-Pro.local (unknown [108.177.128.144]) by c8a.amsl.com (Postfix) with ESMTPSA id 17E201C6297 for ; Tue, 2 Oct 2018 09:35:19 -0700 (PDT) To: xml2rfc-dev@ietf.org From: Heather Flanagan Message-ID: <422d2895-fb61-0c99-f916-a364787e1083@rfc-editor.org> Date: Tue, 2 Oct 2018 09:35:29 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------C5B4271E5942A03FA5DCA4C2" Content-Language: en-US Archived-At: Subject: [xml2rfc-dev] The -bis process for RFC Format docs 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 16:35:32 -0000 This is a multi-part message in MIME format. --------------C5B4271E5942A03FA5DCA4C2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hola a todos! As a reminder, each of the RFCs describing different format requirements (see RFCs 7990-7998) will have a -bis document that will change some of the requirements based on what we learn during implementation. Each of the original RFCs state the following: Non-interoperable changes in later versions of this specification are likely based on experience gained in implementing the new publication toolsets. Revised documents will be published capturing those changes as the toolsets are completed. Other implementers must not expect those changes to remain backwards-compatible with the details described in this document. So, while I don't want to get bogged down on items such as whether pagination [is|isn't] a good idea, whether we should allow color, or other fundamental issues, I do expect other items will change based on the actual experience in developing and testing the code and because of discussion on this list. As always, thank you for putting your energy into this, and thank you for respecting the energy other people are putting into it as well! If you have any further questions about the process, please let me know. Heather --------------C5B4271E5942A03FA5DCA4C2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

    Hola a todos!

    As a reminder, each of the RFCs describing different format requirements (see RFCs 7990-7998) will have a -bis document that will change some of the requirements based on what we learn during implementation. Each of the original RFCs state the following:


       Non-interoperable changes in later versions of this specification are
   likely based on experience gained in implementing the new publication
   toolsets.  Revised documents will be published capturing those
   changes as the toolsets are completed.  Other implementers must not
   expect those changes to remain backwards-compatible with the details
   described in this document.


    So, while I don't want to get bogged down on items such as whether pagination [is|isn't] a good idea, whether we should allow color, or other fundamental issues, I do expect other items will change based on the actual experience in developing and testing the code and because of discussion on this list.

    As always, thank you for putting your energy into this, and thank you for respecting the energy other people are putting into it as well! If you have any further questions about the process, please let me know.

    Heather

    --------------C5B4271E5942A03FA5DCA4C2-- From nobody Tue Oct 2 10:56:37 2018 Return-Path: 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 5501A130F89 for ; Tue, 2 Oct 2018 10:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Cb1iiwi9h032 for ; Tue, 2 Oct 2018 10:56:31 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E641130F8E for ; Tue, 2 Oct 2018 10:56:30 -0700 (PDT) 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 Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 2 Oct 2018 10:56:28 -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; Tue, 2 Oct 2018 10:56:28 -0700 From: Paul Hoffman To: Miek Gieben CC: "xml2rfc-dev@ietf.org" Thread-Topic: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    Thread-Index: AQHUWnk9HdeZ7oX2H06gnxcXcUDcEQ== Date: Tue, 2 Oct 2018 17:56:27 +0000 Message-ID: References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> In-Reply-To: <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> 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=_1A796F00-D521-4C60-A066-5DC98EFEDBBA"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 17:56:33 -0000 --Apple-Mail=_1A796F00-D521-4C60-A066-5DC98EFEDBBA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I just thought of something different that might deal with Miek's issue: = change the name of the element to . That will prevent people who = "know" what
    "means" from expecting it to work because
    doesn't = exist. If, later, we want to add
    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= --Apple-Mail=_1A796F00-D521-4C60-A066-5DC98EFEDBBA Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAwMjE3NTYyN1owIwYJKoZIhvcNAQkEMRYEFKXPpfVH+fWi8z8fRA8kGmJs53HxMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQARPgYvnN5++xW0aaTBa/Ke0URGI2el1pAgvaycXsKlZ+MeDwZPI6osCSva+t2RQtYwe7Kw 7Io5OJAMOnzM4iN7U7E9fN+ll7Ziy4SwaBchgiACxwT2o/Ie08lq9OJjqVrHkEcbeWb0RFMz+oKC gkLcvlhJza4bH543QNd8zPIkNAvJQY+e9RGoq3eGkKgXPQzZ/DvK3v1g52mWO+PXZC6r/0W5W09i Y9L4b5Yj6Az3hhwhKAUUH1IEuRf0YZR+FsiHyEb2GcRU6S/P2czwK5FwyD/M8Ka2IzQEgw3EUaG8 lunBIQxV2v4Ca/0jHESRNbtoim6ntXOYdwgi7mNK4su+AAAAAAAA --Apple-Mail=_1A796F00-D521-4C60-A066-5DC98EFEDBBA-- From nobody Tue Oct 2 11:03:13 2018 Return-Path: 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 61C95130FF8 for ; Tue, 2 Oct 2018 11:03:12 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=miek-nl.20150623.gappssmtp.com 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 Rx-Tnt1u85no for ; Tue, 2 Oct 2018 11:03:10 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3169F130EF5 for ; Tue, 2 Oct 2018 11:03:09 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id z25-v6so5910949wmf.1 for ; Tue, 02 Oct 2018 11:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=miek-nl.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=SL5tm/AtLDiHbwWAOoAILL+Qw8bbDjN3beMhVHAsCho=; b=eZnKd50j1SQxXAV/ZpbxRjYCKwIxp09Xpye6qMpv/hdOeBLyioajbV80ffl7RfVKTB jlL6H+t42JxOQ9/ZF/8GXl4nNdXtCObNtHcCIyx6a3Q49HCv6iVi6uOlXu3Z1SQ0XMgp 9iCYuBRjqyBWQUod+o3Rk264IfBwrz1qCA7lMh44RnCcDLD0HXvaiUxmOlfb/e7Se61A gPWjpotHqdWLkP/PcS6XGooC/+/TPVFWJKmfiHH/5ozqCdTEXAUMrsz+/b7t6i2KM/tI 8GcNom4+vtvppnsbidODrmnBQIJFpzqkJlpQ3JbKr0IE41Q/y4uuqDHr92HQhYTnN9uN zKFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=SL5tm/AtLDiHbwWAOoAILL+Qw8bbDjN3beMhVHAsCho=; b=ABb7xMGOqweMk0AJ0zYQTfChFKwjMiZhWzbOVnhu+vx9yUr9Gc/lw2z/K8o2Q85pcb MQZpTmjcds25VGgwaPAhO1VcChFcspA7GFl9AXwQQtdmQcYhEWcpv6Dzto6ZghEG+Brq +flH8AYuVkY1wjSk8hYpCdW/enw4T9vckMC1hPBO9XphkhE8ssWR17sGUYBKtcGWFIVF NPt57bxMHy8ByxDmgmvHuUM5ALb/ciwyZ8gHEnVlpwh22yDIYTc1vliPCt5pol5FzaiC FwptY+aebqQncmOVYdhvgBD2xvHazmf6vwLcz3BxDS6t+D5/turUK0my6jjVWK/ft5CQ ZO6A== X-Gm-Message-State: ABuFfogt+av4+STqXqje3ZYGwVpvjVHYVorYhkoWQnJHwEqC5Tqzu3lc 8I5EdfOxRDRs0BMFnX+CI9X8UAOTS24= X-Google-Smtp-Source: ACcGV61KNqsl4AhmNAN9jMqrclxdg9iCW/kgITjUy8kMYYPQzR2cj76oHyzd3MbwvuuAz3khD9T/zA== X-Received: by 2002:a1c:a90:: with SMTP id 138-v6mr2718641wmk.49.1538503387439; Tue, 02 Oct 2018 11:03:07 -0700 (PDT) Received: from miek.nl (4.3.8.0.6.9.c.b.e.5.6.a.1.b.f.a.f.3.c.4.9.5.f.b.0.b.8.0.1.0.0.2.ip6.arpa. [2001:8b0:bf59:4c3f:afb1:a65e:bc96:834]) by smtp.gmail.com with ESMTPSA id o13sm4574103wrx.53.2018.10.02.11.03.06 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 02 Oct 2018 11:03:06 -0700 (PDT) Date: Tue, 2 Oct 2018 19:03:04 +0100 From: Miek Gieben To: Paul Hoffman Cc: "xml2rfc-dev@ietf.org" Message-ID: <20181002180304.nsrwbvpcesb4ozrd@miek.nl> References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 18:03:13 -0000 [ Quoting in "Re: [xml2rfc-dev] RFC 7991 issue #3..." ] >I just thought of something different that might deal with Miek's issue: change the name of the element to . That will prevent people who "know" what
    "means" from expecting it to work because
    doesn't exist. > >If, later, we want to add
    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 nobody Tue Oct 2 11:10:39 2018 Return-Path: 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 06BC7130EA0 for ; Tue, 2 Oct 2018 11:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 9qQfeX1t_1H7 for ; Tue, 2 Oct 2018 11:10:36 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D1ED130DC2 for ; Tue, 2 Oct 2018 11:10:36 -0700 (PDT) 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 Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 2 Oct 2018 11:10:34 -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; Tue, 2 Oct 2018 11:10:34 -0700 From: Paul Hoffman To: Miek Gieben CC: "xml2rfc-dev@ietf.org" Thread-Topic: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    Thread-Index: AQHUWns2zg3OydGlZk2ck7XqhhxM3Q== Date: Tue, 2 Oct 2018 18:10:33 +0000 Message-ID: <2C672A24-F2F1-47C4-B183-EE078F920D50@icann.org> References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <20181002180304.nsrwbvpcesb4ozrd@miek.nl> In-Reply-To: <20181002180304.nsrwbvpcesb4ozrd@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=_B8E541C8-7B5B-464F-9D9D-472BDF797A43"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 18:10:38 -0000 --Apple-Mail=_B8E541C8-7B5B-464F-9D9D-472BDF797A43 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 2, 2018, at 11:03 AM, Miek Gieben wrote: >=20 > [ Quoting in "Re: [xml2rfc-dev] RFC 7991 = issue #3..." ] >> I just thought of something different that might deal with Miek's = issue: change the name of the element to . That will prevent people = who "know" what
    "means" from expecting it to work because
    = doesn't exist. >>=20 >> If, later, we want to add
    for running text (with lots of = description of what it will and will not do to displayed RFCs), we can = do so then. >=20 > 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= --Apple-Mail=_B8E541C8-7B5B-464F-9D9D-472BDF797A43 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAwMjE4MTAzM1owIwYJKoZIhvcNAQkEMRYEFIHJZ7MeIRQhvtg+5wgRtcEXQ+8HMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQAbBhlh1vDJTFsBhirzhl0eiA55b+K77r9Yx6j5TC1UtEO6/kI+d0Z8oR1LkZ77PzHN6Eob a8goYnwGHD8x4w9byU5Adm1p8HIi7iUo2hN9nAmo4kL1UAModQuaeCwDEhpQlmYK8XcuS8SHOz5y az59GC1CaJqQB4oULi/751VqGyns0dvvs/8PiiWuVVjl6HQOkK//MENxRpTvUMiuxalrpg+bo01S ZSkktZNw2AwfngQnlQh89LBhv7FM53YpqhrarLUpUTWtnnjgBOXS46tON4GVSnglPJm6ShWFqCJ7 pqZzAa8/4aeLOl2zUvpNvixukBBRYdwzzmp4ytsQGeFhAAAAAAAA --Apple-Mail=_B8E541C8-7B5B-464F-9D9D-472BDF797A43-- From nobody Tue Oct 2 19:43:48 2018 Return-Path: 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 AFE091311D5 for ; Tue, 2 Oct 2018 19:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 QGFQP67fROXz for ; Tue, 2 Oct 2018 19:43:46 -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 D838F1311C5 for ; Tue, 2 Oct 2018 19:43:45 -0700 (PDT) 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 Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 2 Oct 2018 19:43:43 -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; Tue, 2 Oct 2018 19:43:43 -0700 From: Paul Hoffman To: "xml2rfc-dev@ietf.org" Thread-Topic: First draft of the v3-bis document Thread-Index: AQHUWsLm4q/QzwVhRUukD8KDuKNtUA== Date: Wed, 3 Oct 2018 02:43:43 +0000 Message-ID: <19E99A55-1441-4AF1-AB5C-D4E21641BC86@icann.org> 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=_A1ECCFB7-D463-46E7-8395-2D1E5C9B6F7D"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: [xml2rfc-dev] First draft of the v3-bis document 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 02:43:48 -0000 --Apple-Mail=_A1ECCFB7-D463-46E7-8395-2D1E5C9B6F7D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings. I have published draft-iab-xml2rfc-v3-bis-00 as a starting = point for the efforts that you are seeing discussed on this list. See https://datatracker.ietf.org/doc/draft-iab-xml2rfc-v3-bis/ The -00 is very close to exactly RFC 7791 except that it doesn't say = that it obsoletes the v2 RFC because RFC 7791 already does that. I'll try to issue the -01 in a few weeks once we have a handful of = issues that have been brought to the list and have resolution. I'll keep = doing that on maybe a bi-weekly basis. --Paul Hoffman= --Apple-Mail=_A1ECCFB7-D463-46E7-8395-2D1E5C9B6F7D Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAwMzAyNDM0M1owIwYJKoZIhvcNAQkEMRYEFBg1p6GotrbCmccsrO1TGyzyDm16MIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQBE7+GQ278fRHnaTNrxeF2vAUA88asAxEWGvuN/0Ds9PS9caridF55fLpWBl32sBckLT+2D xaWWdMZyDT5j8fiAFmmu+ST/gL+1PqweRtZ+6V+LYbAayB7XqFgg3mHKJc1okDy+46X1Mwp/aNl/ HDfdfuJTYgDdZfGXKpci06O64Kw6kpfLk2lwpiG396L5P8dXUK1zTWc7RlwiXX3T+pPwvOVcddWw T0BjO/ypcvh3Var+H4rNKHEptM6p5SWeIOyw5vUdIfHk01OcaYZqoPelW1ucKdnxFdnNVZ5jx+Fr Pq7nSQ6voUXeza5w/L7W6zM5HbSoVsMFpvqts5Ei6rY8AAAAAAAA --Apple-Mail=_A1ECCFB7-D463-46E7-8395-2D1E5C9B6F7D-- From nobody Tue Oct 2 20:02:46 2018 Return-Path: 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 A0B521311C0 for ; Tue, 2 Oct 2018 20:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 PgoWWYttFQY1 for ; Tue, 2 Oct 2018 20:02:42 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80DDD1311B9 for ; Tue, 2 Oct 2018 20:02:41 -0700 (PDT) Received: from Jude (192.168.0.11) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 2 Oct 2018 19:57:36 -0700 From: Jim Schaad To: 'Henrik Levkowetz' , 'XML Developer List' References: In-Reply-To: Date: Tue, 2 Oct 2018 20:02:08 -0700 Message-ID: <02bc01d45ac5$7ae71a10$70b54e30$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQF+OZOBk6n1fKnGGQl4pCsbx09atqW5FyQw Content-Language: en-us X-Originating-IP: [192.168.0.11] Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #21: Schema Issue, RFC 7991, In Section 2.5.5, "name" Attribute 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 03:02:45 -0000 > -----Original Message----- > From: xml2rfc-dev On Behalf Of Henrik > Levkowetz > Sent: Monday, October 1, 2018 4:28 AM > To: XML Developer List > Subject: [xml2rfc-dev] RFC 7991 issue #21: Schema Issue, RFC 7991, In = Section > 2.5.5, "name" Attribute >=20 > This captures an issue noted during implementation, also described in > = https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation#sec= tion- > 3.1.1 >=20 > Specification: https://tools.ietf.org/html/rfc7991#section-2.5.5 >=20 > --- >=20 > "A filename suitable for the contents (such as for extraction to = a > local file)." >=20 > Given the existing use of "name" on , this attribute = name > has a semantic dissonance. >=20 > Recommendation: Deprecate "name" for use on and > , > and instead use "file", which for = will be > explicitly rendered, as established as best = current > practice for YANG modules (see for instance RFC = 6087 > [RFC6087]) >=20 > Implementation: The current version of xml2rfc uses "name". I have no problems with keeping this as "name" rather than "file". = There is not a great deal of difference to me. I am worried about the rendering of the "name" parameter if present. Is = this going to be conditional on the presence of the = rendering or is it done regardless. I would like to be able to = associate file names that are not rendered to the public as I generally = chose those names that make sense if you read them. Such as = "Appendix.3.2.cddl" Jim > --- >=20 > Regards, > Henrik >=20 > -- > This issue is tracked at: > https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/36 >=20 > Discussion should take place on this list. From nobody Tue Oct 2 20:12:28 2018 Return-Path: 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 485AF13118E for ; Tue, 2 Oct 2018 20:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 OM_fm5w8LiS3 for ; Tue, 2 Oct 2018 20:12:24 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD66F130FBD for ; Tue, 2 Oct 2018 20:12:23 -0700 (PDT) Received: from Jude (192.168.0.11) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 2 Oct 2018 20:07:43 -0700 From: Jim Schaad To: 'Paul Hoffman' , 'Miek Gieben' CC: References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <20181002180304.nsrwbvpcesb4ozrd@miek.nl> <2C672A24-F2F1-47C4-B183-EE078F920D50@icann.org> In-Reply-To: <2C672A24-F2F1-47C4-B183-EE078F920D50@icann.org> Date: Tue, 2 Oct 2018 20:12:16 -0700 Message-ID: <02bd01d45ac6$e53cf9b0$afb6ed10$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJneuHnr/v7zss5vAhzJBHAbfZkOwKlc/I8AYxBdvwC96tKtwK9drHlAgM7L/oA5XHcjqOAGaZg Content-Language: en-us X-Originating-IP: [192.168.0.11] Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 03:12:26 -0000 > -----Original Message----- > From: xml2rfc-dev On Behalf Of Paul > Hoffman > Sent: Tuesday, October 2, 2018 11:11 AM > To: Miek Gieben > Cc: xml2rfc-dev@ietf.org > Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In > Section 2.12,
    > > On Oct 2, 2018, at 11:03 AM, Miek Gieben wrote: > > > > [ Quoting in "Re: [xml2rfc-dev] RFC 7991 issue > #3..." ] > >> I just thought of something different that might deal with Miek's issue: > change the name of the element to . That will prevent people who "know" > what
    "means" from expecting it to work because
    doesn't exist. > >> > >> If, later, we want to add
    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. > > > I wonder who can honestly say that they can write 7991 XML *without* > having the spec next to them. The main reason that I know of for doing a
    is to break paragraphs in a list item. This is no longer necessary as you can now have more than one 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 nobody Tue Oct 2 20:14:29 2018 Return-Path: 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 C5E4213118E for ; Tue, 2 Oct 2018 20:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 nKgamxHwMPtO for ; Tue, 2 Oct 2018 20:14:27 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCD68130FBD for ; Tue, 2 Oct 2018 20:14:26 -0700 (PDT) Received: from Jude (192.168.0.11) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 2 Oct 2018 20:09:46 -0700 From: Jim Schaad To: 'Julian Reschke' , 'Henrik Levkowetz' , References: In-Reply-To: Date: Tue, 2 Oct 2018 20:14:19 -0700 Message-ID: <02be01d45ac7$2e4088c0$8ac19a40$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQE/60/iC0oW5uFeRsGOaCY9EO+4sAJMfbGjAKtuqJsBsjziCqYQZmNg Content-Language: en-us X-Originating-IP: [192.168.0.11] Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, New Section 2.20.4, "indent" Attribute 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 03:14:29 -0000 > -----Original Message----- > From: xml2rfc-dev On Behalf Of Julian > Reschke > Sent: Monday, October 1, 2018 6:06 AM > To: Henrik Levkowetz ; xml2rfc-dev@ietf.org > Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, New > Section 2.20.4, "indent" Attribute > > On 10/1/2018 2:39 PM, Henrik Levkowetz wrote: > > Hi Julian, > > > > On 2018-10-01 14:09, Julian Reschke wrote: > >> On 10/1/2018 1:36 PM, henrik@levkowetz.com wrote: > >>> This captures an issue noted during implementation, also described > >>> in > >>> https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementatio > >>> n#section-3.1.4 > >>> > >>> --- > >>> New Section 2.20.4, "indent" Attribute > >>> > >>> The deprecation of the "hangIndent" attribute on leaves no > >>> opportunity to control the size of the hanging indent. In some > >>> definition lists, it is desirable to have a wide indentation, in order > >>> to clearly show the terms, in other cases it is more important to allow > >>> for a larger text volume than the width of the terms would allow. > >>> > >>> Recommendation: Add an "indent" attribute on
    to control the size > >>> of the hanging indent. > >>> > >>> Implementation: The current version of xml2rfc does not support the > >>> attribute, but has all the underlying functions needed > >>> to apply such an attribute. Internally, an indentation > >>> is calculated based on length of the
    text and the > >>> settings of some of the other attributes. > >>> --- > >>> ... > >> > >> I agree that this would be useful - however we'll need to define it > >> in a way that works well with non-monospaced fonts. > > > > Agreed. > > > > What about specifying indentation as a number that would indicate > > characters in monospaced output, and en-space otherwise? > > Works for me. +1 Jim > > Best regards, Julian > > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc-dev From nobody Wed Oct 3 02:25:43 2018 Return-Path: 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 2ADA913121B for ; Wed, 3 Oct 2018 02:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 WWBLvgH6KZyf for ; Wed, 3 Oct 2018 02:25:39 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 225B8131211 for ; Wed, 3 Oct 2018 02:25:39 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:61310 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g7dPW-0006lf-1G; Wed, 03 Oct 2018 02:25:38 -0700 To: Paul Hoffman , "xml2rfc-dev@ietf.org" References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> From: Henrik Levkowetz Message-ID: <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> Date: Wed, 3 Oct 2018 11:25:22 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uBtBpngUMWKXdQjAJ0Ki6x0ELBblxSVAG" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, paul.hoffman@icann.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 09:25:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uBtBpngUMWKXdQjAJ0Ki6x0ELBblxSVAG Content-Type: multipart/mixed; boundary="BE8InuhkOmsanrbDKeKNnnlpxDcSdt4Ce"; protected-headers="v1" From: Henrik Levkowetz To: Paul Hoffman , "xml2rfc-dev@ietf.org" Message-ID: <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> In-Reply-To: <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> --BE8InuhkOmsanrbDKeKNnnlpxDcSdt4Ce Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Paul, On 2018-10-01 22:36, Paul Hoffman wrote: > On 2018-10-01 19:11, Miek Gieben wrote: >> Are we still expecting humans to write this XML directly? >=20 > Yes. We also expect them to validate it before turning in a draft in > XML format. >=20 >> I ask because the number of one-offs is already staggering (esp. >> with attribute naming and the number of them). >=20 > Yes. That comes with using any markup language for rich documents. We > struggled with this during the development of the v3 spec. >=20 >> 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. >=20 > 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
    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

    , 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
    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 > On Oct 1, 2018, at 12:53 PM, Henrik Levkowetz > wrote: >=20 >> 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. >>=20 >> 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. >=20 > In this case, doing so would require us to remove
    everywhere, I > believe, because otherwise the output will surprise some and piss off > others. >=20 > --Paul Hoffman >=20 >=20 >=20 > _______________________________________________ xml2rfc-dev mailing > list xml2rfc-dev@ietf.org=20 > https://www.ietf.org/mailman/listinfo/xml2rfc-dev >=20 --BE8InuhkOmsanrbDKeKNnnlpxDcSdt4Ce-- --uBtBpngUMWKXdQjAJ0Ki6x0ELBblxSVAG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu0iwMACgkQTptXS4+7 Fxr8TxAAtxlUz1GgwwB3W2bXXZvslauOJJ9WCkwS/o9Jz3NRywIcwGzULK1r80ur MO8c4m459DoVCxE8EHGIv7tHr9jVXNIyRwqGDUokUIJE8JXSRdiNDykslCVb7B9n mLb8o6APjdylRJKiWyOtvOezro90BoVCTgehWwgnNOqiRyxtIIExQEJ2zV50PT5x tIU/oV5zwfVp73xPpkkKTC7KB7t3FlAbQElTkGVPbyVg3r1Tc1QvsAMuGCgYFZv6 r4hTOG9l0CAkXPs7I1K7o94JErzyHDEEUWBacZRu/ihWFoidji+ngBqu9K8iGPvz gyMr/+FkP8/BvwmnR3CcbMAoI4RQvHcvhXEBUoJzgnKlJWNHM5eV7gqhEUKzNrK4 cl960LgKPgHszmKyWmJMCbKLDkBgh79/CV4XOl2tfYFnOnBt2dVFcbSBS3G9en2d XSdvFAOgKdOpuBafmo0tcjBwca/j6GC/nL5eU8xvHDjXIxEPRaRidJPE4wOvvTQ4 9diaMuzmDtq6oDuFBGJx/1+50ppoHBfzdTKNT2COpfAZS5LhRa0zOI75IAu9QNcS ri7e5erq6Cbes8U1wxAwBifi3AGNnq5BlqEo5eGfreo+6l5TbN6fELR+fA/7ALyJ uLLc+N6NKJRYGp2NTt5De0Y6zEinp510bk7D/mBH8FI8KKBsQA0= =OC7N -----END PGP SIGNATURE----- --uBtBpngUMWKXdQjAJ0Ki6x0ELBblxSVAG-- From nobody Wed Oct 3 02:29:55 2018 Return-Path: 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 D67CC13121B for ; Wed, 3 Oct 2018 02:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 v_vlUujTihMM for ; Wed, 3 Oct 2018 02:29:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C883131211 for ; Wed, 3 Oct 2018 02:29:51 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:61332 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g7dTZ-0000ra-Fi; Wed, 03 Oct 2018 02:29:50 -0700 To: Paul Hoffman , Miek Gieben References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <20181002180304.nsrwbvpcesb4ozrd@miek.nl> <2C672A24-F2F1-47C4-B183-EE078F920D50@icann.org> Cc: "xml2rfc-dev@ietf.org" From: Henrik Levkowetz Message-ID: Date: Wed, 3 Oct 2018 11:29:41 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2C672A24-F2F1-47C4-B183-EE078F920D50@icann.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dksVMG6gu3RhDc0EPHx2EHINMR1FW4ocE" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, miek@miek.nl, paul.hoffman@icann.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 09:29:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dksVMG6gu3RhDc0EPHx2EHINMR1FW4ocE Content-Type: multipart/mixed; boundary="DoPuiuGjP0cnqVCl5Mtf993DvuwVGk8jH"; protected-headers="v1" From: Henrik Levkowetz To: Paul Hoffman , Miek Gieben Cc: "xml2rfc-dev@ietf.org" Message-ID: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <20181002180304.nsrwbvpcesb4ozrd@miek.nl> <2C672A24-F2F1-47C4-B183-EE078F920D50@icann.org> In-Reply-To: <2C672A24-F2F1-47C4-B183-EE078F920D50@icann.org> --DoPuiuGjP0cnqVCl5Mtf993DvuwVGk8jH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Paul, On 2018-10-02 20:10, Paul Hoffman wrote: > On Oct 2, 2018, at 11:03 AM, Miek Gieben wrote: >>=20 >> [ Quoting in "Re: [xml2rfc-dev] RFC 7991 >> issue #3..." ] >>> I just thought of something different that might deal with Miek's >>> issue: change the name of the element to . That will prevent >>> people who "know" what
    "means" from expecting it to work >>> because
    doesn't exist. >>>=20 >>> If, later, we want to add
    for running text (with lots of >>> description of what it will and will not do to displayed RFCs), >>> we can do so then. >>=20 >> What's the problem for just allowing it ~everywhere (ala HTML); and >> go by the motto: garbage in; garbage out? >=20 > 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. >> I wonder who can honestly say that they can write 7991 XML >> *without* having the spec next to them. >=20 > 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 --DoPuiuGjP0cnqVCl5Mtf993DvuwVGk8jH-- --dksVMG6gu3RhDc0EPHx2EHINMR1FW4ocE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu0jAYACgkQTptXS4+7 FxrfpxAAiyMad3sERA7xOt7VU9KbbT2MZN4YdYUjp1wiz0+H9+8x9pCLO/x31+v8 ah7t22ubO139WidkkNMETb//tMKeTD0pGEabU0atpYTXuM9TGdwlvAACl33QbIkO op3Z+MPvhGnyY21O7GHZDPELc9CZEUT8EsWbFh7OLY6eBtchgYLMolUf+AuUiN1n Yk/h+4orMSLqtPgSOpeX/lx9UgrfwOiAlUDj/HCJ/PiW34bzMKE9QcjmFy/LwGDP jQW/Vm6MSv/DyS2P+ldRIbYURyD46H/iJnH+0YX1Ly1m8BTi6CCBfJzlWhL+v3qL Eu+q5FMp5+oEyfCYB2W+OTrWX76bGWlFMuA2mk1X/VB+GCWZeAC2FA08MHGCGOx7 WW+Iuyd0/Md33ry5enifMvjMMwUuxoHplsM6ZONqRSB4pDwUx3A3+LNgpP9qYMte fIoLebFfSWdKYF0U0kUdej258UBcTV2EVeaFBp48DXssOk5q9kq3tFnGyRzceWyU dNbGTGvVGgllU/I6CxnFok8NP48nYX3X5F0mk0cTlpZe4D7Tno4fzA3/Zj3e05Ij jNFn7Tc3beZYjP8En9k0uOm4srpL/9BqsE+0+IzVO/fTSt58uqJDVz0Rpc5KuxmS W02eDxwLJ/ZDzh21scVwiglLI6CkWRVCRemAjLTMBTsOWFUvh3E= =h5Oq -----END PGP SIGNATURE----- --dksVMG6gu3RhDc0EPHx2EHINMR1FW4ocE-- From nobody Wed Oct 3 02:57:08 2018 Return-Path: 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 A8A0E1311C9 for ; Wed, 3 Oct 2018 02:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 ndAFgEXVgvxB for ; Wed, 3 Oct 2018 02:57:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 358A7130F89 for ; Wed, 3 Oct 2018 02:57:06 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:61624 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g7dtx-0003mm-9o; Wed, 03 Oct 2018 02:57:05 -0700 To: Jim Schaad , 'XML Developer List' References: <02bc01d45ac5$7ae71a10$70b54e30$@augustcellars.com> From: Henrik Levkowetz Message-ID: Date: Wed, 3 Oct 2018 11:56:57 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <02bc01d45ac5$7ae71a10$70b54e30$@augustcellars.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fWVVn9A2vcpOKtdMQsvAMaOX3IIaGlvA6" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, ietf@augustcellars.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #21: Schema Issue, RFC 7991, In Section 2.5.5, "name" Attribute 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 09:57:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fWVVn9A2vcpOKtdMQsvAMaOX3IIaGlvA6 Content-Type: multipart/mixed; boundary="C4GKqr8qoreMsmp0wdiUmOOTnVhgJ8RVL"; protected-headers="v1" From: Henrik Levkowetz To: Jim Schaad , 'XML Developer List' Message-ID: Subject: Re: [xml2rfc-dev] RFC 7991 issue #21: Schema Issue, RFC 7991, In Section 2.5.5, "name" Attribute References: <02bc01d45ac5$7ae71a10$70b54e30$@augustcellars.com> In-Reply-To: <02bc01d45ac5$7ae71a10$70b54e30$@augustcellars.com> --C4GKqr8qoreMsmp0wdiUmOOTnVhgJ8RVL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jim, On 2018-10-03 05:02, Jim Schaad wrote: >=20 >=20 >> -----Original Message----- >> From: xml2rfc-dev On Behalf Of Henrik >> Levkowetz >> Sent: Monday, October 1, 2018 4:28 AM >> To: XML Developer List >> Subject: [xml2rfc-dev] RFC 7991 issue #21: Schema Issue, RFC 7991, In = Section >> 2.5.5, "name" Attribute >>=20 >> This captures an issue noted during implementation, also described in >> https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation#= section- >> 3.1.1 >>=20 >> Specification: https://tools.ietf.org/html/rfc7991#section-2.5.5 >>=20 >> --- >>=20 >> "A filename suitable for the contents (such as for extraction to= a >> local file)." >>=20 >> Given the existing use of "name" on , this attribute na= me >> has a semantic dissonance. >>=20 >> Recommendation: Deprecate "name" for use on and >> , >> and instead use "file", which for wil= l be >> explicitly rendered, as established as best curren= t >> practice for YANG modules (see for instance RFC 60= 87 >> [RFC6087]) >>=20 >> Implementation: The current version of xml2rfc uses "name". >=20 > I have no problems with keeping this as "name" rather than "file". > There is not a great deal of difference to me. >=20 > I am worried about the rendering of the "name" parameter if present. > Is this going to be conditional on the presence of the > rendering or is it done regardless. The next release will render file "Appendix.3.2.cddl" only if a new attribute "markers" is set to "true", which is my proposed resolution for the question of whether to render code markers or not. > I would like to be able to > associate file names that are not rendered to the public as I > generally chose those names that make sense if you read them. Such as > "Appendix.3.2.cddl" Will the above resolution work for you, then, or do we need separate "name" and "file" attributes, or do we need 2 separate attributes to control rendering of code markers vs rendering of file name? Best regards, Henrik --C4GKqr8qoreMsmp0wdiUmOOTnVhgJ8RVL-- --fWVVn9A2vcpOKtdMQsvAMaOX3IIaGlvA6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu0kmoACgkQTptXS4+7 Fxrydg/+MpbgHzQ8IMDZs+PYXsNI3zjeVqNF+9I+CgZV3rlBAhSZ7TUvP4DlZPkU JNJ6UfD775KutbBkXAlEj2YkJbawvPLjlBnIWXK6r10Jw16lT8LzL6Ao1uIG6yc3 h6qL6WvIlHAR+o3GNcwXXGK7J70rE7hqAXOLJTL5KqJ6brVB/+wbHP1WfF/tkWuA MpDJiiSoa/SD9bSMQu1kOh9Npgug3k7kvuOwjK5sJadXx7OlG3cTO5Zm7kQiuxSN DPNgu9ql/FgNbUUb/JjkLzzlDCtg9hIvkJi6ZVy7g7kOPNuRrf/yY/MmeHHr0lmG 9OT0MLRHsiXvBmG6CnJfu5HhhBl644lv4ABqHH4LTFkVdKKNW2nWnHSl0IAIB0YK o9YcUSriL2ZJ3ujYxuEABCgNWTJwFFO5KRHhfNiz20QTY0Am2rA72g5ZzzMbiuiB GYIFu9r77ph/E2sL6qy+OFRJXmh7lMuBHhZ/iryQCFXI8HCLvnNLJlVHF7x1MxLX wPNJe1qmY99Jm6+ZKeX9ZKvUhLkKkOOMAb158eLUYAXB2+5PnHU8qMKoHaJB4hWy s7D4Agc1Ao+XV62T/7Lyog03aOwyLM61RRdOYTlnEAmIal83S8M6P/jQm57JXp4Q DaepBg5jIiIYB7wBKFscA7dXV4NbW7+0S1enqR8uaUpt3hJunbk= =zkPP -----END PGP SIGNATURE----- --fWVVn9A2vcpOKtdMQsvAMaOX3IIaGlvA6-- From nobody Wed Oct 3 04:39:29 2018 Return-Path: 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 12DB51310AE for ; Wed, 3 Oct 2018 04:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 FK3wDfCrKaQ3 for ; Wed, 3 Oct 2018 04:39:25 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1E17130EDB for ; Wed, 3 Oct 2018 04:39:24 -0700 (PDT) Received: from [192.168.178.20] ([84.171.148.77]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MBnSJ-1fyYx31dhf-00AnIP; Wed, 03 Oct 2018 13:38:42 +0200 Received: from [192.168.178.20] ([84.171.148.77]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MBnSJ-1fyYx31dhf-00AnIP; Wed, 03 Oct 2018 13:38:42 +0200 To: Henrik Levkowetz , Paul Hoffman , "xml2rfc-dev@ietf.org" References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> From: Julian Reschke Message-ID: <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> Date: Wed, 3 Oct 2018 13:38:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:PWCITLXvXhNgbnqL3Ylu234VSC/Rm5RoTARcx468tk1+g2mlv03 5vmEtfuw0f5RlX/hI3f3M9d/ITAcgeOV8f7Tr1yEPOOZpZHz15z9CJ4gPZnPVp/gcqFkQQ+ 4RDgWlOllqNw1PYFe30BWPa9vTrf8+4zdzQg1omke06lyVtnfdSRiBtMEY0zOwm5HAaq4H2 A/Ju647cB9iz7OJ+1qLNg== X-UI-Out-Filterresults: notjunk:1;V01:K0:iASn3rk9Wfs=:jeaM3OHMMDBBl5FNI0BCvY bZ9P62zcsX+MTLI8NCEVM3L38Qza0nTlEs5br2xJg87BmaK2pSa/E0T3fWBLiJ/6mnE7ZknII Fs6uUoHEFCm2lEvXfBnXQcjTvUDFnFmbv78YiQx4w14P8MRy1Zj5WsB7v5QkoSt3sU7oPjXVC 2WJ+t/hXc9t97eqp3Kemvrz+6Vwousb42MSfqUhVb7VUAarHEHhUEAYgP4y5RKM/wEy+hZ1r2 y/in3x80AfAOoUpIUlB5IZVJ3aQ3AYMdQSUoWzaY0Y0vlXEcYDAHYn+AxM7g/NvVeYJE8derg 8lNSC4DtQWcK1PAllGBRcI+yPqdN5W9lJ3Hhqxd+4Q6kyOrYjMsvW5CCR7JONR1xXlXkJAlFf vwhA+aK+bkPzcfk8DONSmR5z0ZBcKm0t+Q7ox7cYl5+sZdX0s1nh05UuAaA0QpIRTdedZjxrP L+c9xEgi19XRAOJODyidhERCnZIU1iIkY1Qh44Lcl73BCOQIS445Ir3wX+AnYL/8kXerqqQMA UOQfwvxNVpkQ0SqGYnI4Nww/QxGtnQrTbfVq5XYiBMVut75VQE60ZWyLkFcSmrz0YzpEYyCyd DwSg/G4oaR2em40BvVit9kUN+36nV5Dd1KDBsoEMgghMKdEYHo5YkV67izzzI8v9p69gEPvxA IuhQmIj8CYVlB3lP6EizodMR5nDc5Vr6QsV+ryvOqBteaELHKiBIXyG391aiUut7K97qLSJBK gpxV3b3ZD5hi0TSOU3mRmGkHBqAMy1ZyLo5UTpLjUYYySDrfuAcqnZ49CZ4ldgSkbNiU/uWc8 KBAqsAaJ3xN5GZCJHh1nU1HI1bgA0UfkB5UeNj9qL64lpMaemI= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 11:39:27 -0000 On 10/3/2018 11:25 AM, Henrik Levkowetz wrote: > ... >> See Julian's response in the thread above. The WG decided > > Umm? Which WG? Could you point at the discussion? "Design Team". >> that it >> didn't like
    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

    , 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 >
    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. 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*
    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 nobody Wed Oct 3 04:49:18 2018 Return-Path: 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 3C0AE130F97 for ; Wed, 3 Oct 2018 04:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 BZ4ff9j8HjPL for ; Wed, 3 Oct 2018 04:49:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5658130EDB for ; Wed, 3 Oct 2018 04:49:14 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:62498 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g7feT-0001GZ-1h; Wed, 03 Oct 2018 04:49:14 -0700 To: Julian Reschke , Paul Hoffman , "xml2rfc-dev@ietf.org" References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> From: Henrik Levkowetz Message-ID: <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> Date: Wed, 3 Oct 2018 13:49:05 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sbHD9E8fADHD6JxQFtfm2g8BMEIxc9xbj" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, paul.hoffman@icann.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 11:49:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sbHD9E8fADHD6JxQFtfm2g8BMEIxc9xbj Content-Type: multipart/mixed; boundary="anHRfwphpiG2fBgM0GgqTXrk7cp5GXGgq"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , Paul Hoffman , "xml2rfc-dev@ietf.org" Message-ID: <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> In-Reply-To: <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> --anHRfwphpiG2fBgM0GgqTXrk7cp5GXGgq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Julian, On 2018-10-03 13:38, Julian Reschke wrote: > On 10/3/2018 11:25 AM, Henrik Levkowetz wrote: >> ... >>> See Julian's response in the thread above. The WG decided >>=20 >> Umm? Which WG? Could you point at the discussion? >=20 > "Design Team". 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 somethin= g we could have counted on) some experience with using the v3 vocabulary, provided by Miek. >>> that it >>> didn't like
    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

    , 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. >>=20 >> I don't see this. I think that if there are considerations which make= s >>
    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. >=20 > 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. > Table cells can get very narrow, like just a few characters, and in tha= t=20 > 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
    makes sense in a cell and not in body text. > FWIW, HTML5 *allows*
    in many places, but says clearly that it's=20 > 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
    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= =2E Best regards :-) Henrik >=20 > Best regards, Julian >=20 --anHRfwphpiG2fBgM0GgqTXrk7cp5GXGgq-- --sbHD9E8fADHD6JxQFtfm2g8BMEIxc9xbj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu0rLEACgkQTptXS4+7 FxpWgRAA0/f7DPaLz3bCGCQw8HvguRx6vDYpKoK4wOsKC/68ZWUIRXE6ELqrf0i4 OZp3TTmj67gYp58+Abit+ieoYChHYk+DCIpz68A/d02XSdNwA6ZhwR4rj/pJquV3 D9ab+/E9+MnltRwmUJrrP11jEeH8L3DJoPokgAE4ZcDcTj2BCimqI4aUfdwbr/S3 1aEGjlx3gPsGvkOiKFkjKCPHQDcPbbEOELuQTQqJiIYvtmzmSU4AsJ3/ng2AT4Dp eH9A/+leOQq+Nije5TXqXd40LKucXzcz3GL5SWe7tydUqObcpaPDbCTAeLrPyKVC ceXfbyz+39vq9+cKE6bDit0rboDcBmEDEWbyG6ZzQOpxHz92FwjZV1pxwn6ZnLGH BbHb2s7QRTGMrlYDDjJRiqvL8O/rauP41iUCvQQek3/A8U+GoFIanNcPJ97ezqE8 Ah9pP3gbnY2iiA/iU2LEFXUWD48S7UGfz+9/jr6j07z9DhcYZDXIElLbL9SiwshD 7Uszx0eWH7s2q6JeN5XqokweJXhIOGI5tTZMnRGzRaLKgmbeJl+WfBcUjAwi/fPe 8jLILG0Hv5pCZnC6Y9IUsQvFUGDkdLGQZq0PJsbFWiZ8F9CFUvq/ZWSNTlUii7b6 1Qek/iEyeEVpB5ZSody4eFo8cz6AQefPbalUmo43ehf3aTlJEGY= =Q5Oy -----END PGP SIGNATURE----- --sbHD9E8fADHD6JxQFtfm2g8BMEIxc9xbj-- From nobody Wed Oct 3 04:59:36 2018 Return-Path: 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 2D24A13127A for ; Wed, 3 Oct 2018 04:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 0lInerzKwUKU for ; Wed, 3 Oct 2018 04:59:33 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEE1F13126F for ; Wed, 3 Oct 2018 04:59:32 -0700 (PDT) Received: from [192.168.178.20] ([84.171.148.77]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MhQxO-1gLVQB3geI-00MbhQ; Wed, 03 Oct 2018 13:58:49 +0200 Received: from [192.168.178.20] ([84.171.148.77]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MhQxO-1gLVQB3geI-00MbhQ; Wed, 03 Oct 2018 13:58:49 +0200 To: Henrik Levkowetz , Paul Hoffman , "xml2rfc-dev@ietf.org" References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> From: Julian Reschke Message-ID: <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> Date: Wed, 3 Oct 2018 13:58:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:E29ve3MIvPnZKdU9728MqFHS/eoP+NvpwGEfbPlZmtZr0IANDow 8J0qvcjLYMPty8LXWIl+yUYq2OSU97jqt6yvT5HO/93I6pr9mwUqb0T80m0kb5Eg0wV0I2Y Z9wuBG+EmLExhl/QvhmdW7uIBSHLG+6DkCKvlezA+24UZQLJ/8EPvD3rthLzFQMESYjQ1lY OKstd5RrCQSMa7tujvPVQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:rIgs6Rww9Tk=:2GD9wlKELRwV/K6Qq5Azn0 8A1JFa+EcL/KLFEGeo5jtcnPCeim33yak02p6J/JV31fgo2hXzmRlJq+/qJCAJM6iTIChrRsg WT1LyDBBDMzSaeckmN7CjTJaIOanIosNUK+N9AUg6EI2L+z/I7K5YSkWHGQpn3wF16O/evFMG JVpzcQ4B2rH3ovZeDlBdhRJ9ZTeykWXLr41JdHKdjv3f/Eytl/gijMDRB06cXePKMHRIgIWu+ 6TsuMpY+3oeVk6+XiwxCsE63Bo0hAm3lBv0GPh8cnYxhh6xXjCilVXML6TQsCcd0lyP5ZtXAA LxALJXlc7GWvyTmHX/AdOd6FCOrqSNprwNnLs+/f+wPd91LkFOlnm922SNy7VBlgHHp+o5A5k 23EkZJSBRihMFTRhdBYEk4LnXbYhozRr9+yzJlli76PJv5ObmrMtPn3cM/xsdmw/4SxOo0YE0 5NvJKbXqU7st5xr/iNPqYrTBCCQJxZTiu6hXDnREhC4iJlksY0sEaLVsdybsIEc8lPdwoKb4D sTKl9u2APfz692nTe1uiqtNolaKz3m0suT5yHQp185PXPWftzdLDQfrIZwXYhwPx2GQg5eiHC X7sGzDTsvAYxhQ3ctQXNntOzhGelxI0s9gV8ov7nvKAb7NzXF/N5yf58zhIAMIhKubLE6E2Fb WVcjnzLIiJrjQGSE6h93RLleNOj2sXJkNKSgRfzBCzcr9sOGLt/YPzPjniS3YAl8cvYVZffkB QKbMmF7JuZKfx4l8Hi0CIJ3ggK6zRKuTgBXB8xgdr+9L4JDrIZrKJQ+OX4WkzJUmXTRcX+ZcV 5kjCuoIVZjWP2ai4Z6wR2b2SYF4fGofD5PgegO2SsbXbeYcqKg= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 11:59:35 -0000 On 10/3/2018 1:49 PM, Henrik Levkowetz wrote: > ... >> 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. 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. >> Table cells can get very narrow, like just a few characters, and in that >> 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
    makes sense in a cell > and not in body text. > ... is an example copied from a real table in an RFC (which back then used though). >> FWIW, HTML5 *allows*
    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. > > 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). > Please note that my suggestion was to either remove
    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. 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 . Best regards, Julian From nobody Wed Oct 3 05:13:31 2018 Return-Path: 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 7500413126D for ; Wed, 3 Oct 2018 05:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 xwpcunb7qxdY for ; Wed, 3 Oct 2018 05:13:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74226131029 for ; Wed, 3 Oct 2018 05:13:27 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:62668 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g7g1u-0002yD-Mp; Wed, 03 Oct 2018 05:13:27 -0700 To: Julian Reschke , Paul Hoffman , "xml2rfc-dev@ietf.org" References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> From: Henrik Levkowetz Message-ID: Date: Wed, 3 Oct 2018 14:13:19 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1iIL7MOevW4DIWf45EEGeaeXghnQ6N4BB" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, paul.hoffman@icann.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 12:13:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1iIL7MOevW4DIWf45EEGeaeXghnQ6N4BB Content-Type: multipart/mixed; boundary="WgV2HLsLOQUlIaRcDRH8odXJxXmegun5h"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , Paul Hoffman , "xml2rfc-dev@ietf.org" Message-ID: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> In-Reply-To: <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> --WgV2HLsLOQUlIaRcDRH8odXJxXmegun5h Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-10-03 13:58, Julian Reschke wrote: > On 10/3/2018 1:49 PM, Henrik Levkowetz wrote: >> ... >>> How did you arrive at 30? >>=20 >> 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 coul= d >> be similar to the case for a table cell. >=20 > 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* lin= e=20 > break - it would affect "regular" rendering as well. >=20 >>> Table cells can get very narrow, like just a few characters, and in t= hat >>> case it can be desirable to control line breaks. >>=20 >> No, it doesn't help the argument that you repeat the statement. >>=20 >> I seriously want to be shown examples where
    makes sense in a cell= >> and not in body text. >> ... >=20 > i= s=20 > an example copied from a real table in an RFC (which back then used=20 > though). 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
    to make this come out right? >>> FWIW, HTML5 *allows*
    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. >>=20 >> But doesn't that approach make more sense that the current limitation?= >=20 > 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=20 > notation). So the conclusion would be to eliminate
    , then ... >> Please note that my suggestion was to either remove
    altogether, o= r >> permit it in inline context consistently. I don't care that much abou= t >> which choice we make, but I still haven't seen any concrete example th= at >> shows why it makes sense to disallow it in one context, and not the ot= her. >=20 > My concern is that when people can't get the table output they want,=20 > they'll fall back to artwork, which isn't helpful. See=20 > . Understood. I still don't see the problem with permitting
    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 --WgV2HLsLOQUlIaRcDRH8odXJxXmegun5h-- --1iIL7MOevW4DIWf45EEGeaeXghnQ6N4BB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu0sl8ACgkQTptXS4+7 Fxqoyw//SOGHEYgUWwJnOXCUuJNEmFovK8XHaD8v5MlLaj4eVnMr5WGEEILY2nDx nPDnPWlkeylgosn/0Bzp6+W1kMQRJuzWpR4qvZa2tKHkL2S0hcAsv+Rvdb6ZAMc+ bsJvSJ93ongqOjP70wy6UJOCtV4mSJJiAld1EWGgT/avJDNZamLFme+TuOCYZ49T aSVHXd0gHebOhq39iLx0tuqSU4IjkNV3TEX6yqq2U7cMAx9C94CfEiVJdrA7aYjJ ysDDuNYSv+gqxmkPTfJ6T6LDDJHl23XICsHVszU6tMw6CSFXLFfL3xT8xLZ69jga lISFk98jLGoRs+VVtMQUr8JJZbT5S4KNwxTMl2vZWw8Cxt3EReYma1ICIb5ukh89 QvMQgrYBvtoqxh0yqDf/A5930zJc27/2FNyZGcLEgd2uWwHi7BaC0zTE1Os2uC0P Rc9GO+vTobY5NuqcWXcSyNo2HoBDY1HRSeWv1qeBHpMxPANmLMIOd7oZMWoNkgD0 W1Hq34xCWeCDufcbEcClWQLg92JC+AzgHUxn/ojsN588rsLff74xXHL6en43oQDP 18U0jiaEQLXZ9SIQYIDFJTQTeWm7/BTKnAFlLL7UPG+iQcJlnY+5dBtYMqA9v3AM Y6wkcYoLG8SWFw/jx1lpc0Hso2kO0u8IBvjB4OMcK5e1LNhSB2c= =k4sk -----END PGP SIGNATURE----- --1iIL7MOevW4DIWf45EEGeaeXghnQ6N4BB-- From nobody Wed Oct 3 05:20:00 2018 Return-Path: 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 0D39513126F for ; Wed, 3 Oct 2018 05:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 BGr3NvwSq-sk for ; Wed, 3 Oct 2018 05:19:57 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FA7E131270 for ; Wed, 3 Oct 2018 05:19:56 -0700 (PDT) Received: from [192.168.178.20] ([84.171.148.77]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Mbwm6-1gOnXS3Hny-00JHpd; Wed, 03 Oct 2018 14:19:36 +0200 Received: from [192.168.178.20] ([84.171.148.77]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Mbwm6-1gOnXS3Hny-00JHpd; Wed, 03 Oct 2018 14:19:36 +0200 To: Henrik Levkowetz , Paul Hoffman , "xml2rfc-dev@ietf.org" References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> From: Julian Reschke Message-ID: Date: Wed, 3 Oct 2018 14:19:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:KJeNfHHQ8ExM5xXSqHy6gbYzUFwbgdbJio6BgqFRenZ2bZhA0ZU BTU64fUX73za1UWkHf1QG7mBcsILYdq4/7lp9W5w0oneUFLbTHxIn/WGxelLJdjvV52Hbpv oWwrQDaKYLKIrXxjmtDU7hPPojYqyvBM0z8CKYs7y6Nsi8aBB3aBkY5D1J0ppE/RGSW32cA 7RJ/04dR37VpzXKU1WjGA== X-UI-Out-Filterresults: notjunk:1;V01:K0:ys2Xk2rKN6s=:DrHREt0BfUPzjB3rIzyHgc wLB4PZF81Wn4j5Q3mACXADYtlLEa9jd4vWIkOcPbYuPY+JrQ8+JQ2PITBLH6bNF1/gpirxevT 6CDbNjALMbxh14Si8seZKF9Y1P0XbHRj8mgw6uZHugouOCcUN8Jq6Int/d4eWxMsD/8+zUXSW 90lajm8k+XP6vFe/D1AjAv3XrImBLEvkjzFpaOQW9RLgwgoMSSS+BTYNtaMJYuHXSzB9ntKbL MaCW++8DiWLSooCfK/wGvfMWf2/LYkW37/28Kk6iUUkGT5+vIJp87IylgpDpREWJgEmJ8915i Tq+iyPRJiay7xD9Ozaxbzl/VaekihBelmjwhv7IbzujrSeJWBIGcixN6iOUfmes0xV1/J+zha aLAfP52Uq+WOLMq21sTzG8XjdLbt8i06NgCIa0azjbGvcny7CY5qbiqTgIeHVZPcqbEt88pWE csRxVk8T3rWpbY2lO26AsUMa00W0wROyYCe0zugGavsLu+OhsVLiit6uVhmXjZLlEOZJbU43A vcha+gjADy25rG19zpUJk35Zi10bH2fRF4/WpiN1st00xsnR9voB2I5HAl2A51fMI8obyYRlw UHxNeWR2ipj4sARnSnny0kvn19hXUbL1eXDOPo5pMkXnSSA7QcB/L42v4YVvd5QU7m7Y84Nig gcnak2T+8mVFXvD4hQmdbwY+oN+tOrBWpG7Bg013lC0qVNGAvgZJzLBVyezppcACRLFoJ6znZ LeD7r4dheDv6ZZzKQuLH64CsMLlGeaEDW9jdnJrTTl0Fbv5feFj8RlzSCEOdCv6PKY+qYaszr hS/CagiFDB0ZKSE7J+RTK2g5X69M4frbCS2xah3C/u9DaQRWQo= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 12:19:59 -0000 On 10/3/2018 2:13 PM, Henrik Levkowetz wrote: > ... > 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
    to make this come out right? In the titles, at least if we want to reproduce what the RFC has. > So the conclusion would be to eliminate
    , then ... > >>> Please note that my suggestion was to either remove
    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. >> >> 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 >> . > > Understood. I still don't see the problem with permitting
    generally -- > the argument about going to artwork has some validity also for body text > 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 nobody Wed Oct 3 05:53:20 2018 Return-Path: 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 6DC9D131270 for ; Wed, 3 Oct 2018 05:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 5APau0IJ5l2H for ; Wed, 3 Oct 2018 05:53:15 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0B6D13118E for ; Wed, 3 Oct 2018 05:53:15 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:62948 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g7geR-0007WW-1L; Wed, 03 Oct 2018 05:53:15 -0700 To: Julian Reschke , Paul Hoffman , "xml2rfc-dev@ietf.org" References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> From: Henrik Levkowetz Message-ID: <6c9785df-73c0-78ff-0c69-1ea1b369b0e0@levkowetz.com> Date: Wed, 3 Oct 2018 14:53:07 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1oO2WCA6ndwwHfrpGl9joDv2pFGoXHIMW" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, paul.hoffman@icann.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 12:53:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1oO2WCA6ndwwHfrpGl9joDv2pFGoXHIMW Content-Type: multipart/mixed; boundary="XLUV2bC9IntjKW2qkHUU3pdB7H6O5tGtm"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , Paul Hoffman , "xml2rfc-dev@ietf.org" Message-ID: <6c9785df-73c0-78ff-0c69-1ea1b369b0e0@levkowetz.com> Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> In-Reply-To: --XLUV2bC9IntjKW2qkHUU3pdB7H6O5tGtm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Julian, On 2018-10-03 14:19, Julian Reschke wrote: > On 10/3/2018 2:13 PM, Henrik Levkowetz wrote: >> ... >> Yes, I've run that through the current text processor, and I particula= rly >> looked at it when working on table rendering. >>=20 >> Where is it you need
    to make this come out right? >=20 > 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
    . 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 instan= ce 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
    . And I'm sure that I'm not able to predict all other cases where
    migh= t be useful, so if we believe it would be useful in some contexts, we shoul= d not limit it to only one narrow context which we've discovered so far. >=20 >> So the conclusion would be to eliminate
    , then ... >>=20 >>>> Please note that my suggestion was to either remove
    altogether,= or >>>> permit it in inline context consistently. I don't care that much ab= out >>>> 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. >>> >>> 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 >>> . >>=20 >> Understood. I still don't see the problem with permitting
    genera= lly -- >> the argument about going to artwork has some validity also for body te= xt >> if people can't get the output they want. >=20 > 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. 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 --XLUV2bC9IntjKW2qkHUU3pdB7H6O5tGtm-- --1oO2WCA6ndwwHfrpGl9joDv2pFGoXHIMW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu0u7MACgkQTptXS4+7 FxrEVxAAxE/JamLsXhyUWssh/QeIr4pfUWlj0OVRv9+duFvhnSrbBSCcUW71cH18 cZh3CCxP8J3uhozRNYkfIwTYVZPBrboFBQMJ1y0g5BaCOZtvrZ3psnnY/SyqX9f0 4aDFqaf9wKkmaa6SfnvrdUlUSDT1ywRJ6EgYyxkmDhWWTsro9kqX075MC++PAK8j fl3c0viJBxc3fQtiy6Ns7prlpGl2NoKsev857POfRkcV3sX5JzJkI4xC8qiMKSaS iKliIrrocZvQnRzT5lpQ8qIgtOoZFYsZPEBcqcHekXgeLe9Q94m7T5YmeI9K4fSY ZwDzwTAOc5GvZamgBo5YJcfDSG8tRLIvJkHwAlQpOtUqR9zP5+kxTieLeGGD5zKh 9ttuZ6PCRxNttyY0E1EXtFUmGpDoaSpJqWsAZhtQqGEiypVYydCUefCc7bsnRUQq Q1Nnhlq041fg/2bwXw2vquom8Ry810EJ8bRRzTV6mA87obV/DM9lneTey69VMHxo nTAvuHf+xtgfhWHCVmz2fdacuizynqiPPNEWvuXKTXgKj60JEA65ous11tZIrkvp 5Mgx/0n4ftTuTxfWyYZiKzKJeMl5BnzT5yOFzmq9TdRIFGBBF2u8N+kiz4YHIpVr exqdQrioETiHvkidpK0Nx9NxJysDe3OxckfUW0ErT/GbCNsGvVw= =6cJn -----END PGP SIGNATURE----- --1oO2WCA6ndwwHfrpGl9joDv2pFGoXHIMW-- From nobody Wed Oct 3 07:55:36 2018 Return-Path: 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 76C7B1312C6 for ; Wed, 3 Oct 2018 07:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Q6Xq3T10hlNL for ; Wed, 3 Oct 2018 07:55:32 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AEB91312C5 for ; Wed, 3 Oct 2018 07:55:32 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 3 Oct 2018 07:50:48 -0700 From: Jim Schaad To: 'Henrik Levkowetz' , 'XML Developer List' References: <02bc01d45ac5$7ae71a10$70b54e30$@augustcellars.com> In-Reply-To: Date: Wed, 3 Oct 2018 07:55:20 -0700 Message-ID: <030e01d45b29$1c7b33d0$55719b70$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQF+OZOBk6n1fKnGGQl4pCsbx09atgGmsqYVAnInDXalmRfZAA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #21: Schema Issue, RFC 7991, In Section 2.5.5, "name" Attribute 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 14:55:35 -0000 > -----Original Message----- > From: Henrik Levkowetz > Sent: Wednesday, October 3, 2018 2:57 AM > To: Jim Schaad ; 'XML Developer List' = dev@ietf.org> > Subject: Re: [xml2rfc-dev] RFC 7991 issue #21: Schema Issue, RFC 7991, = In > Section 2.5.5, "name" Attribute >=20 > Hi Jim, >=20 > On 2018-10-03 05:02, Jim Schaad wrote: > > > > > >> -----Original Message----- > >> From: xml2rfc-dev On Behalf Of = Henrik > >> Levkowetz > >> Sent: Monday, October 1, 2018 4:28 AM > >> To: XML Developer List > >> Subject: [xml2rfc-dev] RFC 7991 issue #21: Schema Issue, RFC 7991, = In > >> Section 2.5.5, "name" Attribute > >> > >> This captures an issue noted during implementation, also described = in > >> = https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation > >> #section- > >> 3.1.1 > >> > >> Specification: https://tools.ietf.org/html/rfc7991#section-2.5.5 > >> > >> --- > >> > >> "A filename suitable for the contents (such as for extraction = to a > >> local file)." > >> > >> Given the existing use of "name" on , this attribute = name > >> has a semantic dissonance. > >> > >> Recommendation: Deprecate "name" for use on and > >> , > >> and instead use "file", which for = will be > >> explicitly rendered, as established as best = current > >> practice for YANG modules (see for instance RFC = 6087 > >> [RFC6087]) > >> > >> Implementation: The current version of xml2rfc uses "name". > > > > I have no problems with keeping this as "name" rather than "file". > > There is not a great deal of difference to me. > > > > I am worried about the rendering of the "name" parameter if present. > > Is this going to be conditional on the presence of the > > rendering or is it done regardless. >=20 > The next release will render file "Appendix.3.2.cddl" = only if a > new attribute "markers" is set to "true", which is my proposed = resolution for > the question of whether to render code markers or not. >=20 > > I would like to be able to > > associate file names that are not rendered to the public as I > > generally chose those names that make sense if you read them. Such = as > > "Appendix.3.2.cddl" >=20 > Will the above resolution work for you, then, or do we need separate = "name" > and "file" attributes, or do we need 2 separate attributes to control = rendering > of code markers vs rendering of file name? That resolution works for me. There might be some source code people = who might be surprised but I don't know how big of a problem that would = be.=20 Jim >=20 >=20 > Best regards, >=20 > Henrik From nobody Wed Oct 3 08:09:02 2018 Return-Path: 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 058831312D2 for ; Wed, 3 Oct 2018 08:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 757H4dUhz9Jm for ; Wed, 3 Oct 2018 08:08:58 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB5851312CE for ; Wed, 3 Oct 2018 08:08:57 -0700 (PDT) Received: from [192.168.178.20] ([84.171.148.77]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MVeCF-1gDzCI0o2x-00Yx23; Wed, 03 Oct 2018 17:08:41 +0200 Received: from [192.168.178.20] ([84.171.148.77]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MVeCF-1gDzCI0o2x-00Yx23; Wed, 03 Oct 2018 17:08:41 +0200 To: Henrik Levkowetz , Paul Hoffman , "xml2rfc-dev@ietf.org" References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> <6c9785df-73c0-78ff-0c69-1ea1b369b0e0@levkowetz.com> From: Julian Reschke Message-ID: <766a8834-4e7a-e819-6b76-2682eb99be9e@gmx.de> Date: Wed, 3 Oct 2018 17:08:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <6c9785df-73c0-78ff-0c69-1ea1b369b0e0@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:vSWY55GZH7ewkIN7sMfq8X6t0hQRKfCX2VnYupxC1ZCefpFLtdi dgRnI1OhMAoG3JnOYIdZp9Wle+BtXS8OVlsMKbAa0EX7hSH0AeEngIRrhccCjpJi/ZpEEZ/ topwK0HUPqst816+wcnCO+6Fw8U13+6isQlvatClp+sSsMLHVwdWi83HdF1KS2mgIEYBEJK L0kEUEuhd+H4n3tXop7GA== X-UI-Out-Filterresults: notjunk:1;V01:K0:HbmZZ1d7DYQ=:F2XqjJrIkFY4Hf9X/RhhB7 ridxozVtgNvAiD47XqIRHPgM/gCwfesejb8K35NwWLmWqBmNqQ8VkWyf2xdJFUjGD1U74ci+Z bhSsY63e9fOS8CIuhpPtnNCNKTmcsHwLKKp2sfg1Qa209doAyhepdcgHEuGYBxJKHSWIcfgg3 gJZ0hdWsiRl4Q4WdWLfduT2fzI03dX0q/NjLv91eM2GCFEh3mEPF/THArKNCZXVyd99PqEo8y Ul8rN1+OEoF8jD0oQHtldgc7CqLOJIolhmfq+oz1orNFWfDJkdBQz6S44t2ISwg5r4zXOuRxK DeBSjhCCGpSyXb7twgjQFzlANGtREONM/rx15NsLHletNNG/4LimGY5Sn7ACFkzmzUiGg/00F MWUj7c+WRAAdPp1yizwcHwCKunwjd9BHcL8q2vgfp3F3UtqONYVU+6LnPpVXZdbeMy1hi1mjJ ZarMANRafDz5KVEgOibFskc6iPFFePxvTgsSkpAwJUdgo/O2yP63iqfnm8k2E1Ggd8o7LgrOY uCWnYqo3WkZdsbSZRbxeLopCM1gfaXyZbKfxcsZXxVs7RdR/XISWxoYFyqZmN8zE3KHRPNyRA 8WBCTBxZCRmyDJ0k6JTIgEplQAGkQe/F7OT+uB+KbNkOfM4kR+XZlNciOkHmgpDU9D8u4hFB0 OdRuaZcBOCUXISYWM5tBB9s32LLLKh5rE98SG6VUiiSmtiQIh8cZFfkkaJg9YiyTzvbJdCmMy vIzI/KSEliBracQW1fG7DsZ9JlQhAeeyLaT9bGiZ282GJ8noe6M+t2HuqXfvxreJWTf0wofUs KQZoSbzKjr6cGJPMiWIH6+6h0ZtiL1HlylAXxM9gQh0SOnOt78= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 15:09:00 -0000 On 10/3/2018 2:53 PM, Henrik Levkowetz wrote: > Hi Julian, > > On 2018-10-03 14:19, Julian Reschke wrote: >> On 10/3/2018 2:13 PM, Henrik Levkowetz wrote: >>> ... >>> 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
    to make this come out right? >> >> 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
    . > > Now, the new v3 feature which cost absolutely most extra work to > implement, by far, was the addition of table rowspan capability. I feel your pain. > 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? Example, please? > 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 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... > ... >> 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. > > 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? Yes. > Might there not be other cases? Maybe it would be better to permit it, > 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 nobody Wed Oct 3 16:10:53 2018 Return-Path: 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 40FB3130DBE for ; Wed, 3 Oct 2018 16:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 9n8FMAKCYVpX for ; Wed, 3 Oct 2018 16:10:49 -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 6312912F295 for ; Wed, 3 Oct 2018 16:10:49 -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; Wed, 3 Oct 2018 16:10:47 -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; Wed, 3 Oct 2018 16:10:47 -0700 From: Paul Hoffman To: XML Developer List Thread-Topic: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, New Section 2.20.4, "indent" Attribute Thread-Index: AQHUW25RVNodvNBASkC/qGHgbOIgoA== Date: Wed, 3 Oct 2018 23:10:46 +0000 Message-ID: <3FC3AF27-D05C-414C-BC64-776DDCCD1100@icann.org> References: <02bc01d45ac5$7ae71a10$70b54e30$@augustcellars.com> <030e01d45b29$1c7b33d0$55719b70$@augustcellars.com> In-Reply-To: <030e01d45b29$1c7b33d0$55719b70$@augustcellars.com> 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=_4EF01915-A31D-4002-B3E5-4A1D0FB168A0"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, New Section 2.20.4, "indent" Attribute 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 23:10:51 -0000 --Apple-Mail=_4EF01915-A31D-4002-B3E5-4A1D0FB168A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 1 Oct 2018, at 4:36, henrik@levkowetz.com wrote: > This captures an issue noted during implementation, also described in > = https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation#sect= ion-3.1.4 > > --- > New Section 2.20.4, "indent" Attribute > > The deprecation of the "hangIndent" attribute on leaves no > opportunity to control the size of the hanging indent. In some > definition lists, it is desirable to have a wide indentation, in = order > to clearly show the terms, in other cases it is more important to = allow > for a larger text volume than the width of the terms would allow. > > Recommendation: Add an "indent" attribute on
    to control the = size > of the hanging indent. > > Implementation: The current version of xml2rfc does not support = the > attribute, but has all the underlying functions = needed > to apply such an attribute. Internally, an = indentation > is calculated based on length of the
    text and = the > settings of some of the other attributes. This could be done where the value of the "indent" attribute is always = em units (from CSS). --Paul Hoffman= --Apple-Mail=_4EF01915-A31D-4002-B3E5-4A1D0FB168A0 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAwMzIzMTA0NlowIwYJKoZIhvcNAQkEMRYEFMlcg4yh5XgbFnodvrBG232p3KBYMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQAL3JVOKpprBce+Q5UNI3jMRdHkKXE8wpYwXOMIS1l4WlYyJHQvvMMH2YbvjRN1/7Hofo38 b7bfLJUYq9nnUQPziKf6omMaIIkLHPLP3Blpo+RRAjWx6UkCbjMQ/JsF58UcWxAMn++ihTIcel7Q m0G37dwSWw0L0gm54ioq73lNXFk9Ot8NbPyaJxKpo9UKf9x6Y3lBvo/jIIT26aRvy3z0HuGA3EUj ShnnT3L5Xx0erQrDRjOv2CjP6exhpabBzf986REy4g/6bJUqxYZjF+ncmaNC3kTijillTuN1KPkT OB2T1MSrejKeoCv8VyjV3kAOYDJHTDwOgzNhcNdiNhjiAAAAAAAA --Apple-Mail=_4EF01915-A31D-4002-B3E5-4A1D0FB168A0-- From nobody Wed Oct 3 16:14:02 2018 Return-Path: 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 41B45130DC3 for ; Wed, 3 Oct 2018 16:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 A0imYvyW9VZB for ; Wed, 3 Oct 2018 16:13:57 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EE7812F295 for ; Wed, 3 Oct 2018 16:13:57 -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; Wed, 3 Oct 2018 16:13:55 -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; Wed, 3 Oct 2018 16:13:54 -0700 From: Paul Hoffman To: XML Developer List Thread-Topic: [xml2rfc-dev] RFC 7991 issue #38: Schema Issue, RFC 7991, In Section 2.20,
    Thread-Index: AQHUW27Ai5A1Ix4rYk+DCMo/QGL27g== Date: Wed, 3 Oct 2018 23:13:54 +0000 Message-ID: References: <02bc01d45ac5$7ae71a10$70b54e30$@augustcellars.com> <030e01d45b29$1c7b33d0$55719b70$@augustcellars.com> <3FC3AF27-D05C-414C-BC64-776DDCCD1100@icann.org> In-Reply-To: <3FC3AF27-D05C-414C-BC64-776DDCCD1100@icann.org> 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=_3912B90B-58CA-43D3-B8FC-ED8409FC9308"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #38: Schema Issue, RFC 7991, In Section 2.20,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 23:14:00 -0000 --Apple-Mail=_3912B90B-58CA-43D3-B8FC-ED8409FC9308 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 1 Oct 2018, at 4:35, henrik@levkowetz.com wrote: > This captures an issue noted during implementation, also described in > = https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation#sect= ion-3.1.3 > > Specification: https://tools.ietf.org/html/rfc7991#section-2.20 > > --- > In Section 2.20,
    > > The current specification says: > > "The "hanging" attribute defines whether or not the term appears = on > the same line as the definition. hanging=3D"true" indicates = that the > term is to the left of the definition, while hanging=3D"false" > indicates that the term will be on a separate line." > > This does not match established typographic terminology. In = typographic > terminology, "hanging indent" describes the case where the = indentation > of the second and subsequent lines of a paragraph is greater than = the > indentation of the first line. Whether the definition in a = definition > list starts on the first line or not has nothing to do with the = presence > of hanging indent; our definition lists will _always_ have hanging > indent. > > The 'hanging' attribute also describes something different from = what the > term has been used to describe in the version 2 vocabulary. This = will > be confusing to users. > > A more descriptive name for the attribute we're talking about would = be > 'start-definition-on-first-line', but that's unwieldy. Maybe > 'newline=3D"false"' to start the definition on the first line, or > something like 'definition-start=3D"first"'? > > Recommendation: Change this to a different term that is more > descriptive and does not use typographically = incorrect > terminology. > > Implementation: The current version of xml2rfc still uses = "hanging". I like the idea of changing this to "newline" with boolean values. --Paul Hoffman= --Apple-Mail=_3912B90B-58CA-43D3-B8FC-ED8409FC9308 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAwMzIzMTM1NFowIwYJKoZIhvcNAQkEMRYEFFMzLRqB3XnKFS9kFxDbRFCU3djrMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQAYEGzHp/7pV9Il4iijXqBd6fJpcbjJPJ23l+rT3cbyTj1WECH/jRpvt08svnc9LPrvjAmb ieyHorXWvunKcLL3NWAEFbyfIHpNwI7/RmN/5HlpwA0YRZc3xp76ELFiGYH1fZtt0mkR3faOQiSQ HNeoKkSpwpiMHC4Zbxkj3s7A4XfDoADuZRh3FgWUlMA8JH0YJ/XmiVF3eKyVs1DSZbk3don75GEz iSFF97CX4Jbz/mUCy9A2jsYG/WiHp6p8V5hRy5WqRgqKqGwLidz+9YtqeyJ5GujhyG3eGIOHsQmO mtyXlHY8jO3e2ldavuc50rEtVFpqf9f+MHosWPrXDEA0AAAAAAAA --Apple-Mail=_3912B90B-58CA-43D3-B8FC-ED8409FC9308-- From nobody Wed Oct 3 16:17:28 2018 Return-Path: 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 430FC130DC9 for ; Wed, 3 Oct 2018 16:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 XmF7I-GPrnmJ for ; Wed, 3 Oct 2018 16:17:22 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A815A130DBE for ; Wed, 3 Oct 2018 16:17:22 -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; Wed, 3 Oct 2018 16:17:20 -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; Wed, 3 Oct 2018 16:17:20 -0700 From: Paul Hoffman To: XML Developer List Thread-Topic: RFC 7991 issue #35:
  • can't contain a block quote Thread-Index: AQHUW287pNj9D3OWj0yZgqafJEPevw== Date: Wed, 3 Oct 2018 23:17:20 +0000 Message-ID: <39D3AA2F-E6C0-4648-9764-9ADE7644477E@icann.org> 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=_50BB4D26-160E-43FF-BD5B-1AB65FD6F27C"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: [xml2rfc-dev] RFC 7991 issue #35:
  • can't contain a block quote 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 23:17:27 -0000 --Apple-Mail=_50BB4D26-160E-43FF-BD5B-1AB65FD6F27C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii (=46rom Miek Gieben) The
  • element https://tools.ietf.org/html/rfc7991#section-2.29 can = contain quite a bit of block elements, except
    (among others = I think). Why? In v2 xml ones usually works around this by mimicking the layout by = abusing another element. Seems strange to do this here as well.= --Apple-Mail=_50BB4D26-160E-43FF-BD5B-1AB65FD6F27C Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAwMzIzMTcyMFowIwYJKoZIhvcNAQkEMRYEFLrM1geNa0fvLuO2+WrC+Oa303B9MIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQBkpIWsMzPNX8Mw4Ge5Pjv1thnXZzqLpCxxdBTMF/+QTleteK5XV31E4AtjrA/9C9sh9nOR HJ1d7ceq9XC7JJ31JvNvx1RiOAllwvUVJdn3v+1QuH+99W02k8Bb+WN3e+HGG5piK2e30fyAQQBo eCXRoOc34FePFzUPsJ9TyWOxUefiHxidtof5drkfCM5Nhpeh/FlQi8sJi0opRhfp3tRPBBCTM7j9 7XMXKOmqNRujNutkod9iv/MU8VVeJNgHnLO3RUkj1MNn2ngRWcrlZIkmGuqq8Z3JYWVQSJByiwR0 lXtLFAWmYtc2LzuR8LfNoF26ftnKYHrjlWLFL2RXQyxbAAAAAAAA --Apple-Mail=_50BB4D26-160E-43FF-BD5B-1AB65FD6F27C-- From nobody Wed Oct 3 16:21:13 2018 Return-Path: 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 A1CFB12F295 for ; Wed, 3 Oct 2018 16:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 93b2Rpm15qom for ; Wed, 3 Oct 2018 16:20:56 -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 EEE72126F72 for ; Wed, 3 Oct 2018 16:20:55 -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; Wed, 3 Oct 2018 16:20:53 -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; Wed, 3 Oct 2018 16:20:53 -0700 From: Paul Hoffman To: XML Developer List Thread-Topic: [Ext] [xml2rfc-dev] RFC 7991 issue #35:
  • can't contain a block quote Thread-Index: AQHUW287fiNrVnOdUEmIW02STMsMvKUOne+A Date: Wed, 3 Oct 2018 23:20:53 +0000 Message-ID: References: <39D3AA2F-E6C0-4648-9764-9ADE7644477E@icann.org> In-Reply-To: <39D3AA2F-E6C0-4648-9764-9ADE7644477E@icann.org> 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=_6196B9AE-BD87-4643-A795-7F3E3E62CB2D"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #35:
  • can't contain a block quote 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 23:20:58 -0000 --Apple-Mail=_6196B9AE-BD87-4643-A795-7F3E3E62CB2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > The
  • element https://tools.ietf.org/html/rfc7991#section-2.29 can = contain quite a bit of block elements, except
    (among others = I think). Why? >=20 > In v2 xml ones usually works around this by mimicking the layout by = abusing another element. Seems strange to do this here as well. If I remember correctly, the idea was that list items are already = indented, and indenting blockquotes in a list item might cause weird = output. In retrospect, that doesn't seem like a great argument. Does anyone still want to prohibit blockquotes in
  • ? --Paul Hoffman --Apple-Mail=_6196B9AE-BD87-4643-A795-7F3E3E62CB2D Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAwMzIzMjA1M1owIwYJKoZIhvcNAQkEMRYEFAE1qNJa/9NLAQ4S4RoadvW5SV25MIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQBOsSHwwHv58eJOSNt0+SoM5vDUpvZM37A4ESaPSm3z6aCtS3j7pToTnHbsvZaQQQe9cDnD DJ/6I4QTGn1+vEhwhoLTw+ZahDlazcQyRcjKRKrj8IetZcaq/AoAH7gfWdpLnFVfhc8WfWmi4BNO B8YLoobUOtaNT0MMI14wg4a0TPx0Ff7hjxNNxsbXY9cz6PL46pXKOKJzICSLvx5XGM3nhxsMjHTK moZv+0yxvdmTIMZoiGN2bYDb6uvn+3EXF4L47VW+0sNxLJCRkpPIuFk+ISWxMine5gYcNYLdVlWF GptvF9kHP+6LZrSausf/Lco67C0zK2UWPY6kptUNgW9oAAAAAAAA --Apple-Mail=_6196B9AE-BD87-4643-A795-7F3E3E62CB2D-- From nobody Wed Oct 3 16:29:15 2018 Return-Path: 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 C3DA1130DC9 for ; Wed, 3 Oct 2018 16:29:12 -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 jPlb_zjEBHJP for ; Wed, 3 Oct 2018 16:29:11 -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 70A42130DC3 for ; Wed, 3 Oct 2018 16:29:11 -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; Wed, 3 Oct 2018 16:29:09 -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; Wed, 3 Oct 2018 16:29:09 -0700 From: Paul Hoffman To: XML Developer List Thread-Topic: RFC 7991 issue #34: src and content confusion Thread-Index: AQHUW3DirH0xQy+ho0mnIH+ol+6hnQ== Date: Wed, 3 Oct 2018 23:29:08 +0000 Message-ID: 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=_25862CDE-E0BC-4BD8-ADF4-F8E70C9AA8A9"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: [xml2rfc-dev] RFC 7991 issue #34: src and content confusion 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 23:29:13 -0000 --Apple-Mail=_25862CDE-E0BC-4BD8-ADF4-F8E70C9AA8A9 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii (From Miek Gieben) Section 2.5 Alternatively, the "src" attribute allows referencing an external graphics file, such as a vector drawing in SVG or a bitmap graphic file, using a URI. In this case, the textual content acts as a fallback for output representations that do not support graphics; thus, it ought to contain either (1) a "line art" variant of the graphics or (2) prose that describes the included image in sufficient detail. And later: It is an error to have both a "src" attribute and content in the element. --Apple-Mail=_25862CDE-E0BC-4BD8-ADF4-F8E70C9AA8A9 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAwMzIzMjkwOFowIwYJKoZIhvcNAQkEMRYEFGcZzdMBYRlvhfCBjtLadyv8cyACMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQCkTuEjPF4wKhYcQ+bWxzapEmiuqW4YeLTlKMmjgELmX6tCEYmWSKtm/ujhvV1A5pXBPnkj +uARBNChELNUfB6yIdgoUnj56fFfbdQOjWd5hlN3CNJLlxqC+tjECOlDYSeKk1kbIEjGGg9uq03E a0YuLEPxBGsNtNcD5hR0iAjw5lyLeVOptY8Z1o+UzpQGpxTnu13VOo7EjygnZ0C8lxt6C53oIBK8 T3wxKTpPb0JdFFgnwEPtFtEh7yzETGntLwDqrxQISzcHALp1ZHffg3zmEljpZQi+p2CSvCRfzZpp rD8vVleaq+3woGiuJ8pJyn4BAK9UvqUjqQW6uIVRpspCAAAAAAAA --Apple-Mail=_25862CDE-E0BC-4BD8-ADF4-F8E70C9AA8A9-- From nobody Wed Oct 3 16:33:16 2018 Return-Path: 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 EFBFE130DC3 for ; Wed, 3 Oct 2018 16:33:14 -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 3giZDag1mX-k for ; Wed, 3 Oct 2018 16:33:13 -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 502F9130DBE for ; Wed, 3 Oct 2018 16:33:13 -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; Wed, 3 Oct 2018 16:33:11 -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; Wed, 3 Oct 2018 16:33:10 -0700 From: Paul Hoffman To: XML Developer List Thread-Topic: [Ext] [xml2rfc-dev] RFC 7991 issue #34: src and content confusion Thread-Index: AQHUW3FxrOFfTu1Ep0uTl65AVFRyJQ== Date: Wed, 3 Oct 2018 23:33:10 +0000 Message-ID: References: In-Reply-To: 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=_A0BBF203-7ADA-4D1D-808A-0BB224FA0EA5"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #34: src and content confusion 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 23:33:15 -0000 --Apple-Mail=_A0BBF203-7ADA-4D1D-808A-0BB224FA0EA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Section 2.5 >=20 > Alternatively, the "src" attribute allows referencing an external > graphics file, such as a vector drawing in SVG or a bitmap graphic > file, using a URI. In this case, the textual content acts as a > fallback for output representations that do not support graphics; > thus, it ought to contain either (1) a "line art" variant of the > graphics or (2) prose that describes the included image in sufficient > detail. >=20 > And later: >=20 > It is an error to have both a "src" attribute and content in the > element. Yeeps. That later sentence seems wrong, particularly when you look at = the "alt" attribute: 2.5.2. "alt" Attribute Alternative text description of the artwork (which is more than just a summary or caption). When the art comes from the "src" attribute and the format of that artwork supports alternate text, the alternative text comes from the text of the artwork itself, not from this attribute. The contents of this attribute are important to readers who are visually impaired, as well as those reading on devices that cannot show the artwork well, or at all. --Paul Hoffman --Apple-Mail=_A0BBF203-7ADA-4D1D-808A-0BB224FA0EA5 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAwMzIzMzMxMFowIwYJKoZIhvcNAQkEMRYEFCkYqer65CopxR8N2Xj5+6WKlR31MIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQBuFF34l5IJVUf25MN673qvzDsViJ5eTMDmrU1NaTTT2+tPXvXywg4haMtlfrRzT8aMwanz 6G9DpBmHnJBtqAnQ/I5MH7p0yiVmBT1Z8CnGl955hNvRbXuRhprOxFj1Z99y173vuW2WYfgjYC+h c9kf3uGs7mvRxRmaLd4UJBmFfrEdqLd0VSDLSv9P17QOhqEvmwb/tROZj6RuKFExUdP9R6MhXre1 2QcrvfPxGyD70hSpB5RZ4UPfv32BwgtU3AHcdw2wY6u5BS5A0J3HZVAbmzo0KV+KqDTE4SV+c13H F2WGTUdT6ZU2e3OGEvSr2h8HqnsxDJyYoDNgqRhFVBCNAAAAAAAA --Apple-Mail=_A0BBF203-7ADA-4D1D-808A-0BB224FA0EA5-- From nobody Wed Oct 3 16:48:47 2018 Return-Path: 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 A2F2212F295 for ; Wed, 3 Oct 2018 16:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 grRj60re8sJP for ; Wed, 3 Oct 2018 16:48:43 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFECD130DC3 for ; Wed, 3 Oct 2018 16:48:43 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:65442 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g7qsk-0001hg-Ky; Wed, 03 Oct 2018 16:48:43 -0700 To: Julian Reschke , Paul Hoffman , "xml2rfc-dev@ietf.org" References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> <6c9785df-73c0-78ff-0c69-1ea1b369b0e0@levkowetz.com> <766a8834-4e7a-e819-6b76-2682eb99be9e@gmx.de> From: Henrik Levkowetz Message-ID: <81f488c3-1caf-a7cc-dc38-c39b3ca2ba5a@levkowetz.com> Date: Thu, 4 Oct 2018 01:48:28 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <766a8834-4e7a-e819-6b76-2682eb99be9e@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VON00q1p44OGc664PnkowruWimbb6wcVN" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, paul.hoffman@icann.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 23:48:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VON00q1p44OGc664PnkowruWimbb6wcVN Content-Type: multipart/mixed; boundary="fHBWp2hWTEWK1Kxfi5hkBU5ONFxNMbg0E"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , Paul Hoffman , "xml2rfc-dev@ietf.org" Message-ID: <81f488c3-1caf-a7cc-dc38-c39b3ca2ba5a@levkowetz.com> Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> <6c9785df-73c0-78ff-0c69-1ea1b369b0e0@levkowetz.com> <766a8834-4e7a-e819-6b76-2682eb99be9e@gmx.de> In-Reply-To: <766a8834-4e7a-e819-6b76-2682eb99be9e@gmx.de> --fHBWp2hWTEWK1Kxfi5hkBU5ONFxNMbg0E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-10-03 17:08, Julian Reschke wrote: > On 10/3/2018 2:53 PM, Henrik Levkowetz wrote: >> Hi Julian, >>=20 >> On 2018-10-03 14:19, Julian Reschke wrote: >>> On 10/3/2018 2:13 PM, Henrik Levkowetz wrote: >>>> ... >>>> Yes, I've run that through the current text processor, and I particu= larly >>>> looked at it when working on table rendering. >>>> >>>> Where is it you need
    to make this come out right? >>> >>> In the titles, at least if we want to reproduce what the RFC has. >>=20 >> Thank you for that. It provides much better understanding of the case= >> which prompted the introduction of
    . >>=20 >> Now, the new v3 feature which cost absolutely most extra work to >> implement, by far, was the addition of table rowspan capability. >=20 > I feel your pain. >=20 >> 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= ? >=20 > Example, please? Umm? Take the table you pointed at, give each header cell rowspan=3D"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. >> And second, why is this a concern in a column header, and not, for ins= tance >> in the document title? >>=20 >> This is the result of a too long document title today (an actual examp= le >> as rendered by the v3 text renderer): >>=20 >> --- >> Network Working Group H. Levkowe= tz >> Internet-Draft Elf Tools = AB >> Intended status: Informational 3 October 20= 18 >> Expires: 6 April 2019 >>=20 >>=20 >> Implementation notes for RFC7991, "The 'xml2rfc' Version 3 >> Vocabulary" >> draft-levkowetz-xml2rfc-v3-implementation-notes-04 >=20 > In the past, we have worked around that by using non-breaking spaces=20 > where we want to keep things together. I doubt that the same approach=20 > would work well in narrow table cells... Why not? There's no mathematical difference between the two cases. >> ... >>> 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. >>=20 >> 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? >=20 > Yes. Ok, good. In that case I really don't understand why
    wasn't provide= d for document titles (and section titles, too, where I've also come across= similar issues for long titles). =20 >> Might there not be other cases? Maybe it would be better to permit it= , >> and maybe (at least in some cases) issue a warning? >=20 > 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 iterati= on, 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= =20 > is currently used. Yes, that would provide additional meaningful data. Best regards, Henrik --fHBWp2hWTEWK1Kxfi5hkBU5ONFxNMbg0E-- --VON00q1p44OGc664PnkowruWimbb6wcVN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu1VU0ACgkQTptXS4+7 FxrnYw/+Ot8rmpY1jdpCWv+o7g9EuUTBXYi1sLjIk937J9rxr9ud7ZkYhGeuxEGg zZZamsB3CFJBc2g5LUjhq9go68PVAcJjUmy7k5NJ5Bz2HDEWFrNJfaAecX9Rqv4v YSywpt9ZNVuYu623HSrXLzMLLS6jWzaFj2OK8J4WZhc5yc1di2NrZImh+tUcB4ac 7N2alowdUcH5dFh530T6MnlBDW9GskK8BjN007lMYFyZkaEeydX/0EJo2e2Kh9Oq Lvd4fmnDo5IVaXJvJQhbRgSw5lTys0DNSoqJvkxEqMMqjA2zgnlr12ZL30nP2UhA xTNKdX+l3wM75n+kXljOIFeXPSO1BsUw5t2s2ARSj5UNr6YJNMXGfQHJji5o8iQY AS6KyzmWdCeBt6y3BqIC8FoaKkcJnA2cehM9jAJYpQWj9XnT3OelWL2RqOgVWxS9 Vypc8vXRU92szblhmF2Xj0sIkw+JklRi/lS6NRxqEeNnyILVJFKnQHJO46mgsZUX kXIQItrRpmZx/p3QRPJQ4DZ7t8j7NCSaBxmDe3++QTwkaQG0pMvWMTe1L22rbHx/ euKxzztjTTvwKdr2EzsewwE+1kqczt8sIYlVhQuy9Gj6HL0QW1pEuu89Yt/NR3fT VJJjU1fHUqwvaiJzanL9RZCC2Qz6ngIxmtLbek3DLW0Z2RPNynE= =izAX -----END PGP SIGNATURE----- --VON00q1p44OGc664PnkowruWimbb6wcVN-- From nobody Wed Oct 3 16:57:41 2018 Return-Path: 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 A0F38130DC3 for ; Wed, 3 Oct 2018 16:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 uaI6e1vI8iaX for ; Wed, 3 Oct 2018 16:57:38 -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 368AB12F295 for ; Wed, 3 Oct 2018 16:57:38 -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; Wed, 3 Oct 2018 16:57:35 -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; Wed, 3 Oct 2018 16:57:35 -0700 From: Paul Hoffman To: Henrik Levkowetz CC: "xml2rfc-dev@ietf.org" Thread-Topic: [Ext] Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    Thread-Index: AQHUWcZrZRdH3nQhUk2ULg6uUQuXT6UNt9AA//+y95aAAAarPoAACyDSgAC3OBCAAHe1gA== Date: Wed, 3 Oct 2018 23:57:34 +0000 Message-ID: <2DE9A77A-0306-4F2E-B8D3-19D7915E73FC@icann.org> References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> <6c9785df-73c0-78ff-0c69-1ea1b369b0e0@levkowetz.com> <766a8834-4e7a-e819-6b76-2682eb99be9e@gmx.de> <81f488c3-1caf-a7cc-dc38-c39b3ca2ba5a@levkowetz.com> In-Reply-To: <81f488c3-1caf-a7cc-dc38-c39b3ca2ba5a@levkowetz.com> 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=_5C0A1EEE-C22A-4C1E-9FE1-2946C4ADA2B7"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [xml2rfc-dev] [Ext] Re: RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 23:57:40 -0000 --Apple-Mail=_5C0A1EEE-C22A-4C1E-9FE1-2946C4ADA2B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Skipping some... On Oct 3, 2018, at 4:48 PM, Henrik Levkowetz = wrote: >>>> 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. >>>=20 >>> 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? >>=20 >> Yes. >=20 > Ok, good. In that case I really don't understand why
    wasn't = provided > for document titles (and section titles, too, where I've also come = across > similar issues for long titles). Because putting a
    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
    Datagrams" or even . "of Generating
    Datagrams" --Paul Hoffman --Apple-Mail=_5C0A1EEE-C22A-4C1E-9FE1-2946C4ADA2B7 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAwMzIzNTczM1owIwYJKoZIhvcNAQkEMRYEFL3IY/hb28p3vj1czm60vQTlccKuMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQB8Sy5dwXKYoMzQ8j1/8V5emruLLmEU6UyTWwAbs9MsToplisOIkhOwpFrQLPP5ceMeJlAL 9f8g2lfefj4Kja6ZjInUhN2+Aly5sxThyXUe7qlT5SPYWKdU/0/OGBFwBrw9+kGTMi/KTUuw7/ND qn6/AzqNxQZOkrhWytzJbp/7u3J6lcV8nYsMLmHgnnpbrS6dr/G0+gdbVm9P+I/RUy0HsMet1l25 bknZEkZyhNYEAqmt27T9wZCyhxPsePmD+rzCtJkqGqBgxHOLeai+qZSSab3IdhSWOkHY6n7OJR9g iOX6IuhFUsiKv9x6ZB6r2/2PxaSbAEmXEbU2qhooGTmMAAAAAAAA --Apple-Mail=_5C0A1EEE-C22A-4C1E-9FE1-2946C4ADA2B7-- From nobody Wed Oct 3 19:23:15 2018 Return-Path: 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 9D65B130DD4 for ; Wed, 3 Oct 2018 19:23:13 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 u7nRSOmBw6C3 for ; Wed, 3 Oct 2018 19:23:12 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 184D0128CFD for ; Wed, 3 Oct 2018 19:23:12 -0700 (PDT) Received: from Jude (192.168.0.11) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 3 Oct 2018 19:18:29 -0700 From: Jim Schaad To: 'Paul Hoffman' , 'XML Developer List' References: <39D3AA2F-E6C0-4648-9764-9ADE7644477E@icann.org> In-Reply-To: Date: Wed, 3 Oct 2018 19:23:01 -0700 Message-ID: <037401d45b89$2dc96ed0$895c4c70$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQNEzNaIx5+IXGuJ9/B6uvqJKShC+wEpTq0foiQuALA= Content-Language: en-us X-Originating-IP: [192.168.0.11] Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #35:
  • can't contain a block quote 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 02:23:14 -0000 > -----Original Message----- > From: xml2rfc-dev On Behalf Of Paul > Hoffman > Sent: Wednesday, October 3, 2018 4:21 PM > To: XML Developer List > Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #35:
  • can't contain a block > quote > > > The
  • element https://tools.ietf.org/html/rfc7991#section-2.29 can contain > quite a bit of block elements, except
    (among others I think). Why? > > > > In v2 xml ones usually works around this by mimicking the layout by abusing > another element. Seems strange to do this here as well. > > If I remember correctly, the idea was that list items are already indented, and > indenting blockquotes in a list item might cause weird output. In retrospect, > that doesn't seem like a great argument. That would be really odd if you did "t blockquote t" as that would actually have an indentation difference. > > Does anyone still want to prohibit blockquotes in
  • ? I don't. jim > > --Paul Hoffman From nobody Wed Oct 3 19:28:20 2018 Return-Path: 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 ECAE2130DC5 for ; Wed, 3 Oct 2018 19:28:17 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 uKinjauy9eFE for ; Wed, 3 Oct 2018 19:28:16 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE803128CFD for ; Wed, 3 Oct 2018 19:28:14 -0700 (PDT) Received: from Jude (192.168.0.11) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 3 Oct 2018 19:23:34 -0700 From: Jim Schaad To: 'Henrik Levkowetz' , 'Julian Reschke' , 'Paul Hoffman' , References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> <6c9785df-73c0-78ff-0c69-1ea1b369b0e0@levkowetz.com> <766a8834-4e7a-e819-6b76-2682eb99be9e@gmx.de> <81f488c3-1caf-a7cc-dc38-c39b3ca2ba5a@levkowetz.com> In-Reply-To: <81f488c3-1caf-a7cc-dc38-c39b3ca2ba5a@levkowetz.com> Date: Wed, 3 Oct 2018 19:28:05 -0700 Message-ID: <037501d45b89$e3562db0$aa028910$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJneuHnr/v7zss5vAhzJBHAbfZkOwKlc/I8AYxBdvwC96tKtwHRLD6/AWGKk5cCjgaQ/wK+otNhAV3fW7kC/GVRgwGTDJtVAY52clAB0G9X5QMfuKvRowd4N/A= Content-Language: en-us X-Originating-IP: [192.168.0.11] Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 02:28:18 -0000 > -----Original Message----- > From: xml2rfc-dev On Behalf Of Henrik > Levkowetz > Sent: Wednesday, October 3, 2018 4:48 PM > To: Julian Reschke ; Paul Hoffman > ; xml2rfc-dev@ietf.org > Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, = In > Section 2.12,
    >=20 > On 2018-10-03 17:08, Julian Reschke wrote: > > On 10/3/2018 2:53 PM, Henrik Levkowetz wrote: > >> Hi Julian, > >> > >> On 2018-10-03 14:19, Julian Reschke wrote: > >>> On 10/3/2018 2:13 PM, Henrik Levkowetz wrote: > >>>> ... > >>>> 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
    to make this come out right? > >>> > >>> 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
    . > >> > >> Now, the new v3 feature which cost absolutely most extra work to > >> implement, by far, was the addition of table rowspan capability. > > > > I feel your pain. > > > >> 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? > > > > Example, please? >=20 > Umm? Take the table you pointed at, give each header cell = rowspan=3D"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. >=20 > >> 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 > > > > 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... >=20 > Why not? There's no mathematical difference between the two cases. >=20 > >> ... > >>> 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. > >> > >> 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? > > > > Yes. >=20 > Ok, good. In that case I really don't understand why
    wasn't = provided for > document titles (and section titles, too, where I've also come across = similar > issues for long titles). >=20 > >> Might there not be other cases? Maybe it would be better to permit > >> it, and maybe (at least in some cases) issue a warning? > > > > Or we can wait for this to become an issue. >=20 > 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. >=20 > > We *could* analyze the set of RFC XML source documents for where > > vspace is currently used. >=20 > Yes, that would provide additional meaningful data. I have a vague memory that Tony did look at this so it might be on the = old discussion group list. Jim >=20 >=20 > Best regards, >=20 > Henrik From nobody Wed Oct 3 21:32:06 2018 Return-Path: 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 C05DC130DD5 for ; Wed, 3 Oct 2018 21:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 my4aCd_daaKo for ; Wed, 3 Oct 2018 21:32:01 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E124D130DD6 for ; Wed, 3 Oct 2018 21:32:01 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:52682 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g7vIu-0007ls-Uu; Wed, 03 Oct 2018 21:32:01 -0700 To: Paul Hoffman References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> <6c9785df-73c0-78ff-0c69-1ea1b369b0e0@levkowetz.com> <766a8834-4e7a-e819-6b76-2682eb99be9e@gmx.de> <81f488c3-1caf-a7cc-dc38-c39b3ca2ba5a@levkowetz.com> <2DE9A77A-0306-4F2E-B8D3-19D7915E73FC@icann.org> Cc: "xml2rfc-dev@ietf.org" From: Henrik Levkowetz Message-ID: <6323b0e6-89bb-6cfa-866d-c4df7a42304d@levkowetz.com> Date: Thu, 4 Oct 2018 06:31:53 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2DE9A77A-0306-4F2E-B8D3-19D7915E73FC@icann.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="A7VN8JD5rc12KqwwWtv7rW7QLqCwEqxpT" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, paul.hoffman@icann.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] [Ext] Re: RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 04:32:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --A7VN8JD5rc12KqwwWtv7rW7QLqCwEqxpT Content-Type: multipart/mixed; boundary="6olwTeGBbvFsd8BrICgHPu2HMTNPGfTUC"; protected-headers="v1" From: Henrik Levkowetz To: Paul Hoffman Cc: "xml2rfc-dev@ietf.org" Message-ID: <6323b0e6-89bb-6cfa-866d-c4df7a42304d@levkowetz.com> Subject: Re: [Ext] Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> <6c9785df-73c0-78ff-0c69-1ea1b369b0e0@levkowetz.com> <766a8834-4e7a-e819-6b76-2682eb99be9e@gmx.de> <81f488c3-1caf-a7cc-dc38-c39b3ca2ba5a@levkowetz.com> <2DE9A77A-0306-4F2E-B8D3-19D7915E73FC@icann.org> In-Reply-To: <2DE9A77A-0306-4F2E-B8D3-19D7915E73FC@icann.org> --6olwTeGBbvFsd8BrICgHPu2HMTNPGfTUC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Paul, On 2018-10-04 01:57, Paul Hoffman wrote: > Skipping some... >=20 > On Oct 3, 2018, at 4:48 PM, Henrik Levkowetz wro= te: >>>>> That is true, but I'm prepared to argue that if they want to enforc= e a >>>>> line break in running text, they are doing something wrong. >>>>=20 >>>> But can we be so sure of that, that it's right to enforce the curren= t >>>> limitation? Had you thought of the case of a document title, above?= >>>=20 >>> Yes. >>=20 >> Ok, good. In that case I really don't understand why
    wasn't prov= ided >> for document titles (and section titles, too, where I've also come acr= oss >> similar issues for long titles). >=20 > Because putting a
    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
    Datagrams" or even . "of Generating
    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
    (in text and pdf because it would not be part of the text; in html, because html search tools already= disregard html's
    ). 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 --6olwTeGBbvFsd8BrICgHPu2HMTNPGfTUC-- --A7VN8JD5rc12KqwwWtv7rW7QLqCwEqxpT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu1l7kACgkQTptXS4+7 FxqyFBAA18n13Qdr2oqlIdPZDy9uvGkC6GAA7crNho/bBFqlBEWb8+t+96TDx21l H/CcCNe7Tm3vIPVabn9R5vKj8e0o981t3i3yEqzE/EnKc1ENDC8ZLhawU22/+E58 gR8sgRhCR2mJsk8Sx1fPcmRrfSaOik6OXiYd/DWeWYaHXBXoLC0eTvVhzbx86N5Q HPC/aD8DBEm6zSrNo7d3WqdaEXv8Vcilsj8/ksYE3lfXXSMQrQid2LFw0tFlcMyn lqLUL6UKKELhA/eBApy+NAa+9HKHVkr3iU2IrMh8Hpcfh2nelgPXfzw1U0CyLSzS 5WfrwI8vJtpkoP6Fu0XJSk83tsDpqZzI3G7YMbiCF57RG4Ei6/TAA6LmeY7PDxLi h6Smt+16N1EJr+4RVLOkAx14oQMvpuzQ+0B0g1beKUw/VvWc+/axrf6+umWdg9ne z8pbWaFcAqnNKmA4Po00ZLxZndynS1rmzlnFAfaWfDnwiRbqIeX/Q+AsDOlKrCil grRflgK5FTfOsLUmGCES5geum5aT3gB43YuMf5hVdfufQ87ITZIKAODi3ArBaDyS pqJvS80ItTvdfrJ7Qs4qFWiVP04IwEYIvbEybFmi99eJaVFO/GnnSCe9gVpA47QZ yhpwW4M/VUwWruSV+o1X6TYgJaRC2fvz8BB1wRQIGvSl3gHiyqM= =x+yP -----END PGP SIGNATURE----- --A7VN8JD5rc12KqwwWtv7rW7QLqCwEqxpT-- From nobody Wed Oct 3 23:30:10 2018 Return-Path: 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 A2279130DE6 for ; Wed, 3 Oct 2018 23:30:07 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=miek-nl.20150623.gappssmtp.com 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 8DdU2WAbvjrZ for ; Wed, 3 Oct 2018 23:30:05 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54B39130DDF for ; Wed, 3 Oct 2018 23:30:05 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id 185-v6so7767791wmt.2 for ; Wed, 03 Oct 2018 23:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=miek-nl.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=SOJYnNV2G/tQb1KFWcvYiXP8TUQDNvridIPYMEtnJXY=; b=C4j96TvGmGtulcAEJtxxaWkSeRJ38jKt6JLZm/uAserQ76wzcw3IjR5g9amFJX0aP5 gIa6ef7JCEuUTXF5kql2ue0qhRuiARQeTsVhmrELkQG7dQAWp+XrVnLMhnpJ167AsVQo 44ZqUAPdo+VUSol0XY0Mhjzmj4xi+vTb9ep0ommlXTNA++qO36qfOKON8vSs8PNRBPoU e3EF1NemvDbDP04/2LnskABS38OgcUgJnpADu1AMiPMTKVDZj2bzQRrRL9CadcLHxDhZ V9FF1UwVeHlbW/raFO99voq8pM35MkuhX2mUwURiBgctaWd2Laz2fwZFooU+MSXYnHPv zSIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=SOJYnNV2G/tQb1KFWcvYiXP8TUQDNvridIPYMEtnJXY=; b=K0JuiHoM83kZSTCpSOjuVAYTB3Nf3o5avUVtpsv0qVpE3Jmfe/uv6ederCGIRfoQsj mTvnbxB+3UaRXjsETSgsJoTgvAC2+RIN03OUFba+LYTx+ZEftNJUdYnEk5uOuYsNBh8q ucaUCf67z+QtkELvvI/XYmlTOaeYj4/9u60wQCFW8DzL5KkX+MLYhsTbtMVzHOq/sSwX wX6zjIC1kxJ6egs5ujHLNfiavDWB2eecjfWBWQU6mZui8IraeDCJzSQgJNkRkcP/wvsZ Tt0cVvvQP4uPYaQNSu0D+ACdqyiRekvyO0CrCjsdskJtb4KEkSKk5l54MnPcHBEv3mTt quEw== X-Gm-Message-State: ABuFfohi38utvtjiIT6smIpCxTib2n74OZ8gAVBq4qI0ypJp3uqJSfRz /EvCwZsDJfJ0LSvJQBQAtez24RBlw7M= X-Google-Smtp-Source: ACcGV63MakFvjDKEgPrcLSQstSTgenmlUmO1uvVGa/+v5PE5xQiFPrS69Ea6Ni2nxiDv7dO/LOgpag== X-Received: by 2002:a1c:96c7:: with SMTP id y190-v6mr3689172wmd.36.1538634603198; Wed, 03 Oct 2018 23:30:03 -0700 (PDT) Received: from miek.nl (4.3.8.0.6.9.c.b.e.5.6.a.1.b.f.a.f.3.c.4.9.5.f.b.0.b.8.0.1.0.0.2.ip6.arpa. [2001:8b0:bf59:4c3f:afb1:a65e:bc96:834]) by smtp.gmail.com with ESMTPSA id j203-v6sm4522775wmd.46.2018.10.03.23.30.02 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 03 Oct 2018 23:30:02 -0700 (PDT) Date: Thu, 4 Oct 2018 07:29:59 +0100 From: Miek Gieben To: XML Developer List Message-ID: <20181004062959.bgyb6sxfzzy63caw@miek.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Archived-At: Subject: [xml2rfc-dev] RFC 7991: issue #41: Target audience for writing XML 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 06:30:08 -0000 Hi all, Forwarded from issue #41: Do we target humans writing XML directly, or it this spec mean to for other languages (i.e. markdown) to compile to? If "humans" would should aim (IMO) for a consistent spec where attribute names are consistent and not that numerous and there aren't a lot of exceptions on where what elements can be used. If we let something compile to XML we could relax this is bit. Although my experience with using markdown is that a lot of the details carry over to the markdown as well; making it easy to generate an illegal document. /Miek -- Miek Gieben From nobody Wed Oct 3 23:36:55 2018 Return-Path: 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 B06D9130DE6 for ; Wed, 3 Oct 2018 23:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 W2juO25J_Yx3 for ; Wed, 3 Oct 2018 23:36:52 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 166CC130DC6 for ; Wed, 3 Oct 2018 23:36:51 -0700 (PDT) Received: from [192.168.178.20] ([91.61.61.129]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MWC9x-1gEJ0h3lJx-00XI3b; Thu, 04 Oct 2018 08:36:47 +0200 Received: from [192.168.178.20] ([91.61.61.129]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MWC9x-1gEJ0h3lJx-00XI3b; Thu, 04 Oct 2018 08:36:47 +0200 To: Paul Hoffman , XML Developer List References: <39D3AA2F-E6C0-4648-9764-9ADE7644477E@icann.org> From: Julian Reschke Message-ID: <43399229-fecd-b74b-2f47-1b811f76f92c@gmx.de> Date: Thu, 4 Oct 2018 08:36:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:PDFBXBrHcquirL6k4iuIhoClMfz6iY20mLUzKtTRsSlhT/E2eIp B7i3mZlggVCva5G9pJgvhayixv611CzOKKRik+eH9poRWPythTa+MFPHmf21w1CsS8x7Y/p /++zBlWX3coBaTwaJuIZe/eBNx6zUFXt3KKXNpB/YG2pAkFAMXoVa9YPFa9zh1NoAzuiRU7 jOcn8+xpMydarEgis3l3w== X-UI-Out-Filterresults: notjunk:1;V01:K0:U+x32iwySJ4=:jkrNzljZnHzaYwtSDHePBd RMUttHMLtkCDztiZohaLg0zJdcCZhM7DdnuL0dvEHQKugkZXApbKisZvc7NBzbyPWsIn/CsGh 5gr+6pV70mGY11K5fvLtPsutwPgpoKhudz/NbiZ9qs6T7fksEzZgzxz/6NoJ1j5pQBXJ7hNfG e6y+u2L91eUTxrM+02lEzp7W7Yb8huusiOY7SgMMSq8BJeksK5GoapTycqRtFSI2QFx8jTB7F Xco+/HM7yiMdQ/EgLczQOM1Qh2pFhC1duRQYlusDlt1z4SeGTBrHCTv/+MXa6cFgYI9jbjkRR 2Jr7ng8A+Nw7YyRPl1Td4Jpo3GwI+DI+1mYUQ67fDiXFUaTR1esmvZQsYMoGD7k0WUL+5KTK1 R/rKKwbfgNt/aK4pxh+zh+gHBauJ14wB7kG48NHK9ss9+M+NrhFsyqXJl8jqPoAKHzWqfiLKh idIF1WBWoCvKobmKzGTwH9sh3fwOIgUfceVnkwQdUWAEQZiBol37lzf0zDlmseG3UFAqcTJjD peMuVh9B6ie7hnsL9/RCJJMiu1PXvmqxMuq7DqzPeuzneChVRJOLM+HOCb13oR90fS5lCSeIu R2voheKRfZoMROw9RYMxKJDez9eKmL978X/RRciqX1JwHlDKfRhRkjHhw+1tAXi3N85FY3dF6 Vg+mPn96NxXsOnp3K91aneB+GRjqk1Q4XUEuV5/L7fueWkALAfrC3IvmsUyAdZUlb5AVUUTPS UAaB9j191MR/QlWJMhZrQywJprP1CBCzMguK2FovrXsXcG+TKcZliMCSvPXGYDQj700l0tvmI PCHKI05b1fA0MWQ1C9mfz4wayWe6W1ZyzBGsDmQFx2j3KSrwwQ= Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #35:
  • can't contain a block quote 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 06:36:55 -0000 On 10/4/2018 1:20 AM, Paul Hoffman wrote: >> The
  • element https://tools.ietf.org/html/rfc7991#section-2.29 can contain quite a bit of block elements, except
    (among others I think). Why? >> >> In v2 xml ones usually works around this by mimicking the layout by abusing another element. Seems strange to do this here as well. > > If I remember correctly, the idea was that list items are already indented, and indenting blockquotes in a list item might cause weird output. In retrospect, that doesn't seem like a great argument. > > Does anyone still want to prohibit blockquotes in
  • ? +1 to allow it... From nobody Wed Oct 3 23:43:04 2018 Return-Path: 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 BFAF4130DE6 for ; Wed, 3 Oct 2018 23:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 fBLVzgygjO5U for ; Wed, 3 Oct 2018 23:43:00 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15BF4130DC6 for ; Wed, 3 Oct 2018 23:42:59 -0700 (PDT) Received: from [192.168.178.20] ([91.61.61.129]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Mfn40-1gK6PL2l6q-00NA6z; Thu, 04 Oct 2018 08:42:23 +0200 Received: from [192.168.178.20] ([91.61.61.129]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Mfn40-1gK6PL2l6q-00NA6z; Thu, 04 Oct 2018 08:42:23 +0200 To: Henrik Levkowetz , Paul Hoffman , "xml2rfc-dev@ietf.org" References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> <6c9785df-73c0-78ff-0c69-1ea1b369b0e0@levkowetz.com> <766a8834-4e7a-e819-6b76-2682eb99be9e@gmx.de> <81f488c3-1caf-a7cc-dc38-c39b3ca2ba5a@levkowetz.com> From: Julian Reschke Message-ID: Date: Thu, 4 Oct 2018 08:42:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <81f488c3-1caf-a7cc-dc38-c39b3ca2ba5a@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:67EnLqxP3XinxMI0STbBJeLmCy+9UKl95psQ/CkQCVbKGg3UMrq rpYU+JK5CyEBu7LIqKKm8bfpRHnEncBvHGMqoatMoHE9zkAF6Dv+WiiQ+XfDLu74a50Qzhq e5y4swamP82oIfMAX/jdgsfvQCSnoiWhfWKpejgTCphkiI8N/XQeybHdwiDyxampPRx99Cu g+jp4K/2VC1LOhkMgh73w== X-UI-Out-Filterresults: notjunk:1;V01:K0:Qu1W1wxfH3E=:aCqeRNLT0ZYLqwoy9+OuaF GjZR67XT/eOqkDb2hBmOUgCOyTPZKcju2cY3/Gq/TRzA++4L2t/qvazLsxHq8joNkTAEYmfeH jBt2u1ZuBxW2mZ3VahQpT/3m3+ckOz73h0O/cxyASgTl6t+km3RT+C7Rhs3/eW2Ah/TgWFZvM E2ZHq976ae+QcYD78fN8F4fR5Ij7cMEyEL59VTeB0q+0omcwQ69TXBNcjt4573MEvCnAweXHm TmkwJUQaxMx5isY9kxmleyQGQQPDpi1u9ySYG5V8YcPs6m2guILZ/TstuU8M5MXVIxGRbR18T Q4zcV76YHF9luG3YGt7Qbi4Jvv7xuor/bi/2vJgHKIN61mcJCjSxiN2xY6KQr6HbaXDJQoV/D T7F24LxbjfzQB/h0lfS+sOAv5nJi8L8cPDvON0K5JTSjVH2PyXq+OTI6CY2TOaVZ4Yq5l/uiU +PObgn+wO2Dts38Zm49aTXjYKQUqcRR6WQpZEgrbQCBLIBR6f1+iVzWrfXwXjj2Xm41iBVz2L op681wBNaT+p+5QUkZ1/K7n5ZnkeVftgXvTV3c3Lg636to1x5+oKlYigpcqCNhL0R/+2tRk/x DXn+uz6kHoJLb+GIK3xWAbhGIuBg5ODKeC/hX70+6YV0tlRpn3y7kVEsohIAOcIIUfBgmX8HY /scLkQNb6JvkvzLH2N1fGAhGG/fXmyKh2aN4r9hp7vIsDetpemzhXAG65H5L0e6Nr4YE5b0lr JoQf7YXg5y2JcrYTQVQXPTbKMqX7p9Sj3lhEiR2P313B88YgMgAw+OduKfEVF+pDK28vfctDG n/grMpCZbr7VqyX7tJlIuOddF0rxgz8w5SDPrFAgzEMBRGQ7tU= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 06:43:02 -0000 On 10/4/2018 1:48 AM, Henrik Levkowetz wrote: > .. >> Example, please? > > 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. 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 >> where we want to keep things together. I doubt that the same approach >> would work well in narrow table cells... > > Why not? There's no mathematical difference between the two cases. 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 nobody Wed Oct 3 23:44:23 2018 Return-Path: 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 65716130DE6 for ; Wed, 3 Oct 2018 23:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 XDr4-ANJZm1D for ; Wed, 3 Oct 2018 23:44:19 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6688130DC6 for ; Wed, 3 Oct 2018 23:44:18 -0700 (PDT) Received: from [192.168.178.20] ([91.61.61.129]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MLOMM-1g8VKB2Nuc-000fEF; Thu, 04 Oct 2018 08:43:41 +0200 Received: from [192.168.178.20] ([91.61.61.129]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MLOMM-1g8VKB2Nuc-000fEF; Thu, 04 Oct 2018 08:43:41 +0200 To: Henrik Levkowetz , Paul Hoffman Cc: "xml2rfc-dev@ietf.org" References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> <6c9785df-73c0-78ff-0c69-1ea1b369b0e0@levkowetz.com> <766a8834-4e7a-e819-6b76-2682eb99be9e@gmx.de> <81f488c3-1caf-a7cc-dc38-c39b3ca2ba5a@levkowetz.com> <2DE9A77A-0306-4F2E-B8D3-19D7915E73FC@icann.org> <6323b0e6-89bb-6cfa-866d-c4df7a42304d@levkowetz.com> From: Julian Reschke Message-ID: <7a3931de-5828-5829-0127-67edfd4de459@gmx.de> Date: Thu, 4 Oct 2018 08:43:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <6323b0e6-89bb-6cfa-866d-c4df7a42304d@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:v1izPASj1trJ4fr/oa3B+N3x7h6i0ANF9TInLMpjHzNpy/gtQGU EtdAnttsO6WTWWNQEQ8mROv6anvOaprOrnkAH6lv37abOHxD02QyZWoK5jVHU0WFRg6VzWT wq6llGRc7gaDpKOSKrAj9tVpavAXro+6z/n5eqYbjx543k+cDzl7nj51+bjI0Fdndha9veW iaridsPZ+dN9KvCDOBFFg== X-UI-Out-Filterresults: notjunk:1;V01:K0:0u8JCplasGg=:c9RgLJQRX++G6qv4eyZH2I QTwi0EOFzW7ejaKbQCS3vS2IbDlw6qZt61Cchu0txNlJ7QFOjC35pweWZGsaAdMB4roXBrADd boCHIMrPFUj6oXOBuWGX2N2gVukmLShjIksM5YIsm0hyR+S/uQJVJVSXa1aGe91p4yMzPEGBn jUTw0dsoC8SVizwtx95W/SpRk7lJdeSyfzrBcrFcH5mCKdaWi2LMUqlBcmsqKcF9+fYk1OeLz iVY7MFgLBUFg5MSh4LtJwW7Qbh2Y6+DcaOq2jQXCJqicKblhPqhFB9RKDo6rhiquWMH2cZLCg E5ndAWOT8dG/8kqMlSGegSMTToRAF03wpSx9VFgzUYV5TAiEE1QRqLzHZpqfD8+BNOEHodDR/ DG22tm0jGlNePFuCZvSIxxCwUfhfhVOtFNzyutBH2Hf04jBCh/IjioQ8vXB+U0JIQ257mN05g UAAR+TFpUgQc9P7APJAvOOgb18vcDI2QSJw+ZEA4A/ycs8oHyge35zuSwu5QISEMn841EmCOM Tpl0hIKUJaMNXST9mJXM0XTuW0QcGIcLXFqRYO0XfuutP+aeyLE31AvqDkQT94+vMfZZ5Rhvm ECd4G2gyIYsUVz/Po5JmAmGB9f/4K4AKmYVPrIRFOaqxcLP/D7y+jCVLyDCztVt+SNoaxo1oJ zKIUskjmbwsFKuLJFI99xKBnTtnHN0u2LuqIorHKz6K06OSZjCnGQbz5gPZJEccLLzLvlsjpi 7H/htLTMkI2I6mMdJWI1/CMCVXCyBzQcSirLsWAQJWgOvPvd3R2IVSP9EbpKK3DY3+lKUcvfA TNWbz6Ra6IgIOOsXWG73EzibSs30JneDvuw7hG3oc16CVrqvRY= Archived-At: Subject: Re: [xml2rfc-dev] [Ext] Re: RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 06:44:22 -0000 On 10/4/2018 6:31 AM, Henrik Levkowetz wrote: > ... > 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
    (in text and pdf because it > would not be part of the text; in html, because html search tools already > disregard html's
    ). > > 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 ,:-) > ... Here I agree with Henrik. Also, why do we allow things like etc in running text then? Best regards, Julian From nobody Thu Oct 4 01:47:04 2018 Return-Path: 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 10459130E07 for ; Thu, 4 Oct 2018 01:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 J6SQPSnaXTOV for ; Thu, 4 Oct 2018 01:46:57 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFE8F130E01 for ; Thu, 4 Oct 2018 01:46:56 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:54055 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g7zHb-0004BN-Of; Thu, 04 Oct 2018 01:46:56 -0700 To: Julian Reschke , Paul Hoffman , "xml2rfc-dev@ietf.org" References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> <6c9785df-73c0-78ff-0c69-1ea1b369b0e0@levkowetz.com> <766a8834-4e7a-e819-6b76-2682eb99be9e@gmx.de> <81f488c3-1caf-a7cc-dc38-c39b3ca2ba5a@levkowetz.com> From: Henrik Levkowetz Message-ID: Date: Thu, 4 Oct 2018 10:46:48 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tvklTfMTahOFOVAR9RWmN6Mp7NFMNpUka" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, paul.hoffman@icann.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 08:47:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tvklTfMTahOFOVAR9RWmN6Mp7NFMNpUka Content-Type: multipart/mixed; boundary="v5Bfv6ONElqHpXCikUsXrcc2ITinPDWX6"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , Paul Hoffman , "xml2rfc-dev@ietf.org" Message-ID: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> <6c9785df-73c0-78ff-0c69-1ea1b369b0e0@levkowetz.com> <766a8834-4e7a-e819-6b76-2682eb99be9e@gmx.de> <81f488c3-1caf-a7cc-dc38-c39b3ca2ba5a@levkowetz.com> In-Reply-To: --v5Bfv6ONElqHpXCikUsXrcc2ITinPDWX6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-10-04 08:42, Julian Reschke wrote: > On 10/4/2018 1:48 AM, Henrik Levkowetz wrote: >> .. >> Example, please? >>=20 >> Umm? Take the table you pointed at, give each header cell rowspan=3D"= 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. >=20 > That would require the table style to have little margins and no=20 > 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. >> ... >> In the past, we have worked around that by using non-breaking s= paces >>> where we want to keep things together. I doubt that the same approach= >>> would work well in narrow table cells... >>=20 >> Why not? There's no mathematical difference between the two cases. >=20 > Because then you'd get overflows when the cell gets narrower than the=20 > longest character sequence that can't be broken. This is not an issue=20 > 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
    . 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)
    makes it much more convenient to get the desired layout in cells than using rowspan and cell-splitting? 3)
    would be better than the use of artwork in order to write RFC 1605, and probably other April 1st RFCs, too? 4) Disallowing
    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
    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
    in _that_ particular title or text. Best regards, Henrik --v5Bfv6ONElqHpXCikUsXrcc2ITinPDWX6-- --tvklTfMTahOFOVAR9RWmN6Mp7NFMNpUka Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu103gACgkQTptXS4+7 FxqXUw//T+iz5QYfVVR/rPOjpi+96UnNYCPebdNBIwkVa4jPYmKfOJ+8Hn+eKoEI 6jOHBRKbsFbOwi3RNqcQVOkK+DDXzeS4FlWFFZg3J5iNpf9vy7NpzqnJ5RLf65N2 rjxnj5Oy/2o7b/WQDap/Fs+9LYJ+q/Lar/yOHbGC8R+o2OVhnEtdxoO+EvMjMs9H 23DYdjq1KFApcWhIYrJ1q7ELF9/0qUXNyG6THZ0/si2gARcKN7h58vCX15rrek+D rB8p+XhB90zKzY8xAfyL7xn2bWcXp0Uw5VjvEVreijtfFCfl9Iioq+UZQwwADt4N NmIeAzDZqK700ysaOIDhNLejQtaQvjkA6wEBVEf++NIcmXmM9Y7Z1u8UBxedhV81 85HRcQ0CQDMZ0SYWtPJ9dH9tUO/FIhS1gP6FiJ3kocVRjnRAK1GS7KVEYPUOdlxN R1LCqT/ofzT8d9a4gBvcxrbJqFC4AQDnxAUm0BJDO+E5ijrf8PJ3DuDassW+UMid XQTCVqQJBLB+i5ss6TuYh1yeVEtaH/io5rJJZ6bxGIHfQdiDL3cxwq91bxk6bUWS +XinhM51ACEuQcFWh2YQOvwakQy7p+YW+/MpZvDWeAL2vk2FCHvrY19WvSn6iPaF f5KbTPT5HTJy/phstkZsDpTgnnE2ky/BzF63xztv0Y8n6GFdx6I= =iupQ -----END PGP SIGNATURE----- --tvklTfMTahOFOVAR9RWmN6Mp7NFMNpUka-- From nobody Thu Oct 4 02:10:11 2018 Return-Path: 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 F0543130E05 for ; Thu, 4 Oct 2018 02:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com 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 1IdV4OHsAGV4 for ; Thu, 4 Oct 2018 02:10:06 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0097.outbound.protection.outlook.com [104.47.93.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1BE7130E01 for ; Thu, 4 Oct 2018 02:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gFiQ3V3L5Vkk/t0ZZp64JDSzOHStnhdsVTUFkYpn4A0=; b=CfPglGlJouys5W1kMW+BDdKN56cxS+RO4tFWUNTkEqszMRtRiEnKCWAOfk9EfjGXB5TMxpXTxF1PB3OwLs4UW1G+nDHLKs9966EL0r3QJaRZpO4YxqhHF5nX4d0OEwtlZdyiddyku4If+2t3pMjq8gNmKHeGTnCtnwRi/EvC+bM= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by OSAPR01MB1540.jpnprd01.prod.outlook.com (2603:1096:603:2e::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1185.23; Thu, 4 Oct 2018 09:10:02 +0000 To: Julian Reschke , Henrik Levkowetz , Paul Hoffman , "xml2rfc-dev@ietf.org" References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> <6c9785df-73c0-78ff-0c69-1ea1b369b0e0@levkowetz.com> <766a8834-4e7a-e819-6b76-2682eb99be9e@gmx.de> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Thu, 4 Oct 2018 18:10:00 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <766a8834-4e7a-e819-6b76-2682eb99be9e@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: KAWPR01CA0082.jpnprd01.prod.outlook.com (2603:1096:402:c::18) To OSAPR01MB1540.jpnprd01.prod.outlook.com (2603:1096:603:2e::19) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6d50b05f-6e13-4542-d312-08d629d92b3b X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7025125)(7024125)(7027125)(7023125)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:OSAPR01MB1540; X-Microsoft-Exchange-Diagnostics: 1; OSAPR01MB1540; 3:xBDBeHTt46AqqqGx8xXL4AIUNRLjHHDW2ZHuYq239mPR75QI4seNnk9ICx/UV/6Ec0uHRL7TLO4MCVJSMmMuhIz46Hh1EC0bGqHUiuQlQb6Q6gtTlVqZlXuP7cx7P7qlzECvAIQqj9K8HdZyaNJxyodYqhR8j0XJ0c9KwSkvmC2obSYtB8gb+VlrrSyAvT+6BeD+q3ULBqL/Xq2ZR+nldjDnUXnGC98S9LY/HG2TRlowby/hMWODaKLr7lmnQMmR; 25:oTFXxjP9SRw6P8B2NnYv495HJCxK3jVtFAYFskepHoD1GEgozU6/O6snAPhzMawRw+CTqlPzISVbKlk2bfa6hizW0kErq+Af4mGhaZjjegCflJFW80LaxYaAklqGURgcxLrsiUd/Hmpc4Ot9LhOF3WIH7T+BGwavbcBbkPKHqBVIZ8YXY0OTbaej6qYrdtU+XylgzhQlmywTLAxFYaL5SsbxWPSZLnitMAFCw+83PS2TCrn7cTIkAD/ehDXAE7CifKQaLVG/10zaUVhmkrcRLVQz81eyOzfuAuBNHCKfXMF68HwZMKpKyjRS98+wmpud7MuRlWzFtBGVsBFBqvW1Gw==; 31:WVj6iCkaT1UhvWGtyUEi/S7GVKqkztojn0YjN2rCR1anYPyYPnE7mBumiS3wMSAUEI7KbrdGsMxuowUUX9ggt2APv+lWFlGg/Ynf+jayFeE8We/IFmmaUFcCKY8OvoJh4S/IGWMpgc7++9sPMAU3JxR5iBjkhJXIOaYGLohfwRDdRyOv3FZUczrSOEU54eAUDJMVP4/O4kSrkuaWmjdzuuKUxHYnj/hlMg8J6LLPPEA= X-MS-TrafficTypeDiagnostic: OSAPR01MB1540: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231355)(944501410)(52105095)(3002001)(10201501046)(149066)(150057)(6041310)(20161123558120)(2016111802025)(20161123560045)(20161123564045)(20161123562045)(6043046)(201708071742011)(7699051); SRVR:OSAPR01MB1540; BCL:0; PCL:0; RULEID:; SRVR:OSAPR01MB1540; X-Microsoft-Exchange-Diagnostics: 1; OSAPR01MB1540; 4:CjqZJ94NYU9hUqsKRj7FRUCNWKzvP2/lMBRa7fiBHYppkBl2TiTaKGuqITvOSnuYMvTp1Zzmo7UApUbsuQ7AKE2/WdN23wN5MLtHLVfiHC/7YyCmX4ebzoy7RG3tcAXzPuVZcLA6A32asWd7lomUc72wcPtXZNtmfnP7HWFSOF30unVw+9MyFs6d4S6DcZRglh4C21cdyba4w/QLiAe/3YmrIpNiLmbb/HxSVA0nfRn/fBb6NXiqQZIfPNV4pOm/HPVeypzqfWCOAwSAzRm++A== X-Forefront-PRVS: 0815F8251E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(136003)(346002)(366004)(396003)(376002)(39840400004)(5383002)(189003)(199004)(31686004)(106356001)(105586002)(53936002)(67846002)(36916002)(86362001)(23676004)(2486003)(52146003)(8936002)(81166006)(81156014)(76176011)(52116002)(8676002)(31696002)(64126003)(305945005)(7736002)(16576012)(229853002)(58126008)(110136005)(93886005)(561944003)(6486002)(316002)(6116002)(3846002)(74482002)(786003)(65956001)(65806001)(66066001)(47776003)(50466002)(26005)(16526019)(186003)(49976009)(476003)(486006)(2616005)(11346002)(446003)(956004)(508600001)(25786009)(6246003)(97736004)(53546011)(65826007)(68736007)(2501003)(2870700001)(5660300001)(2906002)(386003)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OSAPR01MB1540; H:[133.2.210.64]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPU0FQUjAxTUIxNTQwOzIzOjRPTXJXcFlxQVJyVHFJZ2dBWWtkb1BGVVhW?= =?utf-8?B?RnVlR21aWVdxOWY5clZFUFZLdTIyaDRHcTU1R3BBZlVGTWlYZThBN1BJMkNE?= =?utf-8?B?b2Z2aEdOTHhJNmpvTnJkeTMyRmxoc2ROMnhFWm8yVXhhRUNscUc1QzBuc1dm?= =?utf-8?B?bzN5Uktnd0pjdzNGNFdvYXkvZHJzSmZOWnRHMnJkVUFpSTdsSmErKzJ2dXNM?= =?utf-8?B?eW1LaGh1c3J4MS8rQWJkNmlMVG80bjR0T1k0ekpLdG9xRlFyd2pod2p1L0VV?= =?utf-8?B?azVrN1hXN1pQRGZvN2kyRWpZQklOTld3UWV2RGVwVElBZGFGNFBoWjBMb0JB?= =?utf-8?B?Ym41bjZwZVF1bVk5T2NSTUthL255VlBYUHQ1OWNiVlRuNzYrZmZReDE3ai9a?= =?utf-8?B?TXdleElRTlE0MytYSnZYRjdZYkV6VnE5R3g1b2x5TG16bGtxNEU1eE5oQW9n?= =?utf-8?B?Nytpa3hEbzZzajlKektYLzVVLzB3OFNtaE9iK211RG9nNGwxZVZyamd4OGV2?= =?utf-8?B?MnNaK3Z6NHUvU2xiRU85THB3R0Y4bm8rVFFqdXVSRmdqUTc3cGV4VUdvaXNV?= =?utf-8?B?Sk1aOFVkVWdZVTRKYTVGU3ZQWEkxYUNjaENTd0QzNk5FNEVLNjFKdnpFVG1Q?= =?utf-8?B?N1dKdnlteGcyQ2hodmlYK0ZtK3pvMnhqaVlNLzFrQ3ZJMFV6RFJCV2EyckxC?= =?utf-8?B?RXErR3RBcURra0lVSWZjYnFKc21xWG13WFkzZHR2dHZmSlZ4UmljeVg2QVpv?= =?utf-8?B?RUMrMjVmbmdoMmYxelUzSEMzalQ1cGgwVGpIYUtleTdFRXpLZFY5Wjg4Q0Vz?= =?utf-8?B?Z2FxWFNmbzlFdXlhdWlsbHU0b3NuOTNlL0ZIVWd3bS9Tbm94S2xsMlBoTnRN?= =?utf-8?B?WGd0dHJHRVl1eDNpTXpWRk5raWZ3bCtoOE5udUNaOWUwTURvc0NKTXJvUEdR?= =?utf-8?B?NFhiZlYrWEE1NVQ2Mm1aTWtJL1VabzJwWVRkRG84ZW9heWFyenhiMTJZL2ZR?= =?utf-8?B?TkxvazArS0kwZkpDVTE3aEJxUmFxSDA5NWtvN0N1Ym51TUN2NnBKQkJ0UjN6?= =?utf-8?B?MVNUbTlQQnB0dTcrSktNWmF5cWhqZTBjMHpRMm9KU2pIcUZaM1YyRHVXNkJC?= =?utf-8?B?ZG85Vm5uelovUzh0ZCtPemZQN3h3cjQ4QWRsTTU5TW5TZmN1L0pOSEtIdjJH?= =?utf-8?B?ZGJ6dzBpdUU0TVZaOTloZU13NkhYVlNBOUZWdys3blFDd2dtYnI3YlFLTVJY?= =?utf-8?B?ZDNmME16V0xNTjRrOUd6eXVkNklCa1lhZGYvUFQzdUxzLzVLek45RGpnNDVp?= =?utf-8?B?bE9HT1piU1BCY0RFNk9PRWdUdlVxQlp1WHNTcmZvOW1abm9yYXMyZkl4bm55?= =?utf-8?B?Z1NrRkpaYlRkWVdVM2YyZnR1R0p1UlNhRExJUHZqNmZqWWRCQ2xCdnd0c3ZM?= =?utf-8?B?U0ZTOEF6bVBSdzZ6TkQwa3JkSXoxQVVlT3dvZWpJTms1ZFlvOEhCVjRUbVo0?= =?utf-8?B?ajhJR2g5aWs0SmZvakhsV0E1bVhxNDMxd25SUXo0WkRyOFpNbkRMdmJBNHhq?= =?utf-8?B?OGZOY3RFUXBKOHZZWERzMmR5bXJuZE9HNjB4MXhIclZSenI3WU5yYWVIaUYv?= =?utf-8?B?aHMrbi82UlZMRkZJYnJYWmpreTQxYmd6SS9IQnB6R3BpL2ZtYWUzTTdOcnpG?= =?utf-8?B?TVBkYU8vWHZiV2hEYUpFMWlZTUd6NjJyeGlFcGNpTjZDcWY4R3VFN3BxczF5?= =?utf-8?B?TzJjUms2clNYdzl6ZVRYTDlSa280RjU1MkZVZGJzRFBNdG9FQmpteFlKbm5l?= =?utf-8?B?dFZDaUNSUC9DaDRaY0VJd2RwMURwaCt1Qk82TVJ1c2E2K1owemhhdVc1MGV5?= =?utf-8?B?N1AvTTJLc0dKMU9PcVBoRnlMUWJNaGx3Sys5QkxsNDJHRThOVkxPQWNzMjYz?= =?utf-8?B?RjBsSnBiMkhJb2hodklTcjB0KzcxZmtSczN3UkpzcExjV2xycjNzaU5YVXo4?= =?utf-8?B?MmM4MmRaeUtiOVFjV1JiRVp5eEtuSkRXTndjVWNUTW92alRPN2E0dEpDcE9m?= =?utf-8?Q?UOQ/gSUm/0FY2u1wzcWavJFnL?= X-Microsoft-Antispam-Message-Info: 48gM3a9tq+8pWF1H4kwgRH932iZMCnZ5+xWod8fvlfJTfgLeQWtOOsSBQK8Eudl41R4BvnzKDj1qzj/tQHX0RgeEE+PR6s0YnE/sQIF4IbBuhVG57We0hoqXBFHiDyqTIYyoRA6Nu7L4mIJejGiw7JmH7eS5KviZydOe/dIP5ddePpvRAT4tXMNZ/mry0pNMHvhCnTqBskEO4PV92fulasZRY+7s47pbyEpY0NjgBSLeNoAHGRwJqom5AXU6e9KuTNQ4R3OYt6mvfUdsOjSFeYzZDgbRjIY8OnmvsCC4YpWPaqBQReSbpRltjiFkfnPGjecEe+lOw3QvhX0kSxhI7O88GbJ45H3FOhhj3pDZR9U= X-Microsoft-Exchange-Diagnostics: 1; OSAPR01MB1540; 6:CZzutQStqSUvn0a+pyhBl0paP4ZI0jAo4a0MfquoFpQPqiBK9TeCtZNXzoud5J34xfIsmNH7C4y6fwZahz1Z9GBA5Ed/HC7yVaAkMOeaBbAX90jI6r841wAAWsGbmibeI4oGdodUTRfPjvtA3um667OGXUYkniXXwYcjIU8Rs5fh1CUYnsi7zL1bYuVzmzLxLpsXf0c9CojcPgAg5bWmoC4TbVWmM60cuOTgobigIU7I6U9GEbOlxdA/Rmzu6gtNeIB8Y5xEk8uhdYqVSZhMMySRTzQ5uF9+/CAB2U0U8jlm7kGOJ+SW3QMSt53wsLEO18SQrTeXF/ZPIb72YJQCjkA7zUl2vPISHOH8mWeLWO7kZtcneFn+BFr5kRetEFYRIgLswPCnQbYL03RWnmC2aEXKOSXADNr6tt+ygtsZ2H+Ruugl9OAE36N1L6s2ngMsNuDmiqdQsCk4CMK/Jpj2gw==; 5:ow58SIEpyPoWYKY/TrvBf7iSh4fyCOmFk1de2h9aH3d0L5dgyQ6ELxavyF3rgvus1BWeKNEEDkf1+QutPKscCV1IoL68M0IuwUODJiva7tii09we/2frqxxKXuMn9uypKEukNhsOyuGs3CYhpvSFq45lKtNghmckP5QVtXzpyq0=; 7:lMJGiSLvoj/T/3SNi0pOPo1D3/uaeBdKJjDRcdbpgnQo3ExFEOmsX9wtp/MKmou01edi+lYcbPIkc1IM4To7/e89MvJdcxxafqtcMGAoSfgdWLsSS0DrhDx3PGseg8PihBAW+h/s4bYbk6PbtJ/EHIbR4jomjElish546okvGcmEHMsQ/gcSx6V6pHk9WjSL6Z2XNe5P0CtpqI/jtJMHCd4Sq6qXwuAsOtg3lPyVirZx6UBOVMtuQ3ZPdpDZolDr SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Oct 2018 09:10:02.8446 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6d50b05f-6e13-4542-d312-08d629d92b3b X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSAPR01MB1540 Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 09:10:10 -0000 On 2018/10/04 00:08, Julian Reschke wrote: > On 10/3/2018 2:53 PM, Henrik Levkowetz wrote: >>         Implementation notes for RFC7991, "The 'xml2rfc' Version 3 >>                                Vocabulary" >>             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... 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 nobody Thu Oct 4 03:23:24 2018 Return-Path: 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 A72EC130E17 for ; Thu, 4 Oct 2018 03:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 s5H76Tq3uWlx for ; Thu, 4 Oct 2018 03:23:22 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F49130DFB for ; Thu, 4 Oct 2018 03:23:21 -0700 (PDT) Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M7CRe-1flHOl2p4Y-00x584; Thu, 04 Oct 2018 12:22:37 +0200 Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M7CRe-1flHOl2p4Y-00x584; Thu, 04 Oct 2018 12:22:37 +0200 To: Henrik Levkowetz , Paul Hoffman , "xml2rfc-dev@ietf.org" References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> <6c9785df-73c0-78ff-0c69-1ea1b369b0e0@levkowetz.com> <766a8834-4e7a-e819-6b76-2682eb99be9e@gmx.de> <81f488c3-1caf-a7cc-dc38-c39b3ca2ba5a@levkowetz.com> From: Julian Reschke Message-ID: <7029a06a-3da5-909c-5bff-12e050792d1f@gmx.de> Date: Thu, 4 Oct 2018 12:22:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:CRke71HcrgXD25Mh5ta/B51r4LPw97zWk/3aznRRh8mtO+GsZ/l ngb7qKuzflHTSiApBjPgIZ+qg5oxtQg7xh8wyPSlX2aBoeYDehtBPW9sJhhFzDvXurm3nSQ js/Ig82PHCZy9Y54LmaRqcyu4tQn8qDVfSLTkvFlRXX84YBtM1uQi+mkFsfv1DKzVqwFhWM CAFrITxdiWwHwL+lp7wXA== X-UI-Out-Filterresults: notjunk:1;V01:K0:Bp4BJIyymkA=:2PmJSQTzY0iYkbWw3PNL1Y lI3TRr6XNEG+JO3ygf9e040TmCwJgKA+/YrnmENwJfDl7eOj+e6AzDJqIABZkH8hgpvKw0Gob p5brE6VtKBqAw5jYeOhpxkZN3abQeYJblqg0cXDmcB0elmAjB59qQd4nP6QZ4qJhFHUKaI8u0 1oallzCgRjGG+799giHVctzZ4Ze4wJEh4xG5YU9tLvLgj7cFKXA4wzNIblumO7TS+R6zbipkE O2JQLnVpMemafHCPXsy3PlRJ0/ZbiBqEdUrqIT9rXP/BqWykokzxwq7kBbkEKoLebv6vddJ6Q oSfdAYsU4qx/7KQlkeB2XvRNEJeysTaLEDAGBMVDESrT7KbIahz8hGjFGYTjmsMMn83Rq5/LK ZzJScicvEz0pmxVrFzWNlTD6rIRZGpynwIBNKlISNuRZT5Tg/teRfZJdqoftrrfw4OOP8lFd/ 0mND3bCPoUmETGLiWrbqbgFGQwoegqWDKj82eiseIR+L3yjs3sFibaD8vGkwAlwRwsN11DGKf FtWPbsK1hUbTpow8WmBn30LoedeuLo/6SAJTDw3QKgYg28I5FVWCHT6bl/Xz5WMEFPw+kM6oa uPs3HwSm1V95plDxojJ8DpwlL8x6DcyRaza8FhfiuGXnBso11AsewmS4wCcFRh8YatHxo3ytA lui0Xivq2nPJ0Off07zo5bhzOt5GF/6msDxuY4WIIyDh/mIQ6zGajHJvEg4iLGem4bMfVRTeG r83ol+rMpTmIu54Zk8/NtNNf2kWM/QPero8qOGOpf/BAAb+NW9lTCj+uASQj6ctaPu+CV6kFr K/XT/6rmaPHK6h68faT9yvjrLRw1uGjzByLNqe7XMf351h6eiw= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 10:23:24 -0000 On 10/4/2018 10:46 AM, Henrik Levkowetz wrote: > ... > 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? 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. > 2)
    makes it much more convenient to get the desired layout in > cells than using rowspan and cell-splitting? Yes. > 3)
    would be better than the use of artwork in order to write > 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. > 4) Disallowing
    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? 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). > All in all, what do we really loose by permitting
    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
    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 nobody Thu Oct 4 06:01:54 2018 Return-Path: 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 AF224130E4F for ; Thu, 4 Oct 2018 06:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 xf2-vJLQjPtj for ; Thu, 4 Oct 2018 06:01:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10245130E0C for ; Thu, 4 Oct 2018 06:01:51 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:54922 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g83GI-0003tc-77; Thu, 04 Oct 2018 06:01:50 -0700 To: Julian Reschke , "xml2rfc-dev@ietf.org" References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> <6c9785df-73c0-78ff-0c69-1ea1b369b0e0@levkowetz.com> <766a8834-4e7a-e819-6b76-2682eb99be9e@gmx.de> <81f488c3-1caf-a7cc-dc38-c39b3ca2ba5a@levkowetz.com> <7029a06a-3da5-909c-5bff-12e050792d1f@gmx.de> From: Henrik Levkowetz Message-ID: <8344d317-8eb8-53f4-1804-50c421654d30@levkowetz.com> Date: Thu, 4 Oct 2018 15:01:42 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7029a06a-3da5-909c-5bff-12e050792d1f@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2vlLOiHWtbjpe2w7Ttb9BNuAPBd2Xk7pB" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 13:01:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2vlLOiHWtbjpe2w7Ttb9BNuAPBd2Xk7pB Content-Type: multipart/mixed; boundary="HnqUuSLLqnpAiv4h0q5PMUVQUTSQumGXk"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , "xml2rfc-dev@ietf.org" Message-ID: <8344d317-8eb8-53f4-1804-50c421654d30@levkowetz.com> Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> <6c9785df-73c0-78ff-0c69-1ea1b369b0e0@levkowetz.com> <766a8834-4e7a-e819-6b76-2682eb99be9e@gmx.de> <81f488c3-1caf-a7cc-dc38-c39b3ca2ba5a@levkowetz.com> <7029a06a-3da5-909c-5bff-12e050792d1f@gmx.de> In-Reply-To: <7029a06a-3da5-909c-5bff-12e050792d1f@gmx.de> --HnqUuSLLqnpAiv4h0q5PMUVQUTSQumGXk Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-10-04 12:22, Julian Reschke wrote: > On 10/4/2018 10:46 AM, Henrik Levkowetz wrote: > The point being: when we discussed this we decided we don't want to giv= e=20 > authors control over line breaking; except in this specific exception i= n=20 > table cells. 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 decisio= n makes more sense. Because this point is not speaking to any arguments about the usefulness and consistency of
    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 --HnqUuSLLqnpAiv4h0q5PMUVQUTSQumGXk-- --2vlLOiHWtbjpe2w7Ttb9BNuAPBd2Xk7pB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu2DzcACgkQTptXS4+7 FxpmGQ//eksd/AQZmqjVLbekKUu8/FYMUjpcDCc4MnjkC7Zo0ULHLNfw/L+ZqhLh njsGI/aqW9+ttU6DHubCQLZD9xGaRuFY7/jw4q+pAb01vBWxImP0qTZu4XAL+Nl+ 8YuaP8/zkkangBJt5/jJrHrTF3/B6Ks92ZzIXYV2Aop2f0vbVg8jXI/tAtgyJGGv b+3IVvm3jJdZYv2aGKo9GgLPCR99Bi2n8ocdHWv80pT7g3VleuyMuhXaKXfeH00p +as22o8tPfAizulZbcU6+n14PssKkojFxJ3fMpKGvx5Ylv7GuK0DCAeDUUjjs5GV RAX2oX/ZAnYKO2PUDDl2gZcRS8i4J2XOgWSE8Pb1kHQVTiyXt142E8jKlAq6A1OF jYLaTpUljsxUU6qkhxxm4/a1SI4ZiaEwNluqimV48YaDdil941rcMO/7Z+xxuGOR dxWCQucgPljZ+FklZ2p/rTNUUGK0a7qOls9ZSL51uoyhkHljK3gsVbx+oaFMkGTH CuT2IC5VsE4zVIXkeWczzOHkPT3eQkiKzqqcjE0QV+mI7Y36GkoYy5Bd35p0A6ST 34ItLwCx+CpU2kskroey3lJegM5EHgWj+U1OGsSbT5w3gB+B9eTvmhdkC1M1NvtH 7kC3UBvj4ncuuoqSsL+rL3vIbzc8CU/8AmWzDIYFQWe6SnSoND8= =pbON -----END PGP SIGNATURE----- --2vlLOiHWtbjpe2w7Ttb9BNuAPBd2Xk7pB-- From nobody Thu Oct 4 06:33:11 2018 Return-Path: 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 CCD0A130E0C for ; Thu, 4 Oct 2018 06:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 UUFwjVjcZ5cQ for ; Thu, 4 Oct 2018 06:33:08 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFEDA128CE4 for ; Thu, 4 Oct 2018 06:33:07 -0700 (PDT) Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Ltqmn-1fh4c40VML-0119HV; Thu, 04 Oct 2018 15:32:53 +0200 Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Ltqmn-1fh4c40VML-0119HV; Thu, 04 Oct 2018 15:32:53 +0200 To: Henrik Levkowetz , "xml2rfc-dev@ietf.org" References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> <6c9785df-73c0-78ff-0c69-1ea1b369b0e0@levkowetz.com> <766a8834-4e7a-e819-6b76-2682eb99be9e@gmx.de> <81f488c3-1caf-a7cc-dc38-c39b3ca2ba5a@levkowetz.com> <7029a06a-3da5-909c-5bff-12e050792d1f@gmx.de> <8344d317-8eb8-53f4-1804-50c421654d30@levkowetz.com> From: Julian Reschke Message-ID: <8c1310f0-e146-008d-5945-caccba4522b1@gmx.de> Date: Thu, 4 Oct 2018 15:32:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <8344d317-8eb8-53f4-1804-50c421654d30@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:6iO9pf/kZsDyetMI+QLTMxYGBFIwHpSlXzVGCq6g7Ux8/ODwC4b 2gyUbgAS1DhSePJ+Ro+fuuMeixbB5OIttkJMY3qTJUvZ1fXAoyeiJ2cKiGeJUtrTlW1nvzu XIC46tqyqtqMAqqtmXlLc24s6E1I/lY3o4Zbeax+yBUiGU1vzn9Xb0uEtTJ7hdR69JnszLo l0gt9bvY9PD/3CHqANctQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:y/HCWgygle0=:V+MYZXR15Y4vHHZRc9MQCQ zh8RF+950tFI+wuhGy0s/gVq7Bv0fAQPclbBosy7chIwkcGVjEY+mAp9ojSQMrtN8tONBE7ov 4UJIENTDAeJ4lBwbs3brHKmuWwtCimrqcUPe8a585HpCV4i4/73VnUvBsIxXCdNF4aK5cJDvY uQjz53u+N8cLv7G1TG3W9RHY4nZrenjvWILYx/i3bvBZcuKYuQ1bBZ85ycE7kl3tNLik0C5b9 yfRA5iM3MsPQV7x8GsTyswmpkoQQcIpe6OVIKsA/paEkYdNdbkFG/HXxY7uPMdX6BSPJ8JDGl NhmWVBqmTpqu2o8CTYwcFbysE+jcwYk7NiF6ku/J9kfOsPN1YDWkZEyGKxC0u3S9zi5F9588d S8nMkCmtkUQwM1/X0cpGRoOVOGD7Cy9ZvQnnFhmwUh5SuuHKvhowHhPPwPdqpIP81hgwbj8hJ hJv1i8SJmKQONx3cN9/O3qOsZUC9Ph9pGst4gl7NRUNw7/qi6WiACDmnuNtFh3BCmSSx40qqE AW2xAetgMnF7Qr17+4dtETYr3OMKV9Jfn8mi3kdCsqHoAwu4tBPa72+78A8GbFevg43yV4Okh cE86FpYCpDmmmV1qr9WBsVeyhipZQHKKghNERuS7QkySQFuZi+pkHoYDT5/wzEJ9tFSQiEXek uq0981UuiknRLM3c7pYCJW1As9oht8sumGzXfA0HcTzFb3d4sMBaOAz+9Mq29MnCxg7wQXnhl d2H8aBQWdjaiqmoehmA0MMqbYoepRhfHX9omUpd6+ct0/O9a1EUWka2ZWVjoBppxzVjsFX0wR bp8qZShc5MUXbsiGKngC/RP5WobfDoIDNOW5+cKGAv/5UYYasQ= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 13:33:10 -0000 On 10/4/2018 3:01 PM, Henrik Levkowetz wrote: > > On 2018-10-04 12:22, Julian Reschke wrote: >> On 10/4/2018 10:46 AM, Henrik Levkowetz wrote: > >> 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. > > 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
    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? > ... 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
    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 nobody Thu Oct 4 06:56:42 2018 Return-Path: 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 C3086130E0C for ; Thu, 4 Oct 2018 06:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 nXl9Y5QKO7M3 for ; Thu, 4 Oct 2018 06:56:39 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF9C812DD85 for ; Thu, 4 Oct 2018 06:56:38 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:55155 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g847K-0001qj-0a; Thu, 04 Oct 2018 06:56:38 -0700 To: Julian Reschke , "xml2rfc-dev@ietf.org" References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> <6c9785df-73c0-78ff-0c69-1ea1b369b0e0@levkowetz.com> <766a8834-4e7a-e819-6b76-2682eb99be9e@gmx.de> <81f488c3-1caf-a7cc-dc38-c39b3ca2ba5a@levkowetz.com> <7029a06a-3da5-909c-5bff-12e050792d1f@gmx.de> <8344d317-8eb8-53f4-1804-50c421654d30@levkowetz.com> <8c1310f0-e146-008d-5945-caccba4522b1@gmx.de> From: Henrik Levkowetz Message-ID: <3d8fe312-6c77-5dc2-1ef1-e9d6e3c0882f@levkowetz.com> Date: Thu, 4 Oct 2018 15:56:30 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8c1310f0-e146-008d-5945-caccba4522b1@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EKu9cFIQEmTg4Uf1nQOrn5igqxFM842Ud" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 13:56:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EKu9cFIQEmTg4Uf1nQOrn5igqxFM842Ud Content-Type: multipart/mixed; boundary="lfc0aUfJiaPVvuf8Uc8mJbprjcHoT3ud5"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , "xml2rfc-dev@ietf.org" Message-ID: <3d8fe312-6c77-5dc2-1ef1-e9d6e3c0882f@levkowetz.com> Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> <6c9785df-73c0-78ff-0c69-1ea1b369b0e0@levkowetz.com> <766a8834-4e7a-e819-6b76-2682eb99be9e@gmx.de> <81f488c3-1caf-a7cc-dc38-c39b3ca2ba5a@levkowetz.com> <7029a06a-3da5-909c-5bff-12e050792d1f@gmx.de> <8344d317-8eb8-53f4-1804-50c421654d30@levkowetz.com> <8c1310f0-e146-008d-5945-caccba4522b1@gmx.de> In-Reply-To: <8c1310f0-e146-008d-5945-caccba4522b1@gmx.de> --lfc0aUfJiaPVvuf8Uc8mJbprjcHoT3ud5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Julian, On 2018-10-04 15:32, Julian Reschke wrote: > On 10/4/2018 3:01 PM, Henrik Levkowetz wrote: >>=20 >> On 2018-10-04 12:22, Julian Reschke wrote: >>> On 10/4/2018 10:46 AM, Henrik Levkowetz wrote: >>=20 >>> The point being: when we discussed this we decided we don't want to g= ive >>> authors control over line breaking; except in this specific exception= in >>> table cells. >>=20 >> Julian, what you're saying here makes me sad. I read this as you sayi= ng >> that since the design team made one decision, you're not going to acce= pt >> any changes even if to other people, with new experience, another deci= sion >> makes more sense. Because this point is not speaking to any arguments= >> about the usefulness and consistency of
    at ail, it is saying that= >> since your decision was such then, it has to be such now. >>=20 >> In that case, what is the meaning with having these discussions at all= ? >>=20 >> Are you open only to make changes that you felt were necessary already= >> before the implementation and user experience came in? >> ... >=20 > No - that's not what I'm saying. >=20 > I tried to explain how we got to the current spec. You also haven't=20 > convinced me that any of the alternatives (forbid
    in table cells, = > 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
    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,=20 "... we decided we don't want to give authors control over line breakin= g ..." as an argument in the case, is not good. If we are going to have a reaso= ned 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 = > offering my opinion. Ack. No worries. Henrik ----- [1] https://en.wikipedia.org/wiki/Principle_of_least_astonishment --lfc0aUfJiaPVvuf8Uc8mJbprjcHoT3ud5-- --EKu9cFIQEmTg4Uf1nQOrn5igqxFM842Ud Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu2HA4ACgkQTptXS4+7 FxpR+A/9GryBHdlPcLB+A1HP0cnXRvObbwrChFh2ZR0yXcECrnPkq63sdQRWl2xu 7vEQMFqVtW8hFWDmiDaFu7YSBleDj4Mc3M5Omfdc2xpWEsX6H48gLOySdgDiNF9F 8vImHEPo7vADuD5ytKMA7kt1rbRShCPAsb1w4YL7GkH5Roj6CmKsGQiZgWk4luuM JiCZFju92MBUx9eqXxz9m7zf8wSDoqPQ5V7fnMZGn3qoqU1nQsk4gN1SM6oVnS8t enghvkuP1kPrh0N+fAEutB9oSTlhhHkpsVrCEAtgmespDtE7h27kbHUYMt+m4LDF VYGzaNaqGKB0J5uPHRZx9niBdMC1ynnLNyUBjbMBa0TN+4jdMI0a3OByZJhpXhm7 K5U+Pva/0gD6QazJzokD/XhAM68JZLadIM4arkmtoKSmv4DwJl+NS8evJ1ORNroX xZUUWMLjgdelHMO9r/lp80Vs/cTv8xq/sVl42lvo05E0uNcb/CkWQbeYKFZ0s+Zz fUuwEt0/ZkwYeJywZV52TymzVaF83cb6aF5v4+Q3hM2QMXthFdNyAIMPH+poh/OX /gKzV4G5aoN6NL0S1MK42/po4YG+NHWMLbQPa2hDLqXATOcGkBKmJ77h2Lo2Q1tH MKcnFesKxx/iRz1RIjjxbt1X40aifpTYyLYsV1xo9FfcmFGY3rU= =YJCK -----END PGP SIGNATURE----- --EKu9cFIQEmTg4Uf1nQOrn5igqxFM842Ud-- From nobody Thu Oct 4 07:25:25 2018 Return-Path: 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 1731F130E4E for ; Thu, 4 Oct 2018 07:25:24 -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 0egX7WfUmrxm for ; Thu, 4 Oct 2018 07:25:22 -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 AA541130E18 for ; Thu, 4 Oct 2018 07:25:22 -0700 (PDT) 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 Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 4 Oct 2018 07:25:20 -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 07:25:20 -0700 From: Paul Hoffman To: Henrik Levkowetz CC: "xml2rfc-dev@ietf.org" Thread-Topic: [Ext] [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    Thread-Index: AQHUW+4UYUw8hpq+FkK6gfklk9RCfg== Date: Thu, 4 Oct 2018 14:25:19 +0000 Message-ID: <6DE6DADE-01EC-4978-9566-9D2250C408CC@icann.org> References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> <6c9785df-73c0-78ff-0c69-1ea1b369b0e0@levkowetz.com> <766a8834-4e7a-e819-6b76-2682eb99be9e@gmx.de> <81f488c3-1caf-a7cc-dc38-c39b3ca2ba5a@levkowetz.com> <2DE9A77A-0306-4F2E-B8D3-19D7915E73FC@icann.org> <6323b0e6-89bb-6cfa-866d-c4df7a42304d@levkowetz.com> In-Reply-To: <6323b0e6-89bb-6cfa-866d-c4df7a42304d@levkowetz.com> 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=_881AAAD6-C39E-49E0-8B5E-D1A78D5D04AA"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 14:25:24 -0000 --Apple-Mail=_881AAAD6-C39E-49E0-8B5E-D1A78D5D04AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 3, 2018, at 9:31 PM, Henrik Levkowetz = wrote: >> Because putting a
    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
    Datagrams" or even . "of Generating
    Datagrams" >=20 > 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
    (in text and pdf because it > would not be part of the text; in html, because html search tools = already > disregard html's
    ). >=20 > 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 ,:-) Neither of those is what I was referring to: I was referring to = searching the corpus of RFCs or Internet Drafts. --Paul Hoffman= --Apple-Mail=_881AAAD6-C39E-49E0-8B5E-D1A78D5D04AA Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAwNDE0MjUxOVowIwYJKoZIhvcNAQkEMRYEFERjGYGADoyLejgqd1JszpEvuyEXMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQAmJTaTPis6KaRVqtQXsrjqbL4GkePKu3Yh0B/OaClhdh6pQwHDNJoMfRsHYdAb2ZFH09Vb ZLu4BccwLLF3hTdsbSahw6KTOV117peqrB/cvKjXfyvNbnYiDjOLREV2bJYacwXVSzfmcQ+Aw5Yd EKml+TcrL2qcRYx7kgUJRu141+wps7gmlMJmKrDzUrlEbmFlfRutxqfQIpSlCx/ofHrFHiOUSLHR Y7G7AgelcephCCMrN288O8oHonJXO0d/gx1Bo/ZtpCRhKFvFOI5A1Ik478G9X+siMcNgy7pKdq9n iVEgZcQ00VGocna5k/UwZOBXgxwRUJMZuZoSSLpsTYzEAAAAAAAA --Apple-Mail=_881AAAD6-C39E-49E0-8B5E-D1A78D5D04AA-- From nobody Thu Oct 4 07:35:09 2018 Return-Path: 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 80587130E3C for ; Thu, 4 Oct 2018 07:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 9MFXZXGcS6U4 for ; Thu, 4 Oct 2018 07:35:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B402130E21 for ; Thu, 4 Oct 2018 07:35:06 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:55311 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g84iX-0005Cc-Bk; Thu, 04 Oct 2018 07:35:06 -0700 To: Paul Hoffman References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> <6c9785df-73c0-78ff-0c69-1ea1b369b0e0@levkowetz.com> <766a8834-4e7a-e819-6b76-2682eb99be9e@gmx.de> <81f488c3-1caf-a7cc-dc38-c39b3ca2ba5a@levkowetz.com> <2DE9A77A-0306-4F2E-B8D3-19D7915E73FC@icann.org> <6323b0e6-89bb-6cfa-866d-c4df7a42304d@levkowetz.com> <6DE6DADE-01EC-4978-9566-9D2250C408CC@icann.org> Cc: "xml2rfc-dev@ietf.org" From: Henrik Levkowetz Message-ID: <5a12ef5f-06c8-8c68-a5d7-1e4ea255e8b3@levkowetz.com> Date: Thu, 4 Oct 2018 16:34:57 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <6DE6DADE-01EC-4978-9566-9D2250C408CC@icann.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="J307sMNnO15FcS8SNd8ccvJXvWeP4mQJo" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, paul.hoffman@icann.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 14:35:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --J307sMNnO15FcS8SNd8ccvJXvWeP4mQJo Content-Type: multipart/mixed; boundary="COKm6QLvfG7Vkl6tdvriPN82NSOmJCehm"; protected-headers="v1" From: Henrik Levkowetz To: Paul Hoffman Cc: "xml2rfc-dev@ietf.org" Message-ID: <5a12ef5f-06c8-8c68-a5d7-1e4ea255e8b3@levkowetz.com> Subject: Re: [Ext] [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> <6c9785df-73c0-78ff-0c69-1ea1b369b0e0@levkowetz.com> <766a8834-4e7a-e819-6b76-2682eb99be9e@gmx.de> <81f488c3-1caf-a7cc-dc38-c39b3ca2ba5a@levkowetz.com> <2DE9A77A-0306-4F2E-B8D3-19D7915E73FC@icann.org> <6323b0e6-89bb-6cfa-866d-c4df7a42304d@levkowetz.com> <6DE6DADE-01EC-4978-9566-9D2250C408CC@icann.org> In-Reply-To: <6DE6DADE-01EC-4978-9566-9D2250C408CC@icann.org> --COKm6QLvfG7Vkl6tdvriPN82NSOmJCehm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-10-04 16:25, Paul Hoffman wrote: > On Oct 3, 2018, at 9:31 PM, Henrik Levkowetz wro= te: >>> Because putting a
    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
    Datagrams" or even . "of Generating
    Datagrams" >>=20 >> I'm sorry, but I think this is incorrect. In rendered context, whethe= r >> text/plain, text/html, or application/pdf, this would not be an issue = -- >> the search tools would not see any
    (in text and pdf because it >> would not be part of the text; in html, because html search tools alre= ady >> disregard html's
    ). >>=20 >> In the context of an editor, working on the xml, a phrase search is ju= st >> as likely to fail because the text has been broken across a line, and >> contains multi-space indentation, which again would prevent an in-edit= or >> phrase search. This is a reality I live with every day ,:-) >=20 > Neither of those is what I was referring to: I was referring to searchi= ng the corpus of RFCs or Internet Drafts. Using which search tool? Henrik --COKm6QLvfG7Vkl6tdvriPN82NSOmJCehm-- --J307sMNnO15FcS8SNd8ccvJXvWeP4mQJo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu2JRIACgkQTptXS4+7 FxrVFA/+PkFNAXvfM+M7tyxCV4Wa3qaesOtVAmDmInqs/T8l4pub8ofzE2ve/6LN c5t3u7d4hexOllynnS5ltvLhvfsLxe9X0eq4fsIPAKwYDJTnSimkAhsk/yNuK+7M mvAAPAZ943UBAVfKNa9E3zCgnNCjFU/CfnxEo+Lfri+CH7X7XS0cMveU23OeqEYK pQqDjCbxnx1vlUnUktmIpddmel4Lt+liEFQ8Em4dEwKuKGG0so9SqnpLB5nwyOTH Gxw9R3RorqWVau3KYhSDOquY0xk/d0jT5kH/Z7bgaYCpnDDS3ZasYTZauf6LOw5k uYjcpq1e1ne/R8rzFeI/faILE+T2tutVIt0S9eqm7EnC5jeWKbIoHnEEQiqgVE1+ bnOpTdTYXIykEXt66su5JcoHFXCZN2dEJDp6QzIEXXf3SJ9X5uAooI+wEcLUItb/ oaMMbe3KYC+0XSUhC5PnlIC37WEIEZjj/QIyQsafz2NW4ybNu0fX1yB8Czwb5nbn ddkKYLw6UMIrvQutoObDTGtF2uzY9U5zq0kWZcycgAQ57LBwd2PChl+fw+FKjeiW moiy/hfR51tYU4z0HGmnzvmxS6TPWz08tn3JE6v4TcZCbMrHKj0EffU5NDaGfAXY Pvngbpwlt1kNUXymCmK3C2xLx0bV46PArEAJ8kiz44f+thNBUSg= =B6KY -----END PGP SIGNATURE----- --J307sMNnO15FcS8SNd8ccvJXvWeP4mQJo-- From nobody Thu Oct 4 07:35:17 2018 Return-Path: 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 D1B31130E3C for ; Thu, 4 Oct 2018 07:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Zb7DKnn-yvJC for ; Thu, 4 Oct 2018 07:35:14 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21414130E21 for ; Thu, 4 Oct 2018 07:35:14 -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 07:35:12 -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 07:35:12 -0700 From: Paul Hoffman To: Miek Gieben CC: XML Developer List Thread-Topic: [Ext] [xml2rfc-dev] RFC 7991: issue #41: Target audience for writing XML Thread-Index: AQHUW6vBDjj80DnL9kKPum0cmBISJ6UPnOqA Date: Thu, 4 Oct 2018 14:35:11 +0000 Message-ID: <9AC0CC1C-A987-47D0-AA92-C6738B937A39@icann.org> References: <20181004062959.bgyb6sxfzzy63caw@miek.nl> In-Reply-To: <20181004062959.bgyb6sxfzzy63caw@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=_F183CFEF-AB83-4AC3-8EAD-EDAF7A8B76F7"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991: issue #41: Target audience for writing XML 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 14:35:16 -0000 --Apple-Mail=_F183CFEF-AB83-4AC3-8EAD-EDAF7A8B76F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 3 Oct 2018, at 23:29, Miek Gieben wrote: > Do we target humans writing XML directly, or it this spec mean to for = other languages (i.e. markdown) to compile to? Definitely both. In particular, some humans will want to start with a = template in XML, or with the XML that was generated from an old RFC. = Other humans will want to work just in Markdown or similar formats. > If "humans" would should aim (IMO) for a consistent spec where = attribute names are consistent and not that numerous and there aren't a = lot of=20 > exceptions on where what elements can be used. Consistent: that seems like a fine goal. It is stymied by the fact that = v3 is a version of v2, which had its own consistency issues. It is also = stymied by the fact that v3 was developed over time and different parts = had more focus. Still, if we can make it more consistent without making = it harder to covert from v2, that's probably worth doing. Not that numerous: As long as the numerous ones are optional, I would = disagree. In probably >90% of the cases that were added, this was for = added functionality that will make the resulting documents have more = useful metadata, display better, or both. Not lots of exceptions: I guess I'm inured to XML attributes having lots = of exceptions, and that probably leads to specs that are more = complicated. > If we let something compile to XML we could relax this is bit. = Although my experience with using markdown is that a lot of the details = carry over to=20 > the markdown as well; making it easy to generate an illegal document. Conversion from Markdown and similar formats has always been a mixed = bag. FWIW, I normally start new documents in Markdown. When the v3 spec = is finished and usable as a publication format, I will certainly look at = my Markdown-to-XML output for a particular draft and see if the extras = that I might get from sprinkling in my own XML is worth the pain of then = living in XML only. --Paul Hoffman --Apple-Mail=_F183CFEF-AB83-4AC3-8EAD-EDAF7A8B76F7 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAwNDE0MzUxMVowIwYJKoZIhvcNAQkEMRYEFPTuBRZXwWFiuSC2wp2QTHXb+QSMMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQBrAs2qfCTNyrbFRHiHFG4+IE1L7YRIhcbGqflzfjWcM/oQIHBNlDyqvKqYpXP5y3UUg2Gr UilPAxhUMEu1fMirZpHvj/RJGyEsp9W0SyvwuXmuOSQwQQ6ed2IcNH9tFQN7fbUbv2VjREww4ITk X+kDI3ypJQ29BViXgQ+X0gU+IDYwoxzNHpmRkrTTNG4Hip5zB0P0R8RN6im4J3spvJw51xyTrVwO 1Tr5A7928+H3P+lh3qNL2Y+mkx4GPe7CqA/bfgMVgURY6udE5YIT9P5n2bMR0pcmUh1qtHiphkTI JJQM+NUqjHGQEYR16XnSt1XbTfueZ4YX00AsrM9kN8ZpAAAAAAAA --Apple-Mail=_F183CFEF-AB83-4AC3-8EAD-EDAF7A8B76F7-- From nobody Thu Oct 4 07:52:43 2018 Return-Path: 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 44AEC12958B for ; Thu, 4 Oct 2018 07:52:41 -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 pQPE5-VkjOh4 for ; Thu, 4 Oct 2018 07:52:39 -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 9B6AF124BE5 for ; Thu, 4 Oct 2018 07:52:39 -0700 (PDT) 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 Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 4 Oct 2018 07:52:37 -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 07:52:37 -0700 From: Paul Hoffman To: Henrik Levkowetz CC: "xml2rfc-dev@ietf.org" Thread-Topic: [Ext] [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    Thread-Index: AQHUW+4UtWUZn5bLLE2EL84MpJfR4aUPnFSAgAAE7wA= Date: Thu, 4 Oct 2018 14:52:37 +0000 Message-ID: <56828DC3-2038-450A-A98F-58D8F374B974@icann.org> References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> <6c9785df-73c0-78ff-0c69-1ea1b369b0e0@levkowetz.com> <766a8834-4e7a-e819-6b76-2682eb99be9e@gmx.de> <81f488c3-1caf-a7cc-dc38-c39b3ca2ba5a@levkowetz.com> <2DE9A77A-0306-4F2E-B8D3-19D7915E73FC@icann.org> <6323b0e6-89bb-6cfa-866d-c4df7a42304d@levkowetz.com> <6DE6DADE-01EC-4978-9566-9D2250C408CC@icann.org> <5a12ef5f-06c8-8c68-a5d7-1e4ea255e8b3@levkowetz.com> In-Reply-To: <5a12ef5f-06c8-8c68-a5d7-1e4ea255e8b3@levkowetz.com> 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=_34123970-39DA-4359-9E58-CA36987A8873"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 14:52:41 -0000 --Apple-Mail=_34123970-39DA-4359-9E58-CA36987A8873 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 4, 2018, at 7:34 AM, Henrik Levkowetz = wrote: >=20 >=20 > On 2018-10-04 16:25, Paul Hoffman wrote: >> On Oct 3, 2018, at 9:31 PM, Henrik Levkowetz = wrote: >>>> Because putting a
    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
    Datagrams" or even . "of Generating
    Datagrams" >>>=20 >>> 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
    (in text and pdf because it >>> would not be part of the text; in html, because html search tools = already >>> disregard html's
    ). >>>=20 >>> 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 ,:-) >>=20 >> Neither of those is what I was referring to: I was referring to = searching the corpus of RFCs or Internet Drafts. >=20 > Using which search tool? grep for now, hopefully something more formal later when the corpus has = more XML. --Paul Hoffman= --Apple-Mail=_34123970-39DA-4359-9E58-CA36987A8873 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAwNDE0NTIzN1owIwYJKoZIhvcNAQkEMRYEFM1lTir3i6hFgtYJZWKfcjQYNhZsMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQAFChMIE8r0WAZorBmkGUWVWTjJh3aLZpbLQWnrtcRn1H0GoCcSTpu6GVA2lfjPzaOyuziH lbBSEe0wKjI6TnbqnpTHMP6jvvzSnZaK1jInmw84ozYrNuZl1F1c5p1vQEOqXQqedO2z/g/0U7Sa HhmAkUZGkO+OVos5liDm0VxO3URuJOYaF0sX0KFEz4YX0ueskaa7yBi/1+ykr4/D19iapD2rLtKw Wlk2LFkvmZbWRCMtvNv2CGXIMfYMLfU+Lcq4GUVHa2Ziqw7FCxFpiF0gpMOAvn+iW5roNpJudlGn ZIdmnt+hwZM4PZoyUYiPqmI4ZpO51RpcQiPyTOAOPFmeAAAAAAAA --Apple-Mail=_34123970-39DA-4359-9E58-CA36987A8873-- From nobody Thu Oct 4 08:07:39 2018 Return-Path: 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 0A723130E55 for ; Thu, 4 Oct 2018 08:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 2k2IlSeynVU9 for ; Thu, 4 Oct 2018 08:07:34 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B26DF130DFB for ; Thu, 4 Oct 2018 08:07:33 -0700 (PDT) Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MMHaL-1g540e054H-007yjD; Thu, 04 Oct 2018 17:06:53 +0200 Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MMHaL-1g540e054H-007yjD; Thu, 04 Oct 2018 17:06:53 +0200 To: Paul Hoffman , Henrik Levkowetz Cc: "xml2rfc-dev@ietf.org" References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> <6c9785df-73c0-78ff-0c69-1ea1b369b0e0@levkowetz.com> <766a8834-4e7a-e819-6b76-2682eb99be9e@gmx.de> <81f488c3-1caf-a7cc-dc38-c39b3ca2ba5a@levkowetz.com> <2DE9A77A-0306-4F2E-B8D3-19D7915E73FC@icann.org> <6323b0e6-89bb-6cfa-866d-c4df7a42304d@levkowetz.com> <6DE6DADE-01EC-4978-9566-9D2250C408CC@icann.org> <5a12ef5f-06c8-8c68-a5d7-1e4ea255e8b3@levkowetz.com> <56828DC3-2038-450A-A98F-58D8F374B974@icann.org> From: Julian Reschke Message-ID: <2362978e-1b91-8fca-dee8-6b41284f06aa@gmx.de> Date: Thu, 4 Oct 2018 17:06:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <56828DC3-2038-450A-A98F-58D8F374B974@icann.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:hNTy3aK1dmyDxXvEfPvuceXQvSfe/WSTGZ8/AJI176I90n7nyCs Z+HMWWljoa9S60colmsKANgt7+9U9LKsL2ft641U5dDrLmEeufSV74EbuRRS+QYjxwlu1WJ CGm5yoTuje5aftLRRcTe7bP0trJ/8aMN7KXOjhXleWNyXxxdyxdDamISUXNxaUUd+r3CYTg QuRj6xlhW79SkgGgz1ZiQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:zYah4EZySiw=:HE4c1b9YDnHPjKnwZ2x6Y3 MnzsK7kUabX9nhZP8vfuF2R9GHOxYusj6uq+iuAOQ3ipsW1S4F0YQ7Qc6J49f3Vqx44F4qIr9 I2OO0eWWR9BrWJro+LiWst0VFtKinxEBdgmNK8iu87oYJav3l+MFPRk6eIrTLIIe2GykQBrs5 PZJeHOIS88XbqF+0MGVosVmpUnf4GBJ4jtX1rFp1HMMe5Ld9DaxRmQs3o08htfm8jGpNfwb1z j1j/EtOJzhzLS0hmorF5RYfXC6vroAbmvBc8Yjvo9rdy/e4x0BkCYhJ08pmtRApk2rqm9ydlT 2bKfzHxdzV6C3Y2XStyquvAcaswUWpNYHCn0uy1ia1jdYyc+WobomfeKRX42pgzyo7GWRtcDt hGnDaTYUymV5CQpM4yfiOxBsfm4gqzRNF1pb2pG3ssWQztiBzOjLiKR08Fu7f4wPAl4SBVI+e RVpq/o79bSEwk7CQITVWybLHdcKoF2nMGkcV913N8pmF6S52L958ep33f9Z+wxmBPSjC5YW7c G9Qo2aPD0H6NK/85PPxQUSSDFdrvNnJ6RQrb2KB9YhNZ8W+bgwoPRFOO/cVzmb4qGEUwTdV5p eoDsa0jBVuWt7HAdPEoVht2Ng09X6aI5xwVMVH10NdqoHm9AY7Ga1MkskLhZA6sbg/IMiVOcN tEjGo2B+SYuT0VdfxW03fdQC/YzqzC+f1c9PPLR0gUAd/jOiLeGlM6Kg0KIBoeguy6oWmWZ4a CHIsYONBhlhP7QXr3RKfs0YGNSRZOSA16y2Qmo4TTvQsILjGUucpkcj0s5STnQWMCWtpqmcKD tjH89zjSxphiQoEhv+Lml/s8FQovlfSI4fd0fBHIUjFakTkCAU= Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 15:07:37 -0000 On 10/4/2018 4:52 PM, Paul Hoffman wrote: > On Oct 4, 2018, at 7:34 AM, Henrik Levkowetz wrote: >> >> >> On 2018-10-04 16:25, Paul Hoffman wrote: >>> On Oct 3, 2018, at 9:31 PM, Henrik Levkowetz wrote: >>>>> Because putting a
    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
    Datagrams" or even . "of Generating
    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
    (in text and pdf because it >>>> would not be part of the text; in html, because html search tools already >>>> disregard html's
    ). >>>> >>>> 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 ,:-) >>> >>> 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? > > 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 --
    wouldn't make things any more worse than they are already. Best regards, Julian From nobody Thu Oct 4 08:26:06 2018 Return-Path: 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 1B794130DFB for ; Thu, 4 Oct 2018 08:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 EdvanuwGy99m for ; Thu, 4 Oct 2018 08:26:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4591D130E48 for ; Thu, 4 Oct 2018 08:26:00 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:55498 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g85Vm-0002Df-Pc; Thu, 04 Oct 2018 08:25:59 -0700 To: Paul Hoffman References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> <6c9785df-73c0-78ff-0c69-1ea1b369b0e0@levkowetz.com> <766a8834-4e7a-e819-6b76-2682eb99be9e@gmx.de> <81f488c3-1caf-a7cc-dc38-c39b3ca2ba5a@levkowetz.com> <2DE9A77A-0306-4F2E-B8D3-19D7915E73FC@icann.org> <6323b0e6-89bb-6cfa-866d-c4df7a42304d@levkowetz.com> <6DE6DADE-01EC-4978-9566-9D2250C408CC@icann.org> <5a12ef5f-06c8-8c68-a5d7-1e4ea255e8b3@levkowetz.com> <56828DC3-2038-450A-A98F-58D8F374B974@icann.org> Cc: "xml2rfc-dev@ietf.org" From: Henrik Levkowetz Message-ID: <9fb8e2bb-13d5-1f9e-25cc-e13910fbbb29@levkowetz.com> Date: Thu, 4 Oct 2018 17:25:50 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <56828DC3-2038-450A-A98F-58D8F374B974@icann.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8fe75eq0CKEfSDALi5itJKghhM8GXq9I8" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, paul.hoffman@icann.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 15:26:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8fe75eq0CKEfSDALi5itJKghhM8GXq9I8 Content-Type: multipart/mixed; boundary="UJFP23qp7rjvxeaCLKx7Pouic5oFpL1wx"; protected-headers="v1" From: Henrik Levkowetz To: Paul Hoffman Cc: "xml2rfc-dev@ietf.org" Message-ID: <9fb8e2bb-13d5-1f9e-25cc-e13910fbbb29@levkowetz.com> Subject: Re: [Ext] [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> <6c9785df-73c0-78ff-0c69-1ea1b369b0e0@levkowetz.com> <766a8834-4e7a-e819-6b76-2682eb99be9e@gmx.de> <81f488c3-1caf-a7cc-dc38-c39b3ca2ba5a@levkowetz.com> <2DE9A77A-0306-4F2E-B8D3-19D7915E73FC@icann.org> <6323b0e6-89bb-6cfa-866d-c4df7a42304d@levkowetz.com> <6DE6DADE-01EC-4978-9566-9D2250C408CC@icann.org> <5a12ef5f-06c8-8c68-a5d7-1e4ea255e8b3@levkowetz.com> <56828DC3-2038-450A-A98F-58D8F374B974@icann.org> In-Reply-To: <56828DC3-2038-450A-A98F-58D8F374B974@icann.org> --UJFP23qp7rjvxeaCLKx7Pouic5oFpL1wx Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-10-04 16:52, Paul Hoffman wrote: > On Oct 4, 2018, at 7:34 AM, Henrik Levkowetz wro= te: >>=20 >>=20 >> On 2018-10-04 16:25, Paul Hoffman wrote: >>> On Oct 3, 2018, at 9:31 PM, Henrik Levkowetz w= rote: >>>>> Because putting a
    in running text prevents you from being able= >>>>> to search for the whole phrase. This was one of the explicit reason= s >>>>> to prevent them everywhere, and titles and section names are >>>>> particularly important examples. You might search for a title of "o= f >>>>> Generating Datagrams" but would never think of searching for "of >>>>> Generating
    Datagrams" or even . "of Generating
    Datagrams" >>>>=20 >>>> I'm sorry, but I think this is incorrect. In rendered context, whet= her >>>> text/plain, text/html, or application/pdf, this would not be an issu= e -- >>>> the search tools would not see any
    (in text and pdf because it >>>> would not be part of the text; in html, because html search tools al= ready >>>> disregard html's
    ). >>>>=20 >>>> 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, an= d >>>> contains multi-space indentation, which again would prevent an in-ed= itor >>>> phrase search. This is a reality I live with every day ,:-) >>>=20 >>> Neither of those is what I was referring to: I was referring to searc= hing the corpus of RFCs or Internet Drafts. >>=20 >> Using which search tool? >=20 > 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 dea= l with these elements embedded in the phrase:=20 bcp14, cref, em, eref, iref, list, relref, strong, sub, sup, tt, xref (I've excluded some deprecated elements). Adding
    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 --UJFP23qp7rjvxeaCLKx7Pouic5oFpL1wx-- --8fe75eq0CKEfSDALi5itJKghhM8GXq9I8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu2MP4ACgkQTptXS4+7 FxpF3A//XOBuRznnTb17awlX2WHd4Vk+AL830v8GY4iVNvOryV9wy3aAS70a2RHT 69Pe7rwTxp8ZIQonvkoyBtq8RHFIDfrIL+cUH5jBRtdxYFhry+lkJk2oOhQBt6F+ GBRXIG3yRf4OBFICBJ7GPy+EADwvw4Cc9zfPQdF4xMDIMu+YRdcpHoWkceEX+83+ 6tBfA8hdVaoGvOOAuYUArP8QESjSYI8CLgh3KfQkE2HkfC9/IPlFw0mcbA+hZ/4K M1lMdmjZH4h9EtAnsIkUYQEOcVT2vJqq8CAD5uNms6bsNZOlv7Y58M+BlngFQRvG spxq9YFn8gkEeMASjcSWQ+unP1v3RJwj0FWIVqyf5mh1dQT9s3OLfGGVgRISPzG9 6rT3BqavbsGfAcZ+YwSR9nrnLVthu8Q9g25fAuw2pPq4d1ozHd8fCmYYd3lwcnnj ue5NoVitnaFEx1Hsy66fC1h5eeXXk2swfq/XfXN4/auLYrQ4lP9pzbJRrJLxyAmp LuePahNh3T1Hm9qJFcT4YDUsM19LL/O9ykOpSL7z+/RHX9xIHI+mY+gJKrE8pCJc N3eqLlRAhO6eHcewdpl0t05+MKldkGtCo3FEEwcC9fACVy1G3VgbvsVSm72jrlPl vrWZ17j1YvtADWO3hex3wgasAGfISg27pe11MrO9tTlBE0gPtK8= =RlUs -----END PGP SIGNATURE----- --8fe75eq0CKEfSDALi5itJKghhM8GXq9I8-- From nobody Thu Oct 4 10:19:01 2018 Return-Path: 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 88935130E94 for ; Thu, 4 Oct 2018 10:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 un2LpnocsTyq for ; Thu, 4 Oct 2018 10:18:58 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CFBD130DD3 for ; Thu, 4 Oct 2018 10:18:57 -0700 (PDT) Received: from unescapeable.routerlogin.net (mobile-166-137-217-005.mycingular.net [166.137.217.5]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w94HIWGZ021985 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 4 Oct 2018 12:18:34 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-137-217-005.mycingular.net [166.137.217.5] claimed to be unescapeable.routerlogin.net To: Paul Hoffman , Miek Gieben Cc: "xml2rfc-dev@ietf.org" References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> From: Robert Sparks Message-ID: <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> Date: Thu, 4 Oct 2018 12:18:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4D98108156F624C2E3F3A26F" Content-Language: en-US Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 17:19:01 -0000 This is a multi-part message in MIME format. --------------4D98108156F624C2E3F3A26F Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 . That will prevent people who "know" what
    "means" from expecting it to work because
    doesn't exist. > > If, later, we want to add
    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 > > > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc-dev --------------4D98108156F624C2E3F3A26F Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

    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.

--Paul Hoffman


    _______________________________________________
xml2rfc-dev mailing list
xml2rfc-dev@ietf.org
https://www.ietf.org/mailman/listinfo/xml2rfc-dev

    --------------4D98108156F624C2E3F3A26F-- From nobody Thu Oct 4 10:31:23 2018 Return-Path: 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 D33E6130E50 for ; Thu, 4 Oct 2018 10:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 x4SnJ7duTAj6 for ; Thu, 4 Oct 2018 10:31:19 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D6B9130D7A for ; Thu, 4 Oct 2018 10:31:19 -0700 (PDT) Received: from unescapeable.routerlogin.net (mobile-166-137-217-005.mycingular.net [166.137.217.5]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w94HVHon024030 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 4 Oct 2018 12:31:19 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-137-217-005.mycingular.net [166.137.217.5] claimed to be unescapeable.routerlogin.net To: xml2rfc-dev@ietf.org References: From: Robert Sparks Message-ID: <66bebdb0-3587-0c73-4b0a-5e47fbe6536d@nostrum.com> Date: Thu, 4 Oct 2018 12:31:12 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1C82467A394986DAB2212B96" Content-Language: en-US Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #34: src and content confusion 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 17:31:22 -0000 This is a multi-part message in MIME format. --------------1C82467A394986DAB2212B96 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 10/3/18 6:33 PM, Paul Hoffman wrote: >> Section 2.5 >> >> Alternatively, the "src" attribute allows referencing an external >> graphics file, such as a vector drawing in SVG or a bitmap graphic >> file, using a URI. In this case, the textual content acts as a >> fallback for output representations that do not support graphics; >> thus, it ought to contain either (1) a "line art" variant of the >> graphics or (2) prose that describes the included image in sufficient >> detail. >> >> And later: >> >> It is an error to have both a "src" attribute and content in the >> element. > Yeeps. That later sentence seems wrong, particularly when you look at the "alt" attribute: > > 2.5.2. "alt" Attribute > > Alternative text description of the artwork (which is more than just > a summary or caption). When the art comes from the "src" attribute > and the format of that artwork supports alternate text, the > alternative text comes from the text of the artwork itself, not from > this attribute. The contents of this attribute are important to > readers who are visually impaired, as well as those reading on > devices that cannot show the artwork well, or at all. I don't see that as wrong. Content in the artwork element means Content, no? What the text is trying to avoid is the ambiguity introduced by content that looks almost, but not entirely, unlike T (Apologies if I'm being a bit sloppy, but I think that gets the point across? I see the alt attribute as orthoganal. RjS > > --Paul Hoffman > > > > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc-dev --------------1C82467A394986DAB2212B96 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit



    On 10/3/18 6:33 PM, Paul Hoffman wrote:
    Section 2.5

Alternatively, the "src" attribute allows referencing an external
graphics file, such as a vector drawing in SVG or a bitmap graphic
file, using a URI. In this case, the textual content acts as a
fallback for output representations that do not support graphics;
thus, it ought to contain either (1) a "line art" variant of the
graphics or (2) prose that describes the included image in sufficient
detail.

And later:

It is an error to have both a "src" attribute and content in the
<artwork> element.

    Yeeps. That later sentence seems wrong, particularly when you look at the "alt" attribute:

2.5.2.  "alt" Attribute

   Alternative text description of the artwork (which is more than just
   a summary or caption).  When the art comes from the "src" attribute
   and the format of that artwork supports alternate text, the
   alternative text comes from the text of the artwork itself, not from
   this attribute.  The contents of this attribute are important to
   readers who are visually impaired, as well as those reading on
   devices that cannot show the artwork well, or at all.
    I don't see that as wrong. Content in the artwork element means <artwork>Content</artwork>, no?
    What the text is trying to avoid is the ambiguity introduced by
    <artwork src="a place with content that looks like T">content that looks almost, but not entirely, unlike T</artwork>

    (Apologies if I'm being a bit sloppy, but I think that gets the point across? I see the alt attribute as orthoganal.

    RjS
    
--Paul Hoffman




    _______________________________________________
xml2rfc-dev mailing list
xml2rfc-dev@ietf.org
https://www.ietf.org/mailman/listinfo/xml2rfc-dev

    --------------1C82467A394986DAB2212B96-- From nobody Thu Oct 4 10:32:41 2018 Return-Path: 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 BFCE4130E7E for ; Thu, 4 Oct 2018 10:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 1dDa1FEW87To for ; Thu, 4 Oct 2018 10:32:39 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA2F130D7A for ; Thu, 4 Oct 2018 10:32:38 -0700 (PDT) Received: from [192.168.178.20] ([91.61.61.129]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MELdk-1fxABp19wG-00FRCR; Thu, 04 Oct 2018 19:32:21 +0200 Received: from [192.168.178.20] ([91.61.61.129]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MELdk-1fxABp19wG-00FRCR; Thu, 04 Oct 2018 19:32:21 +0200 To: Robert Sparks , Paul Hoffman , Miek Gieben Cc: "xml2rfc-dev@ietf.org" References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> From: Julian Reschke Message-ID: Date: Thu, 4 Oct 2018 19:32:17 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:arpHG1rdfXJSqcZbprhne6bUiEVxSpc9RoabZ0tsItbujFFV2TU XnOJYniewzhF/lvzbsBzIwU+KFzWQu96cp52/DrUxK2acDohG5Snpry27wcDwyVHs/CmBEz XQI2zfGAD31W7E88RyQU1D9vNl8HNbD9O9C8YjSSZ5E5+a0RszOuvduV37KsC6iPjB9Knl1 LYR9PpWdxwayrK+XkU7/Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:jeHZP3laJ18=:UQBArbP6xxgqBeqvSXXnGQ 3FulJl1yl2GTQwt0ymj2L/qfpIIX2O6zfUV9M8aXnVhOlNLC8zfPKPrTVjZtx5xDKEeMOoc0v eMuiWXM7Bp2tVJsTaxBfm9kRV7ICcjJUUi4lMIVC4XKabl3H98S5xuUc5q4L9HFVhnvHcj+Hm /UE6zh8TVUnkJsYoc+n1PlGv/lsRrA/QuNTMnLFZMver646XZl9cKmEgb4C7v+rU8+6xoTtl3 G+eHWvrTDaqaPRrmY5WHpr/+Lk+Tbrwo+DawY04eFWGdZFb3y1nwVxs+E5Bj+mUyG82VAwtYJ 9z4uhZGJ1ODqJK36NJOlBwViDva1OXwP7p9GYUoRNC9DLNRZwf0mFGNw+Ex+GDLZPSc6cWtjv wocdiHUsrwwcKtRqnGHKNhGuu1/NBGpmTgmangGgejlSSl1+GSZjJEGfLRqihtdNZgruw87Vo 25guMW1Kd+VPPrrfc9PTBmPiQAtm891LLBlEYj/gZ8D156aNj+8bPlEamGogk/UshIOMqUZtw F42uBQVVFkBsJCAmCh5X2HgrMLt/4OExWPcv5bSCZ6kaiBqbrhynJpgtabcI5dVDrigksBaKK Dj0+CYm3gYwBeIMiPjw0L8mBo21x4NuCPiaNH14JCedMWn3n2VHEEx+PY3u1vp6lc2l5lR0Aa dv64Fyogdvmmf5nB4qTe1yOLeDEkGO0qy2nPATA/a7bHaTqMNgK4X9AAoCiHQ2kPcneCjy0Kc 2ddbHq+410JkaRG4boQTFhZgPeexXddxWHyOWb9hA9Ls19Qi2eWAipHcY9D7KioyC3X2KJ6Wt x28rPbGKGI1Pwz6gv/WuPFnBzhrKu3DxaF7xoBEhUG7fuoJs/0= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 17:32:41 -0000 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... From nobody Thu Oct 4 10:41:52 2018 Return-Path: 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 65F15130DCF for ; Thu, 4 Oct 2018 10:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 QUpHRnFvdNXR for ; Thu, 4 Oct 2018 10:41:49 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24131130D7A for ; Thu, 4 Oct 2018 10:41:49 -0700 (PDT) Received: from unescapeable.routerlogin.net (mobile-166-137-217-005.mycingular.net [166.137.217.5]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w94HflQH025778 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 4 Oct 2018 12:41:48 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-137-217-005.mycingular.net [166.137.217.5] claimed to be unescapeable.routerlogin.net To: "xml2rfc-dev@ietf.org" From: Robert Sparks Message-ID: <36e383cf-7fc1-08d4-9888-8ac234d0a0b5@nostrum.com> Date: Thu, 4 Oct 2018 12:41:42 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [xml2rfc-dev] Conversation on #33 needs to move to the list 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 17:41:51 -0000 https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/33 has a bit of back-and-forth. That needs to be here, not on github. Please summarize the issue and the discussion so far on-list. RjS From nobody Thu Oct 4 10:43:51 2018 Return-Path: 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 E36EB130EC0 for ; Thu, 4 Oct 2018 10:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 zvfH2cER3DVV for ; Thu, 4 Oct 2018 10:43:43 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19101130EBC for ; Thu, 4 Oct 2018 10:43:43 -0700 (PDT) Received: from unescapeable.routerlogin.net (mobile-166-137-217-005.mycingular.net [166.137.217.5]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w94HhfMD026066 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 4 Oct 2018 12:43:42 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-137-217-005.mycingular.net [166.137.217.5] claimed to be unescapeable.routerlogin.net To: "xml2rfc-dev@ietf.org" From: Robert Sparks Message-ID: <28758af0-e690-1458-6d0b-1af463406a93@nostrum.com> Date: Thu, 4 Oct 2018 12:43:36 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [xml2rfc-dev] Issue #31 needs to be brought to the list. 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 17:43:50 -0000 https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/31 has no list discussion. Please bring it here. RjS From nobody Thu Oct 4 10:46:53 2018 Return-Path: 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 CD109130DDE for ; Thu, 4 Oct 2018 10:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 QMBI869sV7QR for ; Thu, 4 Oct 2018 10:46:50 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D02A130DC8 for ; Thu, 4 Oct 2018 10:46:50 -0700 (PDT) Received: from unescapeable.routerlogin.net (mobile-166-137-217-005.mycingular.net [166.137.217.5]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w94Hkmr3026614 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 4 Oct 2018 12:46:49 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-137-217-005.mycingular.net [166.137.217.5] claimed to be unescapeable.routerlogin.net To: "xml2rfc-dev@ietf.org" From: Robert Sparks Message-ID: Date: Thu, 4 Oct 2018 12:46:43 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [xml2rfc-dev] Bring Issue #27 to the list 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 17:46:52 -0000 https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/27 Please summarize here and complete the discussion on list. From nobody Thu Oct 4 10:57:10 2018 Return-Path: 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 6C667130EB3 for ; Thu, 4 Oct 2018 10:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 gH0eSdtl1B_K for ; Thu, 4 Oct 2018 10:57:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF20130ED7 for ; Thu, 4 Oct 2018 10:57:00 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:56082 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g87ru-0007kk-Jt; Thu, 04 Oct 2018 10:56:59 -0700 To: Robert Sparks , Paul Hoffman , Miek Gieben References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> Cc: "xml2rfc-dev@ietf.org" From: Henrik Levkowetz Message-ID: Date: Thu, 4 Oct 2018 19:56:48 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JAHaatxXU6CUwA70aM9IgLncaw8jucxHA" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, miek@miek.nl, paul.hoffman@icann.org, rjsparks@nostrum.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 17:57:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JAHaatxXU6CUwA70aM9IgLncaw8jucxHA Content-Type: multipart/mixed; boundary="vNOfHI6WtNBCrw4JGgKA6RboHRfFJf0uJ"; protected-headers="v1" From: Henrik Levkowetz To: Robert Sparks , Paul Hoffman , Miek Gieben Cc: "xml2rfc-dev@ietf.org" Message-ID: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> In-Reply-To: <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> --vNOfHI6WtNBCrw4JGgKA6RboHRfFJf0uJ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-10-04 19:18, Robert Sparks wrote: > I didn't see a response to this. >=20 > If we decide that preserving the "only in tables" idea, this avoids the= =20 > argument about causing authors unnecessary confusion. >=20 > If it's clearly a bad idea, please capture why on the list for later. >=20 > RjS >=20 >=20 > 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 . That will prevent >> people who "know" what
    "means" from expecting it to work >> because
    doesn't exist. >>=20 >> If, later, we want to add
    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
    was generall= y unavailable, but the functionality existed specifically within table cell= s. Miek has also raised a related issue, #41, about not having so many speci= al cases in the schema. Finally,
    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
    to will deal with the expectation of
    being generally useful, since it's not called
    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 if
    doesn'= t work. The renaming will not do anything for issue #41, and it will also do noth= ing to address the need for a straightforward capability like
    in other contexts. So I don't see this a clean solution, and the parts it solves also introd= uces new drawbacks. I tried to capture what I felt was the essence of the problem in my propo= sed resolution, of either permitting
    widely, or removing it. I still do= n't care much either way, but seems to provide neither the cleanness of= removing
    it completely, or permitting it more generally. Henrik --vNOfHI6WtNBCrw4JGgKA6RboHRfFJf0uJ-- --JAHaatxXU6CUwA70aM9IgLncaw8jucxHA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu2VGAACgkQTptXS4+7 FxpyLxAAuShdNvQtE3u3uBs4PX5JN1ipDHJVERZtNFF9+KASQXOZy5n60cEuk5AC MS1yj1vrDOLACFLkOa0xuJHZUGzRYeMCwPyqiOu70MBSuzi6J9vTRF0qo18LfM0o HbjGUuHQPFoK5JU4/q+/o0MilUn16nqEhrtRKQV4ovONOD5KYARTLed+YLhAj6Ha AcGtuJZLbObQkgxcz9ZQ6pZtOtoeWwL/psBGhx6+LzwPlN1kPN/l/gt7BrwoKqY3 MxHzDM6FDZ3XZd55b1XCdm4y8q3l9F4FPraXA003GYb4lS9pmpYcuL7pzGxeWAbm Z7LZp0h5J4ufsFMmlsu34GoIQYECttuDuQI5W2V1RgUqQRMgUtpeUC5v5c4FDWtD 37IRj622YuCU8Y5n0W7MuNNux42wlyeILwR/7A5as5ZB5eTwK1U1zGmk7pzTOSw4 zNgCT8rObSJHeM3KhvjNx6ZmlL0Eb2t/OhjnHGDubjiYvclxB8CkR9UmxUU7iA+3 4DMLdFbiuS0IwHy+wYeW5tfXFylkw0EJItg1/oPVXrwB9ZES/jojQFo6tQLPyhd/ agoqZUmZF6j0EcDeNx+YW7yJscQ2M/yCfv8Erfs/bzynUKHy5VTAnknwGQeojFFP Mcb8CZvufKNkqMbE3mmecESuxSSWu5k7x4IUJ/JoUA+hH8GjD9o= =k2S4 -----END PGP SIGNATURE----- --JAHaatxXU6CUwA70aM9IgLncaw8jucxHA-- From nobody Thu Oct 4 11:15:26 2018 Return-Path: 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 09EFC130E83 for ; Thu, 4 Oct 2018 11:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 hFHq_b9N-AKc for ; Thu, 4 Oct 2018 11:15:23 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55961130D7A for ; Thu, 4 Oct 2018 11:15:23 -0700 (PDT) Received: from unescapeable.local (mobile-166-137-217-022.mycingular.net [166.137.217.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w94IFLTm031407 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 4 Oct 2018 13:15:23 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-137-217-022.mycingular.net [166.137.217.22] claimed to be unescapeable.local To: "xml2rfc-dev@ietf.org" From: Robert Sparks Message-ID: Date: Thu, 4 Oct 2018 13:15:16 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [xml2rfc-dev] Other issues with conversation that needs to come to the list 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 18:15:25 -0000 Sigh - I hoped it would only be a few of these. All of the issues will need to come to the list. I've only been pointing to the ones that have (relatively) substantial discussion on github that's not yet reflected here. https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/5 https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/8 https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/9 https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/12 https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/13 https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/17 https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/20 https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/22 https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/26 My cut is a little arbitrary and hastily done- there are other issues with one comment that I didn't call out. In any case, for these, and any I missed, where there has been discussion, please summarize the discussion so far on list and finish it here. RjS From nobody Thu Oct 4 11:36:58 2018 Return-Path: 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 87E6C128D0C for ; Thu, 4 Oct 2018 11:36:57 -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 6dTNTI7uOXfl for ; Thu, 4 Oct 2018 11:36:55 -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 84D8812426A for ; Thu, 4 Oct 2018 11:36:55 -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 11:36:53 -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 11:36:53 -0700 From: Paul Hoffman To: Robert Sparks CC: "xml2rfc-dev@ietf.org" Thread-Topic: [xml2rfc-dev] [Ext] RFC 7991 issue #34: src and content confusion Thread-Index: AQHUXAgUz/xMwB2iskuRR9g0a9MSraUP37gA Date: Thu, 4 Oct 2018 18:36:52 +0000 Message-ID: <87A4F4E0-99B9-4375-94D9-28164B31DBCD@icann.org> References: <66bebdb0-3587-0c73-4b0a-5e47fbe6536d@nostrum.com> In-Reply-To: <66bebdb0-3587-0c73-4b0a-5e47fbe6536d@nostrum.com> 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=_6366E305-088A-476A-9D66-08DFCF4515F8"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #34: src and content confusion 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 18:36:58 -0000 --Apple-Mail=_6366E305-088A-476A-9D66-08DFCF4515F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 4, 2018, at 10:31 AM, Robert Sparks wrote: >=20 >=20 >=20 > On 10/3/18 6:33 PM, Paul Hoffman wrote: >>> Section 2.5 >>>=20 >>> Alternatively, the "src" attribute allows referencing an external >>> graphics file, such as a vector drawing in SVG or a bitmap graphic >>> file, using a URI. In this case, the textual content acts as a >>> fallback for output representations that do not support graphics; >>> thus, it ought to contain either (1) a "line art" variant of the >>> graphics or (2) prose that describes the included image in = sufficient >>> detail. >>>=20 >>> And later: >>>=20 >>> It is an error to have both a "src" attribute and content in the >>> element. >>>=20 >> Yeeps. That later sentence seems wrong, particularly when you look at = the "alt" attribute: >>=20 >> 2.5.2. "alt" Attribute >>=20 >> Alternative text description of the artwork (which is more than = just >> a summary or caption). When the art comes from the "src" = attribute >> and the format of that artwork supports alternate text, the >> alternative text comes from the text of the artwork itself, not = from >> this attribute. The contents of this attribute are important to >> readers who are visually impaired, as well as those reading on >> devices that cannot show the artwork well, or at all. >>=20 > I don't see that as wrong. Content in the artwork element means = Content, no? > What the text is trying to avoid is the ambiguity introduced by > content that = looks almost, but not entirely, unlike T Fully agree, but the "it is an error" is a technical prohibition on = something that the text at the beginning and middle of the same section = allows. I think that prohibition needs to be removed. --Paul Hoffman= --Apple-Mail=_6366E305-088A-476A-9D66-08DFCF4515F8 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAwNDE4MzY1M1owIwYJKoZIhvcNAQkEMRYEFKnk5/vMGcFsIapzWqzz4h7wpCXgMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQAdmVirR5sCyIVHlm+vWaWr8ljxNWgfGoQcGt2etC+GDcKFy45BPlXU/uINr8mvWObTGLdJ YxAUb+FvQh2/srSFAzpcAtfo2ySqOy0b6Elxn/V3CpfTpC0z4HekuR2OdDsH6fby96Qf2SboaP06 ixhxWKVHVdYk5EKqWUMEh5EM5VV8TZKVqzuce0T0nZONO5o5SYJ+7e8k/1g9N9VVptG6bm0g6NJA Z8xXOGmvE2/bhP+jsNL5y8X9LfoHZHd9qVlGMQ+N1TmAaFEgdLpUNM9e33LVtjsRI7PIk7WMPsqD d15v/3ip3CX4YUP7iS531rO78YOZRqTGCDkZWYZpcLb2AAAAAAAA --Apple-Mail=_6366E305-088A-476A-9D66-08DFCF4515F8-- From nobody Thu Oct 4 12:24:30 2018 Return-Path: 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 5A209128CF3 for ; Thu, 4 Oct 2018 12:24:29 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=miek-nl.20150623.gappssmtp.com 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 yhc41w80hVgu for ; Thu, 4 Oct 2018 12:24:27 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B70912785F for ; Thu, 4 Oct 2018 12:24:27 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id q8-v6so10116741wmq.4 for ; Thu, 04 Oct 2018 12:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=miek-nl.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=bywIKSKrOMVUymj/2SFse48QJDutV9Iz5LM4tcuHOas=; b=T0eGlRmO531TiY6kFLhYxtLh/fLqK4UetF2O+mTpm0DQbOSg+4FWG2UA2TC183ZzEJ 9UU71V+tD/nIYOAYqd9jrLce3JwimTkBNqK2M2HkeqzUqlr2TbdDgJXS4v5La0NYj3jm 7/THHkkrZAs50M67YJXPjC6mNVOPhmm03HOl3Eyqt5xeD/n0eH/uS6/v0I/xUwjZcAnF 13Vd1+pqnjQO5I7Naj+MPRGUm44jupsvqtT1F0IkV/+6pSY/zgtDM+L4Ra89MsZi2bNx x/QPqw9hjtQY6EFyMpjSXAfdfOx+fPEX8kQIwp58S5oLIVyxUJy5lGBQ5rBz94DdOM8+ Qj4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=bywIKSKrOMVUymj/2SFse48QJDutV9Iz5LM4tcuHOas=; b=ZDk2WRwedWHO6axChG3H4ebS4aA0GZLX/2osNMeiXXQ74l22WCKGy8A43S6vyYcmeW h/n88yhFToUro4bLUPjBoONqnNdihrTuFZYy5yLcsM7bcxr1SlniXVQpA4RI8GeXh9tz 3Jd2BeqdUjte3eywy2XYAfkrpjHqHXPaQTTBfMvWW8lyQCGnwHKVDjzst+tiRQR04vPZ pkBfkYgedjJRQA0xCijKnUhDgh2++fYOgFEWh13RmGakPrxE8zUkwER8kDWFVZVI8T5e a036VqUXgYlykO3JBzHmAbVxKFb+o9Na+abitAjou60zIEpNW9N4zOrUbIjSuPWPd9n2 gyAw== X-Gm-Message-State: ABuFfoh+yl3NMzV5a4I54boljP88P5wISIvUOvWoK3lROE51tdO5FvUt j1fcfifwltFpkwy3yCwsT8Lx2g== X-Google-Smtp-Source: ACcGV60f2EhJfD4Ah31jOkoez8liqsoYoubrK2035AR/IZTIPueROHZXt2wkPEd/mgZ5U4VaD3KZvA== X-Received: by 2002:a1c:c58b:: with SMTP id v133-v6mr3518790wmf.139.1538681065619; Thu, 04 Oct 2018 12:24:25 -0700 (PDT) Received: from miek.nl (4.3.8.0.6.9.c.b.e.5.6.a.1.b.f.a.f.3.c.4.9.5.f.b.0.b.8.0.1.0.0.2.ip6.arpa. [2001:8b0:bf59:4c3f:afb1:a65e:bc96:834]) by smtp.gmail.com with ESMTPSA id 90-v6sm3568414wrg.86.2018.10.04.12.24.24 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 04 Oct 2018 12:24:24 -0700 (PDT) Date: Thu, 4 Oct 2018 20:24:23 +0100 From: Miek Gieben To: Julian Reschke Cc: Robert Sparks , Paul Hoffman , "xml2rfc-dev@ietf.org" Message-ID: <20181004192423.xexbgomdqs56pkok@miek.nl> References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 19:24:29 -0000 [ Quoting 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
    , but the renderer decides what to do with it? (Or is that an even worse solution wrt to "least surprise") /Miek -- Miek Gieben From nobody Thu Oct 4 12:38:10 2018 Return-Path: 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 ; 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 ; 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 ; 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 To: Miek Gieben CC: "xml2rfc-dev@ietf.org" Thread-Topic: [Ext] Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    Thread-Index: AQHUWnk+g6//hyX+2Uq+Fuv/11Upv6UPzOyA//+t+KyAAHkJgA== Date: Thu, 4 Oct 2018 19:38:03 +0000 Message-ID: <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <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: Subject: Re: [xml2rfc-dev] [Ext] Re: RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 19:38:09 -0000 --Apple-Mail=_A796FFBF-4B38-4DBF-BD75-FB5A24A8338F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 4, 2018, at 12:24 PM, Miek Gieben wrote: >=20 > [ Quoting 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. >>>=20 >>> If we decide that preserving the "only in tables" idea, this avoids = the argument about causing authors unnecessary confusion. >>>=20 >>> If it's clearly a bad idea, please capture why on the list for = later. >>>=20 >>> RjS >>=20 >> + 0.5 to renaming it, if this helps us to come to a conclusion... >=20 > Henrik is better w/ words than I am, and he put forth my thoughts = well. >=20 > How about: just allowing
    , 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 "

    ", 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
    in table = cells). I still think this is a good goal, and if we want to be = consistent, we should just rid of
    . --Paul Hoffman= --Apple-Mail=_A796FFBF-4B38-4DBF-BD75-FB5A24A8338F Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAwNDE5MzgwM1owIwYJKoZIhvcNAQkEMRYEFK+lwQaFgejCk6vTIl2TIN2hag5CMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQAs/j3zqmRXY1wYLaSZ+yLbDdv3nA0qJuB2okZOKPGo5cflgZRwojn7Wafn6ugG4lMu6XRW lAtn/XfDr9RBv2j0WHawDX0PSHd0VXpBrs9H82sQd2QcdY6sTNzbDQH13O07ydqQ3V2PNNeTYmrs FH7Gub2AbVWRj8ZFPDRc40zzEaKHNbBDFaw263FjOYPsDulmsLzdRtm8gXIgou8c72oV4fb+wAUw D9rs8lhmiX0NZE0W2w2yVcqAE94GYKbh3b1Hj6+kJR+4MsT09hIoZsDqk4TPmyFW0XBrFonLfowN m8ZmTRXlb7WyoJMDPhBXYbk4BiNbeUXL0RyHDT7R4EkeAAAAAAAA --Apple-Mail=_A796FFBF-4B38-4DBF-BD75-FB5A24A8338F-- From nobody Thu Oct 4 12:39:45 2018 Return-Path: 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 310B0129C6B for ; Thu, 4 Oct 2018 12:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=miek-nl.20150623.gappssmtp.com 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 0P6hJKYbS5aJ for ; Thu, 4 Oct 2018 12:39:42 -0700 (PDT) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BB43128D68 for ; Thu, 4 Oct 2018 12:39:42 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id r63-v6so10126820wma.4 for ; Thu, 04 Oct 2018 12:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=miek-nl.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=6jN8ouIJou9eBhcT7Vuq/zr7D7JXUJBdapyukE4wGxs=; b=0ttpUQple/BD5MhcUI7OHM6Ynv570CpzCIdkDcCuBpB5IFqvxjPhmUfFhWY44U4Bta BVUlgx61SGXw0Pa6nXhDhaPD5uYdgXLzu6dJCRWDLO1rS8qV4rNJ3i4X7fM3aeICshtg jJfekVEBIIlKHdmmPLv5pj5IWIerycCiDnAci0JFBW6nBLqxONar1usM4v5gkFOi3zIw XoYpgXTZsvRUTMf4dCeiaR7mN1sxQ3GMMyl2dYPPhTW0uAJMTjSxZmz/TROuXMN8v9oC wy/tzr4UPEp4LbVD5E3UFGATS7Lcj7sDoMUD4ERQJWtLu/VafcsDHn/U56v+UGwRGdT8 OVjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=6jN8ouIJou9eBhcT7Vuq/zr7D7JXUJBdapyukE4wGxs=; b=G06PNrijtLoVG6MgyEqKiinzk/0TScxYbu3Fy1q55vpn9VcZnI8xH/NueMZp7yqhBh 5zYvLDglUPk4OVaTpj8/V8VhRdbNnPC67Oaf6dWDS7weA/YbOO8NfMbIUfLeC7hrITsE 0aDGTl+DCK2tSm+e2tApeN13EUJGjGcvZfaL4o/+a8ISh8JBh116GOpetTIOgYieXaAf JNugHMbNJavdRNVRQX65Md4Oo5/aOyfOAISd2pTlcKWD1AQ9Z4v7pBig8k+En5QV9Rjl c1hrdu0sUsxG0RwaVv8qUBRohsDIMxrCqN4kVxjmk+el1t/E7cZ+5cB2u2TXZDJUG55b UEcw== X-Gm-Message-State: ABuFfoiVpy3oBZ3jNwQzZ5n0a8yMbod7eFM/d3pxct7NzSIpW9kez7rX tKwG4MDM+tWbCvzS2wreUKZJWg== X-Google-Smtp-Source: ACcGV62wX1wIkA6J5R4GBnkhRJDJBV2rPeW2FbKdUmxX7qB8rG040SmJmmHDqv1Fk1/X6Mh8fxjArQ== X-Received: by 2002:a1c:e157:: with SMTP id y84-v6mr5431280wmg.22.1538681980781; Thu, 04 Oct 2018 12:39:40 -0700 (PDT) Received: from miek.nl (4.3.8.0.6.9.c.b.e.5.6.a.1.b.f.a.f.3.c.4.9.5.f.b.0.b.8.0.1.0.0.2.ip6.arpa. [2001:8b0:bf59:4c3f:afb1:a65e:bc96:834]) by smtp.gmail.com with ESMTPSA id 63-v6sm7582649wmj.39.2018.10.04.12.39.39 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 04 Oct 2018 12:39:40 -0700 (PDT) Date: Thu, 4 Oct 2018 20:39:39 +0100 From: Miek Gieben To: Paul Hoffman Cc: "xml2rfc-dev@ietf.org" Message-ID: <20181004193939.szec4ng47kp7lapv@miek.nl> References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Archived-At: Subject: Re: [xml2rfc-dev] [Ext] Re: RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 19:39:44 -0000 [ Quoting 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
    in table cells). I still think this is a good goal, and if we want to be consistent, we should just rid of
    . If that's technically possible: +1 for removing
    entirely /Miek -- Miek Gieben From nobody Thu Oct 4 14:33:59 2018 Return-Path: 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 505FE12D7EA for ; Thu, 4 Oct 2018 14:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 vvhIFmLGfjiM for ; Thu, 4 Oct 2018 14:33:56 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1763E130934 for ; Thu, 4 Oct 2018 14:33:55 -0700 (PDT) Received: from [192.168.178.20] ([91.61.61.129]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LpPg1-1fTdI91g3x-00f7rH; Thu, 04 Oct 2018 23:33:18 +0200 Received: from [192.168.178.20] ([91.61.61.129]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LpPg1-1fTdI91g3x-00f7rH; Thu, 04 Oct 2018 23:33:18 +0200 To: Miek Gieben , Paul Hoffman Cc: "xml2rfc-dev@ietf.org" References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> From: Julian Reschke Message-ID: <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> Date: Thu, 4 Oct 2018 23:33:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20181004193939.szec4ng47kp7lapv@miek.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:e5NuCovdv9OsYtYcAVLRXihTJ8dycfrihmoKc5/p3oCeOr6Yv5D RKA8QT/CWMRGdLYtvS+9nKdxA7G/cQoVgKIynKqGox7ahTFIK0LfFCOxM+U9NJUmdTyEPam 0+p+snIyqAL3573BwECizM+WJKa+LTTHyCk3KffaeS/E0Zb8xZzhD0i59XXZqs8j3U7iTKg sMJCn6rDhv50BL4zlNp8A== X-UI-Out-Filterresults: notjunk:1;V01:K0:RU8Hf7fTfs8=:IpVI8/hlgREB+pxXrxVsTH /s9JNc17biOphpN920RQn9SCe6c1Z+cdH8GsTk6v+CIcuJpCH3slCXOmzKCpcg+R72U1vK+7O 6lRmiFEnpnivboA+smKhp56avifeRltQtdfT6Xh+n2ts1pH/jKiK937qRQSWPxcNDYPndGXHB EsxeYG+1n3sEGxbpAJQHFDrQjnb37YsZivKRY2tQPAbv1QMh7Mjr5l6cQIfYmPJQ+r906hyg5 kfSjqbg2dliLQLmdlL13ZPXdDffNj0kvIDO8CPVnLCWDdCcFGlpCr5rm5L6N7BKRjqnuLSR9j 0yebYO86Qdwtn4of94h9ny6UcqZHw2Lnt2CFs6xy1DIao/TZ0mVhoDO+H3oYwmZMDF8NVDsAs VKhjKQ5raURLW1DJz10HgzzPnk0Yt7SLEbe2ie+aZ6eXGz/PLCgpRnDRyFhmfMZOUXrCE9zcD bzK7pwfhhehcgy04HWxd4LZ7i/RvO30QgmV1CTf96lHMzqVU46oT7oUDkDGoSDkPAvYtAcsa7 OboNXT1r41xt9RtCKvthRwvdejBJ0v8Mi0Cvw+tmXZbOwjwFUdSVy7yXlg+/kWAaXxK7pZ3+K aOsA0I6IAYKS/HCEJe8mRgzBCFaCr7zfY3TyfdgRDZ33WhgabKoGJ8LLGrbYzl1j2EpqgnlCf kW9Cne0R66bzEecHo1jngnFpEL+Yimhn9glsXUxrpJHms3jKue80IcHNvTn8ZARo/vWjdUIFO Jln3HyBM18zpHgVindzh3QxwwXC6/TOOiVq+cXBn2GYVb0eDVDBtnOByRo3Ea/2B1Fz0R5TWJ /TgqRn2Dz35SavZxEJe8t1dx5I2EEmD1rBvq56WIlBRtZg31/8= Archived-At: Subject: Re: [xml2rfc-dev] [Ext] Re: RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 21:33:58 -0000 On 2018-10-04 21:39, Miek Gieben wrote: > [ Quoting 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
    in >> table cells). I still think this is a good goal, and if we want to be >> consistent, we should just rid of
    . > > If that's technically possible: +1 for removing
    entirely 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 nobody Thu Oct 4 14:34:08 2018 Return-Path: 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 8841F12D7EA for ; Thu, 4 Oct 2018 14:33:59 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 HSIc6eOWWv6z for ; Thu, 4 Oct 2018 14:33:57 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0220130DE3 for ; Thu, 4 Oct 2018 14:33:56 -0700 (PDT) Received: from Jude (192.168.0.11) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 4 Oct 2018 14:29:14 -0700 From: Jim Schaad To: 'Paul Hoffman' , 'Robert Sparks' CC: References: <66bebdb0-3587-0c73-4b0a-5e47fbe6536d@nostrum.com> <87A4F4E0-99B9-4375-94D9-28164B31DBCD@icann.org> In-Reply-To: <87A4F4E0-99B9-4375-94D9-28164B31DBCD@icann.org> Date: Thu, 4 Oct 2018 14:33:48 -0700 Message-ID: <043701d45c29$f1af7790$d50e66b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKK6M7h3owTAhLW+tsIWU8aAVAylwHYeYQ4AfsvI38CY6VpYaNwxc0Q Content-Language: en-us X-Originating-IP: [192.168.0.11] Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #34: src and content confusion 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 21:34:00 -0000 > -----Original Message----- > From: xml2rfc-dev On Behalf Of Paul > Hoffman > Sent: Thursday, October 4, 2018 11:37 AM > To: Robert Sparks > Cc: xml2rfc-dev@ietf.org > Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #34: src and content > confusion > > On Oct 4, 2018, at 10:31 AM, Robert Sparks wrote: > > > > > > > > On 10/3/18 6:33 PM, Paul Hoffman wrote: > >>> Section 2.5 > >>> > >>> Alternatively, the "src" attribute allows referencing an external > >>> graphics file, such as a vector drawing in SVG or a bitmap graphic > >>> file, using a URI. In this case, the textual content acts as a > >>> fallback for output representations that do not support graphics; > >>> thus, it ought to contain either (1) a "line art" variant of the > >>> graphics or (2) prose that describes the included image in > >>> sufficient detail. > >>> > >>> And later: > >>> > >>> It is an error to have both a "src" attribute and content in the > >>> element. > >>> > >> Yeeps. That later sentence seems wrong, particularly when you look at the > "alt" attribute: > >> > >> 2.5.2. "alt" Attribute > >> > >> Alternative text description of the artwork (which is more than just > >> a summary or caption). When the art comes from the "src" attribute > >> and the format of that artwork supports alternate text, the > >> alternative text comes from the text of the artwork itself, not from > >> this attribute. The contents of this attribute are important to > >> readers who are visually impaired, as well as those reading on > >> devices that cannot show the artwork well, or at all. > >> > > I don't see that as wrong. Content in the artwork element means > Content, no? > > What the text is trying to avoid is the ambiguity introduced by > > content that > > looks almost, but not entirely, unlike T > > Fully agree, but the "it is an error" is a technical prohibition on something that > the text at the beginning and middle of the same section allows. I think that > prohibition needs to be removed. I have never been really happy with this. I would have preferred to keep both the "good" artwork and the "alt" artwork as first class citizens of the artwork element. I don't want to have a 55 line ascii art version of the picture. I realize that this is legal but ugly. There should perhaps be an "alt-src" attribute which could be used to pick up the alt version from a file and then only could end up with a really long alt attribute only after running the prep-tool. Jim > > --Paul Hoffman From nobody Thu Oct 4 14:53:45 2018 Return-Path: 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 B1AF512D7EA for ; Thu, 4 Oct 2018 14:53:43 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=miek-nl.20150623.gappssmtp.com 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 FsFYJJuo-XGF for ; Thu, 4 Oct 2018 14:53:40 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97F55130EB3 for ; Thu, 4 Oct 2018 14:53:37 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id a2-v6so4420024wrc.13 for ; Thu, 04 Oct 2018 14:53:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=miek-nl.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=umqnw0xEE3XpBLzj7hjfpqutxuFirBFRjh3P3dFFRjE=; b=SYrRoiQhKbwfCXiKvo715TY1VBiGe9j/+1NMY5XJCb+dyzMuZkHESDdpCK84myf1GO HXQU3GcCnSeLyFoNJafMijJtRYtQwx9X9CWkToggcrHBSQUIrnLhvLfHnprPGDYt6BBX vx60OpjZMOO4cvMi8A0J97IuM7OP7DoKSM6do+rNNCWGrUscSTnRgNJR/XvpYLIc8KVG c16upIcj2e6vE8LbXLCcJvlsV5c8I3vVNWvCVWTneRlk/qEoiTRlns4jH2SR53M1ayuy dWY3fg1SYwKPATkSWWOXbDKCm0CeqlpuQeptqpZCpmZtVksEiGWX7VLLrHL1bL9FPr1b 4MfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=umqnw0xEE3XpBLzj7hjfpqutxuFirBFRjh3P3dFFRjE=; b=b+QohuHJ0+f5BgKjhJUmhUa8aaPb8+oysth20ClKPBPDUMQzK4t6/2KoRRFnnpaJI1 VWrv7IMxdDJp1JCyjua+W6aMX6N4mFETgHhpwVEZnfqiFtltLonS9aUHoIZUzVrYqC6M a6cjd64s1Mc+t1K+FVXb7F2pEJS09VRt/HV2rRE2O+EyiZVFppG1++YMWmP4uVF8ZTh8 Bnw2iglBjyIsQoRcPoQmIi69O4CM42eLf6x3ZWHCVxQN0wV2R56ii7xcBJkJ0lIDU4uI ko7HurWtYDTIaWTMP25GU+yU+X9dhc8w5dxLZzk6Ii1rnxewnwyZLq9ahbrrY6AuBcCE pFww== X-Gm-Message-State: ABuFfojQyPxWefFMWPmVPW4Ti0wkGz7Qry92DIZRcnzvmvAti3P1u5ZS 1ckzWjxK8o9kp4blonxlzSx35A== X-Google-Smtp-Source: ACcGV61wKEZeqodljc1a9+N+3RXZcM1Kswxe+Td2bcXSeBPttYcxjpYuQEpZhB61fumh8tdZpiqN5A== X-Received: by 2002:adf:f9d1:: with SMTP id w17-v6mr6168397wrr.293.1538690015911; Thu, 04 Oct 2018 14:53:35 -0700 (PDT) Received: from miek.nl (4.3.8.0.6.9.c.b.e.5.6.a.1.b.f.a.f.3.c.4.9.5.f.b.0.b.8.0.1.0.0.2.ip6.arpa. [2001:8b0:bf59:4c3f:afb1:a65e:bc96:834]) by smtp.gmail.com with ESMTPSA id g75-v6sm8306186wrd.1.2018.10.04.14.53.34 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 04 Oct 2018 14:53:34 -0700 (PDT) Date: Thu, 4 Oct 2018 22:53:31 +0100 From: Miek Gieben To: Julian Reschke Cc: Paul Hoffman , "xml2rfc-dev@ietf.org" Message-ID: <20181004215331.gdn7euf6qt3mlg2w@miek.nl> References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Archived-At: Subject: Re: [xml2rfc-dev] [Ext] Re: RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 21:53:44 -0000 [ Quoting in "Re: [xml2rfc-dev] [Ext] Re: RFC 799..." ] >>If that's technically possible: +1 for removing
    entirely > >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. 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 nobody Thu Oct 4 14:54:55 2018 Return-Path: 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 B8FD2130934 for ; Thu, 4 Oct 2018 14:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Yf6E2sOihtAU for ; Thu, 4 Oct 2018 14:54:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BA5D12D7EA for ; Thu, 4 Oct 2018 14:54:53 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:57691 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g8Ba8-0007Uw-0M; Thu, 04 Oct 2018 14:54:52 -0700 To: Julian Reschke , Miek Gieben , Paul Hoffman References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> Cc: "xml2rfc-dev@ietf.org" From: Henrik Levkowetz Message-ID: Date: Thu, 4 Oct 2018 23:54:44 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="l5bWnrI2ih9XXV7kL5EBVnTpkH1SeEPDq" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, paul.hoffman@icann.org, miek@miek.nl, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] [Ext] Re: RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 21:54:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --l5bWnrI2ih9XXV7kL5EBVnTpkH1SeEPDq Content-Type: multipart/mixed; boundary="vxwBgcpK2jmXAdh2q6FFv1J7qTcT2tcKW"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , Miek Gieben , Paul Hoffman Cc: "xml2rfc-dev@ietf.org" Message-ID: Subject: Re: [xml2rfc-dev] [Ext] Re: RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> In-Reply-To: <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> --vxwBgcpK2jmXAdh2q6FFv1J7qTcT2tcKW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Julian, On 2018-10-04 23:33, Julian Reschke wrote: > On 2018-10-04 21:39, Miek Gieben wrote: >> [ Quoting in "Re: [Ext] Re: [xml2rfc-dev] RFC= =20 >> 799..." ] >>> One of the design goals for v3 was to get rid of markup that had no=20 >>> semantic meaning to the documents. We mostly succeeded at that, but=20 >>> clearly failed to clean up some of it (such as by allowing
    in=20 >>> table cells). I still think this is a good goal, and if we want to be= =20 >>> consistent, we should just rid of
    . >>=20 >> If that's technically possible: +1 for removing
    entirely >=20 > Misleading. >=20 > HTML can focus on semantic markup, because it has a sister technology t= o=20 > deal with presentation (CSS). We don't have that, so we need to conside= r=20 > common cases where a default presentation just isn't good enough. >=20 > 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. For me, it's not that. It is adding
    for that case, and not for others where it would be just as useful. It's the inconsistency. Best regards, Henrik --vxwBgcpK2jmXAdh2q6FFv1J7qTcT2tcKW-- --l5bWnrI2ih9XXV7kL5EBVnTpkH1SeEPDq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu2jCQACgkQTptXS4+7 FxqWkRAAl4XhN4VpKnii3lmx3B7Qicm2Po64SSSqHxcs4t1123Q/E39HswAwhDTy U9IF7vfTD/F3ozLWADTfy8SgsrKOCJSghTC6KwUzQ2jNFLzWzIq2cvPSoyRHEwvN 6TMg0WQ6gDqAVjBgzjOUqXivycfF7C3YvOVWcs3YN/bTvNYlyLl679tXnyyEyho3 E4jzBAuo9zX5Jks5bXWNgRPSFQNY5d34uF00+SNt4XY6bI1mRuxWMWX+3WWHpBzF PIU9BcAgwTxb2wSLnUxOC76hR8/tbceZOLfajnjmFRnk5vVJ98tW2rlIUuVneZx7 AlT85yGitkfoOUcgAf6TYc2MHKm4iRqDktRza1moaeOkbssPvFz0Ythy/gBrZwwj KOLwoWYDb85UMELvog1KVQYrE7lQLKU7p0/dZzJjLCDgZwySor9UMgyBSJoO5JS4 GrcgdXG0BIoGlfL0qFEYXvGkOSTY5VAFbwVdQzGOpyEgsnnpYc9DSYKPFRTLGxTP C34IccH6p0dI6ijvauM/dVVILz4cjPTLFSB+qbWdCD+WAizFVGmudwKVSRliGz6D z4is6Wgqba0z9cILem/Lh+eiZv+HMWbvNctQFJcBy4xp3Jdx/q4pt/uOyvkMqKJS 08oTREH3JdqUmLQ9JpDh1a3HX+IcV8TdWvCIS0s7J1nCQFRrbow= =SFwu -----END PGP SIGNATURE----- --l5bWnrI2ih9XXV7kL5EBVnTpkH1SeEPDq-- From nobody Thu Oct 4 21:35:18 2018 Return-Path: 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 9C6D2130DC7 for ; Thu, 4 Oct 2018 21:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Bxj9NYlxoODO for ; Thu, 4 Oct 2018 21:35:15 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5BA41292F1 for ; Thu, 4 Oct 2018 21:35:14 -0700 (PDT) Received: from [192.168.178.20] ([91.61.61.244]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M6AbC-1fnk293dUI-00y8UC; Fri, 05 Oct 2018 06:35:11 +0200 Received: from [192.168.178.20] ([91.61.61.244]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M6AbC-1fnk293dUI-00y8UC; Fri, 05 Oct 2018 06:35:11 +0200 To: Miek Gieben Cc: "xml2rfc-dev@ietf.org" References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> <20181004215331.gdn7euf6qt3mlg2w@miek.nl> From: Julian Reschke Message-ID: Date: Fri, 5 Oct 2018 06:35:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20181004215331.gdn7euf6qt3mlg2w@miek.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:RXB5SaoYBI2V5A6stkkLoG4YgYeibSPrn+jkJfjq4TNyj/VqQX6 8ZMK/R8phySQPZgPaeReS8fw9OucKXUc/DJHzPJcAc+H9mdoQdT/jxvlNZT9WNZg6bXjuVT HjD7i+xQbcp1s+9PFBnQ2OaX1z73zuG138dhpbZdRQ8ZsTqq0espRcV2XlTfse0mFsKQYi5 mEqj3hOWkhSUkqAi5ZBAQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:mBFyT8SujMw=:EDQeJ/NIPSVfvE9Ek+xpzV BLuluUTaypXHMCSvdXjw8K9CUQTmdx3Za4QXDsOBGLEDCW22CF8UZh4DdYvd3HXOVf2GJk78o 9Wib5YPIYMXay8ra2wAJwIHxZFF9IQ7YkOw0qjWKJPYIjUOHcWdECKG9AdAwZmhb3jROMDHh5 OOyZN7ctmpR/49Zif2SiOI8b/mCtjHDnXt9HKftWy5DFeaZAa02dPv3IeZ5hWwlo2u0fiwBUB rlIBiwyT2Of7gg/8GGcnjhGvRAwV+K3SPTYXneIz+D0QdDonNps47Nv//ag8r3rFjYPIgCrVW XYSIVO+RXYd2Y+32lX2mSoO8ssfgqyqxdC/DWDa4X/0hYP8ClyneM9mk9WOG3NnCLgLdRbyY2 m6eFZ+06MeXQ7uSdY6pejINU1ePQEp3DB2qdQF07odIeIkQvuqgaUJVE6nF9KwtcM/y+camHf FGdo63zekbQ/kYz+pidhW6ABHaLZGZlNKisr3bKi9DQdNMQlNwkHJK4KDbcLo08OWRqCqJ69d R+rUSq0aKjh6zufpudgm6SSwJkHHGKmg5gwnsTFKjSkwaq+686Zk0vEtT3yPMUoU9m6eUeRh8 5bIiSdX+7prjNS8mH/da5q2oZ/BfMVeUjM/Ib4ktrxbE9iYfxz+7NitICZqjtJSlQa4XcufYE c2C8qAAX8RTkOe0duZ906qVXvzebw/LQpJTI0UGIYo15sK2XNIhf2w6D7FNQ07S0tEiXnkL1R C97T9m768tLt4rqZKwrQmdGOjmAgLD7JwQ7bXuMpZm2UYRprDm2wWamruAAEwWcz1m+2BMtfZ Gd0RYyn/NbBy+qW5AmYJ9IUGXPJOWTn52HUQDpXUOw9gdB+E6Y= Archived-At: Subject: Re: [xml2rfc-dev] [Ext] Re: RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 04:35:17 -0000 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 nobody Fri Oct 5 16:13:34 2018 Return-Path: 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 E1937128B14 for ; Fri, 5 Oct 2018 16:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 hTwQbH0Q9-sP for ; Fri, 5 Oct 2018 16:13:31 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 248C21277D2 for ; Fri, 5 Oct 2018 16:13:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id F32D21D06EB for ; Fri, 5 Oct 2018 16:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymC_CWGPc1uk for ; Fri, 5 Oct 2018 16:13:14 -0700 (PDT) Received: from Heathers-MacBook-Pro.local (unknown [IPv6:2603:3023:30a:e7e0:e09c:5a89:3a95:badf]) by c8a.amsl.com (Postfix) with ESMTPSA id B9B461D06E9 for ; Fri, 5 Oct 2018 16:13:14 -0700 (PDT) To: xml2rfc-dev@ietf.org References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> From: Heather Flanagan Message-ID: <65f7d2f9-21ed-c7a1-a234-05e00e1c7dae@rfc-editor.org> Date: Fri, 5 Oct 2018 16:13:30 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 23:13:33 -0000 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
    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 . That will prevent >>> people who "know" what
    "means" from expecting it to work >>> because
    doesn't exist. >>> >>> If, later, we want to add
    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
    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,
    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
    to will deal with the expectation of
    being > generally useful, since it's not called
    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 if
    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
    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
    widely, or removing it. I still don't > care much either way, but seems to provide neither the cleanness of > removing
    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
    is introducing here, making tooling that much more complicated. After reading all the arguments, I'm going to say we remove
    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 nobody Sat Oct 6 06:04:54 2018 Return-Path: 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 2AA15130DE1 for ; Sat, 6 Oct 2018 06:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 t4GLtZVpSqOx for ; Sat, 6 Oct 2018 06:04:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5F09130DC2 for ; Sat, 6 Oct 2018 06:04:51 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:49572 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g8mGJ-0006vL-An; Sat, 06 Oct 2018 06:04:51 -0700 To: Heather Flanagan , xml2rfc-dev@ietf.org References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <65f7d2f9-21ed-c7a1-a234-05e00e1c7dae@rfc-editor.org> From: Henrik Levkowetz Message-ID: <07c79cc9-5228-3eb4-32db-b2de53b480e7@levkowetz.com> Date: Sat, 6 Oct 2018 15:04:29 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <65f7d2f9-21ed-c7a1-a234-05e00e1c7dae@rfc-editor.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ecX1S1lvLXp6U7r35iCE5f1MsCs3CKJEM" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, rse@rfc-editor.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2018 13:04:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ecX1S1lvLXp6U7r35iCE5f1MsCs3CKJEM Content-Type: multipart/mixed; boundary="i09GphTnHS45S4E7LRqNVrDMALBXU07oG"; protected-headers="v1" From: Henrik Levkowetz To: Heather Flanagan , xml2rfc-dev@ietf.org Message-ID: <07c79cc9-5228-3eb4-32db-b2de53b480e7@levkowetz.com> Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <65f7d2f9-21ed-c7a1-a234-05e00e1c7dae@rfc-editor.org> In-Reply-To: <65f7d2f9-21ed-c7a1-a234-05e00e1c7dae@rfc-editor.org> --i09GphTnHS45S4E7LRqNVrDMALBXU07oG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Heather, On 2018-10-06 01:13, Heather Flanagan wrote: > Hola a todos! >=20 > Apologies for letting this thread get a bit out of hand. Airplanes and = > small, on-site meetings are not conducive to handling active threads. >=20 > This isn't an IETF WG, but we're going to work along those models for=20 > sake of clarity. Consider me the WG chair for the purpose of consensus = > calls and breaking deadlock decisions. Thank you. Much appreciated :-) And good to have a decision on issue #3= 7. 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 Monda= y. Best regards, Henrik --i09GphTnHS45S4E7LRqNVrDMALBXU07oG-- --ecX1S1lvLXp6U7r35iCE5f1MsCs3CKJEM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu4st0ACgkQTptXS4+7 FxrEaA/7BxBhu46Mc1ddQ8wa22tKQ4mpABwEjOUKMs1e244PLe8hceFxvKGJpu3x hpn55pQDQrTCitZkVMMKsZwVPnA/GuVOK0PAIvN39juShy1b34axs+R9jwOhbora 895619djlI5XvznbIfPdZCxZkFk0oNNShUN9B8JROSUh8e9gp9aIT07k4/QGn30j x9MXP3iiQ0IqZedrtzns7xDT8ZITw55p2X6Gyb7bM8VTDQPcu72lliul3ftECOAM OpdCgPzqLVNa6pBem7vdkPEp61nh4OQQAiUQY6JJQ9L1hKbY6QKVtvfW7Q2Xq0Cs waRfb6x0Lbg+XNLZnaHVq+/xXuPlNVs3+bZHg+ydUYa36euzOMUBoTYNk4hWniEv ea7njCkoZPDvxG9VGIXsIzuBy3Zdc9V5hVqewYVBDp48xq1zHuLTTDvM/X6PcOec pwE9xsmepVEzz+zAa0PA8OiCi5UQZ4ExnTsqVpoN2WRjGxEc6u8R9tfTdgmqsqz3 bbMhqPAJSmP4NuWwFw+QOtarm5R6CNhNsnJnyLqpWl0WGFLqxzjUyc2RRUOK7Zes tWutMcIPT3QnPPiIpsfko5r3hJQ+XMpQaS1Gp0H3pIKnFCHYivcshgu23hiaMh6X 1v4h2s27T1NEAc0Jx6JwpzlCd3B3UpdvYEXji4ehQIDmfLPkArs= =B4OX -----END PGP SIGNATURE----- --ecX1S1lvLXp6U7r35iCE5f1MsCs3CKJEM-- From nobody Sat Oct 6 08:03:29 2018 Return-Path: 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 D6075127133 for ; Sat, 6 Oct 2018 08:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Ia_xf-GPV_0T for ; Sat, 6 Oct 2018 08:03:25 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6020612426A for ; Sat, 6 Oct 2018 08:03:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 348EA1CA42E; Sat, 6 Oct 2018 08:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPWv-ANkoV_k; Sat, 6 Oct 2018 08:03:08 -0700 (PDT) Received: from Heathers-MacBook-Pro.local (unknown [IPv6:2603:3023:30a:e7e0:1d1b:43c9:5488:d7d6]) by c8a.amsl.com (Postfix) with ESMTPSA id EF7B41C6297; Sat, 6 Oct 2018 08:03:07 -0700 (PDT) To: Henrik Levkowetz , xml2rfc-dev@ietf.org References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <65f7d2f9-21ed-c7a1-a234-05e00e1c7dae@rfc-editor.org> <07c79cc9-5228-3eb4-32db-b2de53b480e7@levkowetz.com> From: Heather Flanagan Message-ID: <38d5e402-cfc9-6927-cd7e-2c03feede59a@rfc-editor.org> Date: Sat, 6 Oct 2018 08:03:20 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <07c79cc9-5228-3eb4-32db-b2de53b480e7@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2018 15:03:27 -0000 On 10/6/18 6:04 AM, Henrik Levkowetz wrote: > Hi Heather, > > On 2018-10-06 01:13, Heather Flanagan 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. > 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. 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 nobody Sat Oct 6 09:05:32 2018 Return-Path: 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 D977F130DF3 for ; Sat, 6 Oct 2018 09:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 W3qea4yDfk2n for ; Sat, 6 Oct 2018 09:05:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84C57130DDA for ; Sat, 6 Oct 2018 09:05:27 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:50006 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g8p53-00041p-QC; Sat, 06 Oct 2018 09:05:26 -0700 To: Julian Reschke , Paul Hoffman , XML Developer List References: <39D3AA2F-E6C0-4648-9764-9ADE7644477E@icann.org> <43399229-fecd-b74b-2f47-1b811f76f92c@gmx.de> From: Henrik Levkowetz Message-ID: Date: Sat, 6 Oct 2018 18:05:17 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <43399229-fecd-b74b-2f47-1b811f76f92c@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5RcuWpoGM8iwpvxGVwVSaI66eoepga3lJ" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, paul.hoffman@icann.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #35:
  • can't contain a block quote 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2018 16:05:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5RcuWpoGM8iwpvxGVwVSaI66eoepga3lJ Content-Type: multipart/mixed; boundary="3L0s2V7lW00dl2b5aOgUkitPnEN3BnLJa"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , Paul Hoffman , XML Developer List Message-ID: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #35:
  • can't contain a block quote References: <39D3AA2F-E6C0-4648-9764-9ADE7644477E@icann.org> <43399229-fecd-b74b-2f47-1b811f76f92c@gmx.de> In-Reply-To: <43399229-fecd-b74b-2f47-1b811f76f92c@gmx.de> --3L0s2V7lW00dl2b5aOgUkitPnEN3BnLJa Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-10-04 08:36, Julian Reschke wrote: > On 10/4/2018 1:20 AM, Paul Hoffman wrote: >>> The
  • element https://tools.ietf.org/html/rfc7991#section-2.29 can= contain quite a bit of block elements, except
    (among others= I think). Why? >>> >>> In v2 xml ones usually works around this by mimicking the layout by a= busing another element. Seems strange to do this here as well. >>=20 >> If I remember correctly, the idea was that list items are already inde= nted, and indenting blockquotes in a list item might cause weird output. = In retrospect, that doesn't seem like a great argument. >>=20 >> Does anyone still want to prohibit blockquotes in
  • ? >=20 > +1 to allow it... +1 Henrik --3L0s2V7lW00dl2b5aOgUkitPnEN3BnLJa-- --5RcuWpoGM8iwpvxGVwVSaI66eoepga3lJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu43T0ACgkQTptXS4+7 FxqRiA/+OF4w9uhikQgiTx5OBv+A+G9Jv1AxzVNRz2FKWWcELqytwssEtbTzGBd2 yjuy8XfeVcKb+PpFwJJFp+gVpj8zVkahwiQH1JQnjeaQcthIabn63nUgNOWU98PQ s4pkkI+vB8OgmDtVzttVp0jmk3VO6Tmh3CCh6nNPWxSJI+CLV6biCNZUlMZs0mkO OGM74UoopJ+dNv/Cc11wJ+JDA+QL9TRQMegLuMFkS/MK3BYsfBtqEtfJFTdHmcS1 QHroLX89wePcRSOVZFquWbXednlMwmE3tooMegBlWT4Fvq88bSThIou/3LnZXxJd MklJSr18/6Xm3bEtpAUjHKYb7xiK5SupYRFSSuN4S7w4rDLPwvohpzp64s20aKyp 2xFzytbmOl5V+kPIvCN8A2YvkgmC4Q7M8SBt9igwd8L8E4ajPy/u1HVDfhfSBF3m apQ0sbJZb6X2LFAADUfdgMrYJoh5DiFZygUm6Q1BpEQ62hs0j5OMaaFNG77okWOI glh7mtuy+GExFQ3SQYP4R9zdXFbdc7s2tKLyHA0/3grDad8BTwZKeRbVR85og6/C X2ZZhcv1ebLs0AN8MDqQ2+etjngupviQFAO0Fbkx9TCRhzSDSNPTzOeVjoDgNqah NEsCrnGOxrs2O+fUEcMNeqysZHhJr6Nv2ktHjwX74FHg7H9xC4w= =9McP -----END PGP SIGNATURE----- --5RcuWpoGM8iwpvxGVwVSaI66eoepga3lJ-- From nobody Sat Oct 6 09:33:03 2018 Return-Path: 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 AFA47130E00 for ; Sat, 6 Oct 2018 09:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 dSi9zEBzwOCz for ; Sat, 6 Oct 2018 09:32:59 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1A4F130DDA for ; Sat, 6 Oct 2018 09:32:59 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:50086 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g8pVi-0000OK-0g; Sat, 06 Oct 2018 09:32:58 -0700 From: Henrik Levkowetz References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> To: XML Developer List Message-ID: Date: Sat, 6 Oct 2018 18:32:50 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KB6pgq41nl70NFF4L99I612IpC2O3CLJL" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: miek@miek.nl, xml2rfc-dev@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, In Section 2.54, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2018 16:33:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KB6pgq41nl70NFF4L99I612IpC2O3CLJL Content-Type: multipart/mixed; boundary="vkVOrqjcP2MODJEKjHT99mjFIpWBp5QQ1"; protected-headers="v1" From: Henrik Levkowetz To: XML Developer List Cc: Miek Gieben Message-ID: Subject: RFC 7991 issue #31: Schema Issue, RFC 7991, In Section 2.54,
    References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> In-Reply-To: <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> --vkVOrqjcP2MODJEKjHT99mjFIpWBp5QQ1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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
    has no provisions for having a caption. The discussion subsequently sorts this out, pointing to the use of the 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 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 to provide a caption. The discussion subsequently mentions the discrepancy between table and figure permitting , while doesn't. To clarify this, it might be good to point out in Section 2.5. 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
    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
    . - 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 to provide
    captions. There is one unresolved schema issue (align keyword for
    ) and one layout issue which will be fixed in the next xml2rfc release. Best regards, Henrik --vkVOrqjcP2MODJEKjHT99mjFIpWBp5QQ1-- --KB6pgq41nl70NFF4L99I612IpC2O3CLJL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu447IACgkQTptXS4+7 Fxo6Zw//clC0PTdKjo1Ijvv8QIPz6CGYGSqRENjox6f3h+KcqP6y3/DpGoXiIvD3 wt9gFibBeOEL0FOGExso+zhEZ/WtRNkMn+O5y+4gzVf4O3bFzn3fKA+Xc9NZgUAt PSjK03P7lRVN4O7KiNsb4/jhYoKb9W+grSreNqfEIq9e0rioEQ54aj9gWYr4tn0U YroyBlOCRnA0zY8BMSoPp6619T+1yhASVxtCY4Q6qxZ3qOEvKb+WZAb/WwgDGZgt 6jP/101HVx/s8ucYGOYrIIxVQy7Jj/2QGZMFXuNUXmzWtAuPaufRUpsaebFgD0tI Bo0mBsMuZzCI/NIsdrEpGYaDxvLnOwQ5QlAqMvk3UUg0XhDYdOvdbXspMtcYU+m2 dHeGKKT58d1Hg4+InK0Ph59IAaCH/kXV0I86EsY5OJw5iiSmePbSq+7NlanzFVQE YDJs9ePhCCqTGK96SPyTxQW79xs8PQgoTsvPEN5eMFv6wxY935LndN2Ax6Z1amS0 XwMwyONmRWaNI/151vCtFErsa8B6oPGljeUwl6UluQFxV4ekJ9AVfYXPssg+VMRZ KO+kxoOdbL/QE5suNg/zBBWmlrsXr7K+6Ix7HWKYAWegAom6y9dDI2TNaMCrg9iP Hf2ewFxAk7Z2wbzmbnTasBVBFQ/otYvx39p6gGjQYw/dNN3YjOE= =p7Xf -----END PGP SIGNATURE----- --KB6pgq41nl70NFF4L99I612IpC2O3CLJL-- From nobody Sat Oct 6 10:10:22 2018 Return-Path: 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 582AE128CE4 for ; Sat, 6 Oct 2018 10:10:21 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 yzsdQ5beMhef for ; Sat, 6 Oct 2018 10:10:19 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF418130DDF for ; Sat, 6 Oct 2018 10:10:18 -0700 (PDT) Received: from Jude (192.168.0.11) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 6 Oct 2018 10:05:36 -0700 From: Jim Schaad To: 'Henrik Levkowetz' , 'XML Developer List' References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> In-Reply-To: Date: Sat, 6 Oct 2018 10:10:09 -0700 Message-ID: <050c01d45d97$714e51b0$53eaf510$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKlc/I8qUpx6H6sTpIQv3vHmEIb5gGMQXb8AverSrcCvXax5QHGvedgAOtPwScCpgcF3ADkS5KAAqj1aRQB/yc3qAHvHWwdos+dOrA= Content-Language: en-us X-Originating-IP: [192.168.0.11] Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, In Section 2.54,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2018 17:10:21 -0000 > -----Original Message----- > From: xml2rfc-dev On Behalf Of Henrik > Levkowetz > Sent: Saturday, October 6, 2018 9:33 AM > To: XML Developer List > Subject: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, In = Section > 2.54,
    >=20 > Bringing this issue to the list. The issue was raised by Miek: > https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/31 >=20 > This issue starts out by stating one problem, namely that
    has = no > provisions for having a caption. The discussion subsequently sorts = this out, > pointing to the use of the element for a table in order to = provide the > caption. >=20 > In order to make this clearer, Section 2.54 probably should mention = the usage > of 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 to provide a caption. >=20 > The discussion subsequently mentions the discrepancy between table and = figure > permitting , while doesn't. To clarify this, it might = be good > to point out in Section 2.5. 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
    so that it can get a Figure number. >=20 > Finally the discussion moves on to the alignment of table captions. >=20 > There are 2 issues here: >=20 > - 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
    . 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.=20 > - 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. 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. >=20 > To sum up: I think there are some improvements that could be made to = the > document text, to clarify the use of to provide
    = captions. There > is one unresolved schema issue (align keyword for >
    ) 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. >=20 >=20 > Best regards, >=20 > Henrik >=20 >=20 >=20 >=20 From nobody Sat Oct 6 10:39:26 2018 Return-Path: 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 E5367130E0C for ; Sat, 6 Oct 2018 10:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 beOQuBrpx5E4 for ; Sat, 6 Oct 2018 10:39:22 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8716130DEE for ; Sat, 6 Oct 2018 10:39:22 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:50220 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g8qXx-0004h0-Uc; Sat, 06 Oct 2018 10:39:22 -0700 To: Jim Schaad , 'XML Developer List' References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> <050c01d45d97$714e51b0$53eaf510$@augustcellars.com> From: Henrik Levkowetz Message-ID: Date: Sat, 6 Oct 2018 19:39:14 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <050c01d45d97$714e51b0$53eaf510$@augustcellars.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="J22QFapoIhtHNKfGfmdJF1aQCIOh1Lh0E" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, ietf@augustcellars.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, In Section 2.54,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2018 17:39:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --J22QFapoIhtHNKfGfmdJF1aQCIOh1Lh0E Content-Type: multipart/mixed; boundary="NsTV3WTShaid36M1L8VpEGCBVmRmVrt21"; protected-headers="v1" From: Henrik Levkowetz To: Jim Schaad , 'XML Developer List' Message-ID: Subject: Re: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, In Section 2.54,
    References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> <050c01d45d97$714e51b0$53eaf510$@augustcellars.com> In-Reply-To: <050c01d45d97$714e51b0$53eaf510$@augustcellars.com> --NsTV3WTShaid36M1L8VpEGCBVmRmVrt21 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-10-06 19:10, Jim Schaad wrote: >=20 >> -----Original Message----- >> From: xml2rfc-dev On Behalf Of Henrik >> Levkowetz >> Sent: Saturday, October 6, 2018 9:33 AM >> To: XML Developer List >> Subject: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, In = Section >> 2.54,
    >>=20 >> Bringing this issue to the list. The issue was raised by Miek: >> https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/31 >>=20 >> This issue starts out by stating one problem, namely that
    has = no >> provisions for having a caption. The discussion subsequently sorts th= is out, >> pointing to the use of the element for a table in order to prov= ide the >> caption. >>=20 >> In order to make this clearer, Section 2.54 probably should mention th= e usage >> of 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= =2E3.3, bullet 7 >> could also mention the use of to provide a caption. >>=20 >> The discussion subsequently mentions the discrepancy between table and= figure >> permitting , while doesn't. To clarify this, it might= be good >> to point out in Section 2.5. that there is no separate numbe= ring >> space for artwork; in order to caption and number a piece of artwork i= t has to >> be wrapped in a
    so that it can get a Figure number. >>=20 >> Finally the discussion moves on to the alignment of table captions. >>=20 >> There are 2 issues here: >>=20 >> - one schema issue, which is whether to permit left/center/right >> alignment of tables. It is permitted for artwork, and was permitte= d >> for texttable, but it not permitted for
    . >=20 > 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.) >> - 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 loo= k >> good. The next release of xml2rfc will center the caption under th= e >> table, before placing the combined table and caption. >=20 > 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. >=20 >>=20 >> To sum up: I think there are some improvements that could be made to = the >> document text, to clarify the use of to provide
    caption= s. There >> is one unresolved schema issue (align keyword for >>
    ) and one layout issue which will be fixed in the next xml2rfc = release. >=20 > +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 --NsTV3WTShaid36M1L8VpEGCBVmRmVrt21-- --J22QFapoIhtHNKfGfmdJF1aQCIOh1Lh0E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu480IACgkQTptXS4+7 FxrHMBAA1erqU9PV4gDBpTarTCkCu/FULJ4Y6RQDXsYzXRfag17hT2T4/wtD0vna Z+drX9+WUa3pxEGj/Z50gXqW784YswytS8X/O9Zq4iKcSQf1hgZWhMZEdIBPLxik NwqU8rw/j44C3mKyv983YvB9Vr/1pKitFFAcLquSQUyFHfEEVFTpQpdQnwzm7o2T ycI6qFB7sa4AB1dbTfWLkL+Q+8RSt1PBjD7d4T8DMz6qBxNUjiMV8NZ0sLDKV8aj evFQ4IsLRR+qxem0a3kH6MPzLRSuppzqPhvrN+RpyP8PBN/LjV/3e7SFMs1x25Ci 7MjI+COQ4+b0T191L+IZ0H7wAk5EymZCLPwW5BZvdxyS/27bixMH2QGOzrMOU62Y acF2Qa6U6sL7ThnEsLABDUsJ5w9Si3qJm53PjXohgJdaoNzDtkKXZ7wB8h+tmmNv 5XMqiSzPYohvFWo5nh/E114p4sXvCdm5Tw6FmM3miJa9CbM+dwm0N12fajdF0Vir L3xJ9TbYtNW/pYMqrY60cCpSyFzWb6b53LeTADVgyISkHnmV/wm9jt9a4+87meZU ntStUFgtNQ8hSomHGB9a8yfpEyKapre2xerytDBwDiwp3/MAs8KZkon220telFRO /ZDTzWIqeJbeKX4VvTVD7QICmLFqgHf94C2dr1+ooKCtgQfPYYc= =CIh5 -----END PGP SIGNATURE----- --J22QFapoIhtHNKfGfmdJF1aQCIOh1Lh0E-- From nobody Sat Oct 6 11:15:32 2018 Return-Path: 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 D6BC3130DEE for ; Sat, 6 Oct 2018 11:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 UjRjXec51-3Q for ; Sat, 6 Oct 2018 11:15:27 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D201128CE4 for ; Sat, 6 Oct 2018 11:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w96IFNmw007335; Sat, 6 Oct 2018 20:15:23 +0200 (CEST) Received: from client-0086.vpn.uni-bremen.de (client-0086.vpn.uni-bremen.de [134.102.107.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42SFCv00kszDWNg; Sat, 6 Oct 2018 20:15:22 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Sat, 6 Oct 2018 20:15:22 +0200 Cc: XML Developer List X-Mao-Original-Outgoing-Id: 560542520.518132-462edb73faa197708768eb088245b2a6 Content-Transfer-Encoding: quoted-printable Message-Id: <602D0951-0A16-4B51-BF69-96D5766BD2B0@tzi.org> References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> To: Henrik Levkowetz X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, In Section 2.54,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2018 18:15:30 -0000 On Oct 6, 2018, at 18:32, Henrik Levkowetz wrote: >=20 >
    > has no provisions for having a caption. The discussion subsequently > sorts this out, pointing to the use of the element for a table > in order to provide the caption. 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=E2=80=99t). Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Oct 6 12:27:12 2018 Return-Path: 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 87F30130E02 for ; Sat, 6 Oct 2018 12:27:10 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 EbLP5BWLAjmW for ; Sat, 6 Oct 2018 12:27:08 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0C37130DEE for ; Sat, 6 Oct 2018 12:27:07 -0700 (PDT) Received: from Jude (192.168.0.11) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 6 Oct 2018 12:22:14 -0700 From: Jim Schaad To: 'Henrik Levkowetz' , 'XML Developer List' References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> <050c01d45d97$714e51b0$53eaf510$@augustcellars.com> In-Reply-To: Date: Sat, 6 Oct 2018 12:26:47 -0700 Message-ID: <052b01d45daa$87e71980$97b54c80$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKlc/I8qUpx6H6sTpIQv3vHmEIb5gGMQXb8AverSrcCvXax5QHGvedgAOtPwScCpgcF3ADkS5KAAqj1aRQB/yc3qAHvHWwdAnFKOwwCPeYpeKKqSxbQ Content-Language: en-us X-Originating-IP: [192.168.0.11] Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, In Section 2.54,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2018 19:27:10 -0000 > -----Original Message----- > From: Henrik Levkowetz > Sent: Saturday, October 6, 2018 10:39 AM > To: Jim Schaad ; 'XML Developer List' = dev@ietf.org> > Subject: Re: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, = In > Section 2.54,
    >=20 > On 2018-10-06 19:10, Jim Schaad wrote: > > > >> -----Original Message----- > >> From: xml2rfc-dev On Behalf Of = Henrik > >> Levkowetz > >> Sent: Saturday, October 6, 2018 9:33 AM > >> To: XML Developer List > >> Subject: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, = In > >> Section 2.54,
    > >> > >> 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
    = has > >> no provisions for having a caption. The discussion subsequently > >> sorts this out, pointing to the use of the 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 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 > to provide a caption. > >> > >> The discussion subsequently mentions the discrepancy between table > >> and figure permitting , while doesn't. To clarify > >> this, it might be good to point out in Section 2.5. 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
    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
    . > > > > 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. >=20 > I fully agree. Not making it so is a mistake from my side. Will fix = in the next > release. >=20 > > The > > question then becomes what are the advantages/disadvantages of > > allowing for left and right aligned tables. >=20 > Right. (And also the issue of permitting it in the past, but not = now.) >=20 > >> - 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. > > > > 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. >=20 > Till now, both have been centered. That can be changed. >=20 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 > > > >> > >> To sum up: I think there are some improvements that could be made = to > >> the document text, to clarify the use of to provide
    > >> captions. There is one unresolved schema issue (align keyword for > >>
    ) 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. >=20 > Makes sense to me. >=20 > Henrik From nobody Sat Oct 6 14:53:39 2018 Return-Path: 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 0C0981277CC for ; Sat, 6 Oct 2018 14:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 KDu1Ey5n957c for ; Sat, 6 Oct 2018 14:53:37 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F2D61277BB for ; Sat, 6 Oct 2018 14:53:37 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:51644 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g8uW0-0006Wy-Mw; Sat, 06 Oct 2018 14:53:37 -0700 To: Jim Schaad , 'XML Developer List' References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> <050c01d45d97$714e51b0$53eaf510$@augustcellars.com> <052b01d45daa$87e71980$97b54c80$@augustcellars.com> From: Henrik Levkowetz Message-ID: <656afb2e-3aa7-53c5-5e39-55050387aa20@levkowetz.com> Date: Sat, 6 Oct 2018 23:53:29 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <052b01d45daa$87e71980$97b54c80$@augustcellars.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pB3LihjFN106WeMLCgDjVXi01kuKJOQ3C" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, ietf@augustcellars.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, In Section 2.54,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2018 21:53:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pB3LihjFN106WeMLCgDjVXi01kuKJOQ3C Content-Type: multipart/mixed; boundary="TRxd4DurQh6XH2bGnDAn7RJJ2WO85EqRm"; protected-headers="v1" From: Henrik Levkowetz To: Jim Schaad , 'XML Developer List' Message-ID: <656afb2e-3aa7-53c5-5e39-55050387aa20@levkowetz.com> Subject: Re: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, In Section 2.54,
    References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> <050c01d45d97$714e51b0$53eaf510$@augustcellars.com> <052b01d45daa$87e71980$97b54c80$@augustcellars.com> In-Reply-To: <052b01d45daa$87e71980$97b54c80$@augustcellars.com> --TRxd4DurQh6XH2bGnDAn7RJJ2WO85EqRm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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. >> Till now, both have been centered. That can be changed. >>=20 > 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 --TRxd4DurQh6XH2bGnDAn7RJJ2WO85EqRm-- --pB3LihjFN106WeMLCgDjVXi01kuKJOQ3C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu5LtkACgkQTptXS4+7 Fxr1uA/8CGnLWhcYv3IbGcL+w5NfdZ4SwkDF5gsmPp9HBCgr/uZNaWZ9D/iSooc5 7jEVGc9K/3dwBsekaSv78XYljgXdhYxe++EOnbzlwOoM8DR+RV1biwbNpf2vXcYx W0gNTog9RHNpZJ8UK1KhRANT0eircQ2Qy21yh1qFg2FQ3a5VgNT3Ok/aeJvo8BHK tnjBTib8VOv51VFFOb3pm4RAa7aUzQ357e87qNbrtVSMrUoPaq6bcfJZI0HlGqZB dPNHrXy9FpsdJIbcK6iyOz313QbWEwJZj2K0Ama9PN4/CQSEYRFGNAg50EoYmX6J m3r9UNG0ka2XBLQIhG662cI2Kc+l+CHqAkPjApgcbL+1c+ef5bkRpIMrlkeOP6o+ nioYunegFpGfifTY18ucJNQtFTndZ9y/kyrT0cpBR8EYZynttdLXoW/tnuI1vIr/ qDYwXc21budzLgMp02WPh6haTnOka/ehH81/aj1SVv/3NBVBOZMWZ47Pd/h/02L0 D5PBRs5/DGUXMkTPb4VLv9hv8kRhApLawinT6F4bLRbg20Ftk7c0t7I4pJTe2F+1 K4m2m07WOBRnpujWlG5TquLrm5jBnKYOEuCj7Z+KCcbJVJ6Uo+1bB1l0SCMCl8Ne pwRL+izVnSA6FtJ7spkptD08XBUT8fTyT6wGS0M5vwGz1y9IpkU= =4i0X -----END PGP SIGNATURE----- --pB3LihjFN106WeMLCgDjVXi01kuKJOQ3C-- From nobody Sun Oct 7 07:14:29 2018 Return-Path: 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 03460130DF0 for ; Sun, 7 Oct 2018 07:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 yn5d_oubKxzV for ; Sun, 7 Oct 2018 07:14:26 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BD57130DE1 for ; Sun, 7 Oct 2018 07:14:26 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:57040 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g99pA-0005Uz-Qd for xml2rfc-dev@ietf.org; Sun, 07 Oct 2018 07:14:25 -0700 To: xml2rfc-dev@ietf.org References: From: Henrik Levkowetz Message-ID: Date: Sun, 7 Oct 2018 16:14:07 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kQUH68tnw5STX3PSjt05G58JMoeQAh956" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, New Section 2.20.4, "indent" Attribute 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2018 14:14:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kQUH68tnw5STX3PSjt05G58JMoeQAh956 Content-Type: multipart/mixed; boundary="ga7CBWi5PUBNCk02Na1DEdKsHgxhesmU9"; protected-headers="v1" From: Henrik Levkowetz To: xml2rfc-dev@ietf.org Message-ID: Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, New Section 2.20.4, "indent" Attribute References: In-Reply-To: --ga7CBWi5PUBNCk02Na1DEdKsHgxhesmU9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I propose closing this ticket with the following resolution: Add an attribute "indent" to
    , signifying the character indentation in monospace rendering, and the indentation measured in en-space [1] unit= s in other renderings. If there are no objections to the resolution by EOB Monday, I'll close th= e ticket. =20 With respect to document text, I propose the following new text under Section 2.20.
    : --- 2.20.4. "indent" Attribute Indicates the indentation to be used for the second and following lines of item rendering (the first line starts with the term, and is not indented). The indentation is to be interpreted as characters for monospace renderings, and en-space units when using proportional fonts. One en-space is assumed to be the length of 0.5 em-space in CSS units. --- [1] https://en.wikipedia.org/wiki/En_(typography) Best regards, Henrik On 2018-10-01 14:39, Henrik Levkowetz wrote: > Hi Julian, >=20 > On 2018-10-01 14:09, Julian Reschke wrote: >> On 10/1/2018 1:36 PM, henrik@levkowetz.com wrote: >>> This captures an issue noted during implementation, also described in= >>> https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation= #section-3.1.4 >>>=20 >>> --- >>> New Section 2.20.4, "indent" Attribute >>>=20 >>> The deprecation of the "hangIndent" attribute on leaves no= >>> opportunity to control the size of the hanging indent. In some >>> definition lists, it is desirable to have a wide indentation, in = order >>> to clearly show the terms, in other cases it is more important to= allow >>> for a larger text volume than the width of the terms would allow.= >>>=20 >>> Recommendation: Add an "indent" attribute on
    to control the= size >>> of the hanging indent. >>>=20 >>> Implementation: The current version of xml2rfc does not support = the >>> attribute, but has all the underlying functions = needed >>> to apply such an attribute. Internally, an inde= ntation >>> is calculated based on length of the
    text a= nd the >>> settings of some of the other attributes. >>> --- >>> ... >>=20 >> I agree that this would be useful - however we'll need to define it in= a=20 >> way that works well with non-monospaced fonts. >=20 > Agreed. >=20 > What about specifying indentation as a number that would indicate chara= cters > in monospaced output, and en-space otherwise? --ga7CBWi5PUBNCk02Na1DEdKsHgxhesmU9-- --kQUH68tnw5STX3PSjt05G58JMoeQAh956 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu6FLcACgkQTptXS4+7 FxqYuhAAstLCNW1dZaDEcKkOfY8X/8HfGrWGA25Q7nyBpRnALF4bOlw/DzvHJrrt XD8DjT0C9R68Wc6JzFt5emhucehel/+mLd5a0NL9CtJc6jjdMA2b+MR+jZXx1/om 3zzUA41JbYN6OxtHBtr4Pbx75xo6iFK3WeQiggJfMMOVsKsFhwMMQjuR2TuNTbNx HpPQd6Z6X1tmZ7p2KV4cJmEdSF8CFgLdLjxAJpZXK8HQV5L9BoGDMCvieldzYIEz My0R+EHHG3qgPVnH6ToM21u1ID5MBazsdVlZHHeHPjjMMahF4H8TF0XKlG89gkrL euCONlbW1lUBkTAlVSghG0xIVQg+pSTwtdcmpsD9vg6CISfg08rZNNEDU4LvY8bu Ep/EgCnp9Z7PMNN2/11l8rcv/QSGGc1MqkcHVZ7dEGlT34IMr4Vw/aBhlHkC5WRL QkTWOudRTet7p3MKY3Zit606dYUylKlGOfxmBf0HmxvtGAtBGqoWX8OmpIa5g0bg fqk8PbWL4EejBMkI7x0OBvrYjn0yaGEqT0uasKpM9/I6Csm/AE5iHKHHeQ0B5qVO zr7vPjc7ABDRN3vRflyuSA0qpLXNqpPXZOmoLc0/GVnZuO0xqK/UqiEsfnLzkkPQ ybWPujJtaTP7xUamFGXZi1OIc5c6IKdK0S1sNoqsewO09lCQa+k= =kz/0 -----END PGP SIGNATURE----- --kQUH68tnw5STX3PSjt05G58JMoeQAh956-- From nobody Sun Oct 7 08:10:54 2018 Return-Path: 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 7C895130E2F for ; Sun, 7 Oct 2018 08:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 7eVoBF_wbfzF for ; Sun, 7 Oct 2018 08:10:50 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 512F1130E30 for ; Sun, 7 Oct 2018 08:10:50 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 7 Oct 2018 08:06:05 -0700 From: Jim Schaad To: 'Henrik Levkowetz' , References: In-Reply-To: Date: Sun, 7 Oct 2018 08:10:40 -0700 Message-ID: <055101d45e4f$eab33f30$c019bd90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQE/60/iC0oW5uFeRsGOaCY9EO+4sAJMfbGjAKtuqJsCbqsHJaYRk6vA Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, New Section 2.20.4, "indent" Attribute 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2018 15:10:52 -0000 > -----Original Message----- > From: xml2rfc-dev On Behalf Of Henrik > Levkowetz > Sent: Sunday, October 7, 2018 7:14 AM > To: xml2rfc-dev@ietf.org > Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, = New > Section 2.20.4, "indent" Attribute >=20 > I propose closing this ticket with the following resolution: >=20 > Add an attribute "indent" to
    , signifying the character = indentation in > monospace rendering, and the indentation measured in en-space [1] = units in > other renderings. >=20 > If there are no objections to the resolution by EOB Monday, I'll close = the ticket. >=20 > With respect to document text, I propose the following new text under = Section > 2.20.
    : >=20 > --- > 2.20.4. "indent" Attribute >=20 > Indicates the indentation to be used for the second and following > lines of item rendering (the first line starts with the term, and > is not indented). The indentation is to be interpreted as = characters > for monospace renderings, and en-space units when using = proportional > fonts. One en-space is assumed to be the length of 0.5 em-space in > CSS units. I think it would be fine just to use em rather than en. Also I don't = think that the text needs to be written as different between monospace = and proportional fonts. The width of an em is going to be font specific = and is equal to a character width for monospace. If you don't do the = 0.5 but just use em to start with then everything is consistant. Jim >=20 > --- >=20 > [1] https://en.wikipedia.org/wiki/En_(typography) >=20 >=20 > Best regards, >=20 > Henrik >=20 >=20 > On 2018-10-01 14:39, Henrik Levkowetz wrote: > > Hi Julian, > > > > On 2018-10-01 14:09, Julian Reschke wrote: > >> On 10/1/2018 1:36 PM, henrik@levkowetz.com wrote: > >>> This captures an issue noted during implementation, also described > >>> in > >>> = https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementatio > >>> n#section-3.1.4 > >>> > >>> --- > >>> New Section 2.20.4, "indent" Attribute > >>> > >>> The deprecation of the "hangIndent" attribute on leaves = no > >>> opportunity to control the size of the hanging indent. In = some > >>> definition lists, it is desirable to have a wide indentation, = in order > >>> to clearly show the terms, in other cases it is more important = to allow > >>> for a larger text volume than the width of the terms would = allow. > >>> > >>> Recommendation: Add an "indent" attribute on
    to control = the size > >>> of the hanging indent. > >>> > >>> Implementation: The current version of xml2rfc does not = support the > >>> attribute, but has all the underlying = functions needed > >>> to apply such an attribute. Internally, an = indentation > >>> is calculated based on length of the
    = text and the > >>> settings of some of the other attributes. > >>> --- > >>> ... > >> > >> I agree that this would be useful - however we'll need to define it > >> in a way that works well with non-monospaced fonts. > > > > Agreed. > > > > What about specifying indentation as a number that would indicate > > characters in monospaced output, and en-space otherwise? >=20 From nobody Sun Oct 7 08:18:22 2018 Return-Path: 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 952FD130E2A for ; Sun, 7 Oct 2018 08:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 J8-g_cllZhWj for ; Sun, 7 Oct 2018 08:18:19 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33103124BE5 for ; Sun, 7 Oct 2018 08:18:19 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:57281 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g9Aow-0000Cq-Ec; Sun, 07 Oct 2018 08:18:18 -0700 To: Jim Schaad , xml2rfc-dev@ietf.org References: <055101d45e4f$eab33f30$c019bd90$@augustcellars.com> From: Henrik Levkowetz Message-ID: Date: Sun, 7 Oct 2018 17:18:06 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <055101d45e4f$eab33f30$c019bd90$@augustcellars.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jermrOx7SwNLkcMsDFRmexC6KxTv8rWhd" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, ietf@augustcellars.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, New Section 2.20.4, "indent" Attribute 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2018 15:18:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jermrOx7SwNLkcMsDFRmexC6KxTv8rWhd Content-Type: multipart/mixed; boundary="X3p6wgaEpjXosE0HDrDJDjMOiUPXxlvcB"; protected-headers="v1" From: Henrik Levkowetz To: Jim Schaad , xml2rfc-dev@ietf.org Message-ID: Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, New Section 2.20.4, "indent" Attribute References: <055101d45e4f$eab33f30$c019bd90$@augustcellars.com> In-Reply-To: <055101d45e4f$eab33f30$c019bd90$@augustcellars.com> --X3p6wgaEpjXosE0HDrDJDjMOiUPXxlvcB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jim, On 2018-10-07 17:10, Jim Schaad wrote: >=20 >=20 >> -----Original Message----- >> From: xml2rfc-dev On Behalf Of Henrik >> Levkowetz >> Sent: Sunday, October 7, 2018 7:14 AM >> To: xml2rfc-dev@ietf.org >> Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991,= New >> Section 2.20.4, "indent" Attribute >>=20 >> I propose closing this ticket with the following resolution: >>=20 >> Add an attribute "indent" to
    , signifying the character indentatio= n in >> monospace rendering, and the indentation measured in en-space [1] unit= s in >> other renderings. >>=20 >> If there are no objections to the resolution by EOB Monday, I'll close= the ticket. >>=20 >> With respect to document text, I propose the following new text under = Section >> 2.20.
    : >>=20 >> --- >> 2.20.4. "indent" Attribute >>=20 >> Indicates the indentation to be used for the second and following >> lines of item rendering (the first line starts with the term, and >> is not indented). The indentation is to be interpreted as characte= rs >> for monospace renderings, and en-space units when using proportiona= l >> fonts. One en-space is assumed to be the length of 0.5 em-space in= >> CSS units. >=20 > I think it would be fine just to use em rather than en. Also I don't > think that the text needs to be written as different between > monospace and proportional fonts. The width of an em is going to be > font specific and is equal to a character width for monospace. If you > don't do the 0.5 but just use em to start with then everything is > consistant. The reason I expressed this in en-space is that as a rule of thumb, the average character width in a proportional font is 1 en. If we apply the indent figure as number of em-spaces, the visual impression will be a much larger indentation when using proportional fonts than for monospaced= fonts. Best regards, Henrik >=20 > Jim >=20 >>=20 >> --- >>=20 >> [1] https://en.wikipedia.org/wiki/En_(typography) >>=20 >>=20 >> Best regards, >>=20 >> Henrik >>=20 >>=20 >> On 2018-10-01 14:39, Henrik Levkowetz wrote: >> > Hi Julian, >> > >> > On 2018-10-01 14:09, Julian Reschke wrote: >> >> On 10/1/2018 1:36 PM, henrik@levkowetz.com wrote: >> >>> This captures an issue noted during implementation, also described= >> >>> in >> >>> https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementat= io >> >>> n#section-3.1.4 >> >>> >> >>> --- >> >>> New Section 2.20.4, "indent" Attribute >> >>> >> >>> The deprecation of the "hangIndent" attribute on leaves= no >> >>> opportunity to control the size of the hanging indent. In som= e >> >>> definition lists, it is desirable to have a wide indentation, = in order >> >>> to clearly show the terms, in other cases it is more important= to allow >> >>> for a larger text volume than the width of the terms would all= ow. >> >>> >> >>> Recommendation: Add an "indent" attribute on
    to control = the size >> >>> of the hanging indent. >> >>> >> >>> Implementation: The current version of xml2rfc does not suppo= rt the >> >>> attribute, but has all the underlying functio= ns needed >> >>> to apply such an attribute. Internally, an i= ndentation >> >>> is calculated based on length of the
    tex= t and the >> >>> settings of some of the other attributes. >> >>> --- >> >>> ... >> >> >> >> I agree that this would be useful - however we'll need to define it= >> >> in a way that works well with non-monospaced fonts. >> > >> > Agreed. >> > >> > What about specifying indentation as a number that would indicate >> > characters in monospaced output, and en-space otherwise? >>=20 >=20 >=20 >=20 --X3p6wgaEpjXosE0HDrDJDjMOiUPXxlvcB-- --jermrOx7SwNLkcMsDFRmexC6KxTv8rWhd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu6I64ACgkQTptXS4+7 FxqG8g//dobxxQ3biaDlF2Fyw6jasix2/FD1dBy1h7x2JApb/ICnu+zd7rSqFOJS UU5lxxvkdZGxSK/oKMiP3vcxc9+yRrwEBfI9t1mYLRudb0eHVTUl3OsWGpjebt46 EwF+Gq0j1Uwg2ztB+L3D2oZNOxmHB4k8N7cACppllCM43AeHN1IdjbhR5DJbqkCV n51/z7WXKfmtIwP7YBDbpStLmL9fRJoOsLaPPm0TINODcgCwNoFm354pwxQwQEof 6LAfGWQMukE/Sf0+VELnaQQ7Sdz3hryZtxP5ctJZUb7c7oXcPpA/NqFnmMUjHu7T VImfSLw8NB1I9c2CHMYpQTHRDIb3e5qRX1IxYQa1wR21PZ/zPkFBakhsx2/tbDt4 wcJppqg4btcIvcDxwn/GSEiuXHkVUawsPfLWcgCTxjXAxbTtlqbFSBdU4Nn9yMlV KyupkHsrf7QjWadGwCZn0wg4Betc3T+ed9HrW3aYAOOdqwM8jH2eQHb2ukX0ZXXV euNVwU/O0Go89g/FIyeR7H/GbjqBFrKkCx4VutdmAK/4Uk/OlnGREPzxAJXVStxm mN2bZWGHcfOvxBNdlcuxxYcjU97Qc70EVFnuXfnn5q+J7CAGBWmm1+9imCC1hRId NXHA2oiSi7U0tE/yGrBY1/ZqNuhKJsUkngSaaoPNHfjZFN+32lQ= =Fhzj -----END PGP SIGNATURE----- --jermrOx7SwNLkcMsDFRmexC6KxTv8rWhd-- From nobody Sun Oct 7 12:54:36 2018 Return-Path: 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 3E7D0127333; Sun, 7 Oct 2018 12:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 O3Q3fB5Iorly; Sun, 7 Oct 2018 12:54:27 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13DD4130DE9; Sun, 7 Oct 2018 12:54:27 -0700 (PDT) Received: from henrik by durif.tools.ietf.org with local (Exim 4.80) (envelope-from ) id 1g9F8E-0007Af-JK; Sun, 07 Oct 2018 12:54:26 -0700 To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org Cc: rfc-markdown@ietf.org Message-Id: From: Henrik Levkowetz Date: Sun, 07 Oct 2018 12:54:26 -0700 X-SA-Exim-Connect-IP: X-SA-Exim-Rcpt-To: rfc-markdown@ietf.org, xml2rfc-dev@ietf.org, xml2rfc@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc-dev] New xml2rfc release: v2.11.0 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2018 19:54:30 -0000 Hi, This is an automatic notification about a new xml2rfc release, v2.11.0, generated when running the mkrelease script. Release notes: xml2rfc (2.11.0) ietf; urgency=medium This release is a result of the issue discussions on xml2rfc-dev, and attempt to follow the discussion and projected resolution of issues #36-#40. This results in a number of incompatibilities with previous releases, with respect to the v3 tools, as expected. The v2 tools are unaffected. Details: * Changed the default table alignment to 'center', in order to match v2. * Changed the
    'hanging' attribute name to 'newline', based on the discussion of issue #38, in the schema, v2v3 converter and text formatter. * Added an attribute 'indent' to
    in the schema, according to the discussion of issue #39. Added v2v3 and text support for the same. * Added markers='true' in the v2v3 converter for sourcecode with markers, and tweaked render_sourcecode() to honour the 'markers' setting. * Removed the disallowed align attribute on sourcecode. * Removed
    from the schema, according to the resolution of issue #37. * Tweaked the handling of the document title to only reflow if needed, with some refactoring. * Corrected the handling of the align attribute on and
    . * Changed to hold an RFC 3339 timestamp with seconds resolution. * Fixed a couple of issues with v2v3 conversion warnings, and added source line information for all elements created during conversion. * Fixed a buglet in sourcode rendering. * Added a warning about lxml versions that lack validation error xpath information, and tweaked the warn() method. -- Henrik Levkowetz 06 Oct 2018 19:23:40 +0000 The preferred way to install xml2rfc is by doing 'pip install xml2rfc', and 'pip install --upgrade xml2rfc' to upgrade. If there are system- installed python modules which pip will not upgrade, you may have to use 'pip install --upgrade --no-deps xml2rfc' and install dependencies manually. The new version is also available through SVN checkout, with 'svn checkout http://svn.tools.ietf.org/svn/tools/xml2rfc/tags/cli/2.11.0' Regards, Henrik (via the mkrelease script) From nobody Sun Oct 7 13:16:08 2018 Return-Path: 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 62284130E05 for ; Sun, 7 Oct 2018 13:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 8PZhDV0IcnUz for ; Sun, 7 Oct 2018 13:16:05 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A651130DEE for ; Sun, 7 Oct 2018 13:16:05 -0700 (PDT) Received: from Jude (192.168.0.11) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 7 Oct 2018 13:11:21 -0700 From: Jim Schaad To: 'Henrik Levkowetz' , References: <055101d45e4f$eab33f30$c019bd90$@augustcellars.com> In-Reply-To: Date: Sun, 7 Oct 2018 13:15:55 -0700 Message-ID: <057801d45e7a$8f7c5c20$ae751460$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQE/60/iC0oW5uFeRsGOaCY9EO+4sAJMfbGjAKtuqJsCbqsHJQHSk4ieASEJhGSl+kwdsA== Content-Language: en-us X-Originating-IP: [192.168.0.11] Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, New Section 2.20.4, "indent" Attribute 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2018 20:16:08 -0000 > -----Original Message----- > From: Henrik Levkowetz > Sent: Sunday, October 7, 2018 8:18 AM > To: Jim Schaad ; xml2rfc-dev@ietf.org > Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, = New > Section 2.20.4, "indent" Attribute >=20 > Hi Jim, >=20 > On 2018-10-07 17:10, Jim Schaad wrote: > > > > > >> -----Original Message----- > >> From: xml2rfc-dev On Behalf Of = Henrik > >> Levkowetz > >> Sent: Sunday, October 7, 2018 7:14 AM > >> To: xml2rfc-dev@ietf.org > >> Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC > >> 7991, New Section 2.20.4, "indent" Attribute > >> > >> I propose closing this ticket with the following resolution: > >> > >> Add an attribute "indent" to
    , signifying the character > >> indentation in monospace rendering, and the indentation measured in > >> en-space [1] units in other renderings. > >> > >> If there are no objections to the resolution by EOB Monday, I'll = close the > ticket. > >> > >> With respect to document text, I propose the following new text = under > >> Section 2.20.
    : > >> > >> --- > >> 2.20.4. "indent" Attribute > >> > >> Indicates the indentation to be used for the second and = following > >> lines of item rendering (the first line starts with the term, = and > >> is not indented). The indentation is to be interpreted as = characters > >> for monospace renderings, and en-space units when using = proportional > >> fonts. One en-space is assumed to be the length of 0.5 em-space = in > >> CSS units. > > > > I think it would be fine just to use em rather than en. Also I don't > > think that the text needs to be written as different between = monospace > > and proportional fonts. The width of an em is going to be font > > specific and is equal to a character width for monospace. If you = don't > > do the 0.5 but just use em to start with then everything is > > consistant. >=20 > The reason I expressed this in en-space is that as a rule of thumb, = the average > character width in a proportional font is 1 en. If we apply the = indent figure as > number of em-spaces, the visual impression will be a much larger = indentation > when using proportional fonts than for monospaced fonts. My worry is that this means that trying to get the value right in css is = going to based on if the current paragraph is using a mono-space font (n = * em) or a proportional font ( n / 2 * em). For some places a = mono-space font is going to be more readable and you are now getting = different displays. I understand what you are saying, I am just not too sure if it is going = to be the correct answer in all cases. Jim >=20 >=20 > Best regards, >=20 > Henrik >=20 >=20 > > > > Jim > > > >> > >> --- > >> > >> [1] https://en.wikipedia.org/wiki/En_(typography) > >> > >> > >> Best regards, > >> > >> Henrik > >> > >> > >> On 2018-10-01 14:39, Henrik Levkowetz wrote: > >> > Hi Julian, > >> > > >> > On 2018-10-01 14:09, Julian Reschke wrote: > >> >> On 10/1/2018 1:36 PM, henrik@levkowetz.com wrote: > >> >>> This captures an issue noted during implementation, also > >> >>> described in > >> >>> = https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementa > >> >>> tio > >> >>> n#section-3.1.4 > >> >>> > >> >>> --- > >> >>> New Section 2.20.4, "indent" Attribute > >> >>> > >> >>> The deprecation of the "hangIndent" attribute on = leaves no > >> >>> opportunity to control the size of the hanging indent. In = some > >> >>> definition lists, it is desirable to have a wide = indentation, in order > >> >>> to clearly show the terms, in other cases it is more = important to allow > >> >>> for a larger text volume than the width of the terms would = allow. > >> >>> > >> >>> Recommendation: Add an "indent" attribute on
    to = control the > size > >> >>> of the hanging indent. > >> >>> > >> >>> Implementation: The current version of xml2rfc does not = support the > >> >>> attribute, but has all the underlying = functions needed > >> >>> to apply such an attribute. Internally, = an indentation > >> >>> is calculated based on length of the
    = text and the > >> >>> settings of some of the other attributes. > >> >>> --- > >> >>> ... > >> >> > >> >> I agree that this would be useful - however we'll need to define > >> >> it in a way that works well with non-monospaced fonts. > >> > > >> > Agreed. > >> > > >> > What about specifying indentation as a number that would indicate > >> > characters in monospaced output, and en-space otherwise? > >> > > > > > > From nobody Sun Oct 7 13:20:32 2018 Return-Path: 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 6D38E1292AD for ; Sun, 7 Oct 2018 13:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 V0LygXQlWRlH for ; Sun, 7 Oct 2018 13:20:29 -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 B7E13124D68 for ; Sun, 7 Oct 2018 13:20:29 -0700 (PDT) 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 Microsoft SMTP Server (TLS) id 15.0.1367.3; Sun, 7 Oct 2018 13:20:26 -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; Sun, 7 Oct 2018 13:20:26 -0700 From: Paul Hoffman To: Henrik Levkowetz CC: XML Developer List Thread-Topic: [Ext] [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, New Section 2.20.4, "indent" Attribute Thread-Index: AQHUXnsuD//yaBAStUWXTDZMD0CuoQ== Date: Sun, 7 Oct 2018 20:20:26 +0000 Message-ID: <735A937F-1464-464C-908F-2A107D981364@icann.org> References: <055101d45e4f$eab33f30$c019bd90$@augustcellars.com> In-Reply-To: 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=_FFCCFE11-E34F-4E0E-8A9D-F2F4599BD8A0"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #39: Schema Issue, RFC 7991, New Section 2.20.4, "indent" Attribute 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2018 20:20:32 -0000 --Apple-Mail=_FFCCFE11-E34F-4E0E-8A9D-F2F4599BD8A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 7, 2018, at 8:18 AM, Henrik Levkowetz = wrote: > The reason I expressed this in en-space is that as a rule of thumb, = the > average character width in a proportional font is 1 en. If we apply = the > indent figure as number of em-spaces, the visual impression will be a > much larger indentation when using proportional fonts than for = monospaced > fonts. This makes sense, but the reason I proposed using the em unit earlier is = that em is defined in CSS, but (I'm pretty sure) en is not. This would = make the HTML much easier to render directly, I think. --Paul Hoffman= --Apple-Mail=_FFCCFE11-E34F-4E0E-8A9D-F2F4599BD8A0 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAwNzIwMjAyNlowIwYJKoZIhvcNAQkEMRYEFAaixQ6dNYmZcxmFgBzTQGCDIZ9yMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQBvYG9jFfaigbxdAC1MOkRzASuQfR0S4hXwwk4z03SrHfRuo/yitVtYGvtLo2Fcds0xk71h FkCW8FYW0wdg+U25qE+95jEs+fp9oB+u+DTAjpNsP3uhFz9nLINVC+aGO43kyFyzGgaULKRBT2nI v+n4MBc0ZPJz43cOG4owV8+zmAIad02McMpmY2303EdCEHN/XjzzfeZq7x1szRvHLY1LCOn4eH4r JX92V/dRIk/6bp6GM6m3dhI9RcXVJfRSKmKB6rvilgsvTpzRa072uooRWkpjR5HZgm04Q1F8al6G pL1h6LprJYlvBh+gIuYYUl79sa6JgoTlv2ZVSU1df4B+AAAAAAAA --Apple-Mail=_FFCCFE11-E34F-4E0E-8A9D-F2F4599BD8A0-- From nobody Sun Oct 7 13:26:36 2018 Return-Path: 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 99F4F1292AD for ; Sun, 7 Oct 2018 13:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 DSNmiPsGc6GA for ; Sun, 7 Oct 2018 13:26:32 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36B5B124D68 for ; Sun, 7 Oct 2018 13:26:32 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:58381 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g9FdH-0006oy-6m; Sun, 07 Oct 2018 13:26:32 -0700 To: Jim Schaad , xml2rfc-dev@ietf.org References: <055101d45e4f$eab33f30$c019bd90$@augustcellars.com> <057801d45e7a$8f7c5c20$ae751460$@augustcellars.com> From: Henrik Levkowetz Message-ID: Date: Sun, 7 Oct 2018 22:26:23 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <057801d45e7a$8f7c5c20$ae751460$@augustcellars.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SJfqj9cuu6Df7VUKQ2l239j2xcWOoFVIi" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, ietf@augustcellars.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, New Section 2.20.4, "indent" Attribute 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2018 20:26:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SJfqj9cuu6Df7VUKQ2l239j2xcWOoFVIi Content-Type: multipart/mixed; boundary="8vCd6Ji2E2fRgh4xkNm5T9MRaFtrpRnnm"; protected-headers="v1" From: Henrik Levkowetz To: Jim Schaad , xml2rfc-dev@ietf.org Message-ID: Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, New Section 2.20.4, "indent" Attribute References: <055101d45e4f$eab33f30$c019bd90$@augustcellars.com> <057801d45e7a$8f7c5c20$ae751460$@augustcellars.com> In-Reply-To: <057801d45e7a$8f7c5c20$ae751460$@augustcellars.com> --8vCd6Ji2E2fRgh4xkNm5T9MRaFtrpRnnm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable n 2018-10-07 22:15, Jim Schaad wrote: >=20 >> -----Original Message----- >> From: Henrik Levkowetz >> Sent: Sunday, October 7, 2018 8:18 AM >> To: Jim Schaad ; xml2rfc-dev@ietf.org >> Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991,= New >> Section 2.20.4, "indent" Attribute >>=20 >> Hi Jim, >>=20 >> On 2018-10-07 17:10, Jim Schaad wrote: >> > >> > >> >> -----Original Message----- >> >> From: xml2rfc-dev On Behalf Of Henri= k >> >> Levkowetz >> >> Sent: Sunday, October 7, 2018 7:14 AM >> >> To: xml2rfc-dev@ietf.org >> >> Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC >> >> 7991, New Section 2.20.4, "indent" Attribute >> >> >> >> I propose closing this ticket with the following resolution: >> >> >> >> Add an attribute "indent" to
    , signifying the character >> >> indentation in monospace rendering, and the indentation measured in= >> >> en-space [1] units in other renderings. >> >> >> >> If there are no objections to the resolution by EOB Monday, I'll cl= ose the >> ticket. >> >> >> >> With respect to document text, I propose the following new text und= er >> >> Section 2.20.
    : >> >> >> >> --- >> >> 2.20.4. "indent" Attribute >> >> >> >> Indicates the indentation to be used for the second and followin= g >> >> lines of item rendering (the first line starts with the term, an= d >> >> is not indented). The indentation is to be interpreted as chara= cters >> >> for monospace renderings, and en-space units when using proporti= onal >> >> fonts. One en-space is assumed to be the length of 0.5 em-space= in >> >> CSS units. >> > >> > I think it would be fine just to use em rather than en. Also I don't= >> > think that the text needs to be written as different between monospa= ce >> > and proportional fonts. The width of an em is going to be font >> > specific and is equal to a character width for monospace. If you don= 't >> > do the 0.5 but just use em to start with then everything is >> > consistant. >>=20 >> The reason I expressed this in en-space is that as a rule of thumb, th= e average >> character width in a proportional font is 1 en. If we apply the inden= t figure as >> number of em-spaces, the visual impression will be a much larger inden= tation >> when using proportional fonts than for monospaced fonts. >=20 > My worry is that this means that trying to get the value right in css > is going to based on if the current paragraph is using a mono-space > font (n * em) or a proportional font ( n / 2 * em). For some places a > mono-space font is going to be more readable and you are now getting > different displays. Ah. Ok, got you. What about this, then: --- 2.20.4. "indent" Attribute Indicates the indentation to be used for the second and following lines of item rendering (the first line starts with the term, and is not indented). The indentation is to be interpreted as characters in text/plain rendering, and en-space units when using renderings with richer typographic support, such as html or pdf. One en-space is= assumed to be the length of 0.5 em-space in CSS units. --- >=20 > I understand what you are saying, I am just not too sure if it is > going to be the correct answer in all cases. Ack. Henrik > Jim >=20 >>=20 >>=20 >> Best regards, >>=20 >> Henrik >>=20 >>=20 >> > >> > Jim >> > >> >> >> >> --- >> >> >> >> [1] https://en.wikipedia.org/wiki/En_(typography) >> >> >> >> >> >> Best regards, >> >> >> >> Henrik >> >> >> >> >> >> On 2018-10-01 14:39, Henrik Levkowetz wrote: >> >> > Hi Julian, >> >> > >> >> > On 2018-10-01 14:09, Julian Reschke wrote: >> >> >> On 10/1/2018 1:36 PM, henrik@levkowetz.com wrote: >> >> >>> This captures an issue noted during implementation, also >> >> >>> described in >> >> >>> https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implemen= ta >> >> >>> tio >> >> >>> n#section-3.1.4 >> >> >>> >> >> >>> --- >> >> >>> New Section 2.20.4, "indent" Attribute >> >> >>> >> >> >>> The deprecation of the "hangIndent" attribute on lea= ves no >> >> >>> opportunity to control the size of the hanging indent. In = some >> >> >>> definition lists, it is desirable to have a wide indentatio= n, in order >> >> >>> to clearly show the terms, in other cases it is more import= ant to allow >> >> >>> for a larger text volume than the width of the terms would = allow. >> >> >>> >> >> >>> Recommendation: Add an "indent" attribute on
    to contr= ol the >> size >> >> >>> of the hanging indent. >> >> >>> >> >> >>> Implementation: The current version of xml2rfc does not su= pport the >> >> >>> attribute, but has all the underlying func= tions needed >> >> >>> to apply such an attribute. Internally, a= n indentation >> >> >>> is calculated based on length of the
    = text and the >> >> >>> settings of some of the other attributes. >> >> >>> --- >> >> >>> ... >> >> >> >> >> >> I agree that this would be useful - however we'll need to define= >> >> >> it in a way that works well with non-monospaced fonts. >> >> > >> >> > Agreed. >> >> > >> >> > What about specifying indentation as a number that would indicate= >> >> > characters in monospaced output, and en-space otherwise? >> >> >> > >> > >> > >=20 >=20 >=20 --8vCd6Ji2E2fRgh4xkNm5T9MRaFtrpRnnm-- --SJfqj9cuu6Df7VUKQ2l239j2xcWOoFVIi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu6a+8ACgkQTptXS4+7 FxqUow//cJY6eGeA05xfbtg+wg9R2LJOC+gzyXBj8aEMrfC2cxGr9HtsCchqxK+n UCCqM43d5d8mMWYcjtoTro5HqYfEnXg7ZQs2uDckXWSJWckj5c9Vfc18cCh2gZWy Oiv/6VSrzp6IOkvMYGBl0Z/T6GUkaVJwn6gJOK5U3M130HRQ7HLH5G3iHQUiJagg gSLcoOMDS3svGzEscZ3FYysQbdmR2MQ2fYJPI1sH3Gjn8qqwpHZJ7Y2XyJUCz1u/ dizt5mabwpAjw430l2Jj9Y8uMstHOHfOV0ESd9DkZpOqOXkLSerEr2o76+tYQ7Ey 5MyxCZKGeavPR3JCig54KHg3+sxgZhETCEQ/PkT5mFJLhpTE/kt5HRV4t2JBa+Pz aTpj/glgNZeQ1Mh3Fm9miCoB6AYgvg6U5wwieKxdvd/vq6FhG7cT8+NWbRbm9l3h +qT0JRmOdxP2cUU/s11LuyP5Jp7uX3uESHdiXtr/f0X5Ih4Lk639r18fsQnOFjMj CAKLvkmRFA+TyNbjwR5irUxGpKUQDwQTW90CNUEQfcznb1lQ5MUhweBMR17mCrQf jWSwA6KjkvkBUz6nz2AdzLtkf5AsnDl44BvHE37R74mKR+nLFKEVt3gxJjzlbeb6 W2FN7urlgrGsErcqIGG7tewugCwPR7FDysK0NHn3nJODH3/tm2E= =9/pE -----END PGP SIGNATURE----- --SJfqj9cuu6Df7VUKQ2l239j2xcWOoFVIi-- From nobody Sun Oct 7 13:33:59 2018 Return-Path: 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 D202F130DEE for ; Sun, 7 Oct 2018 13:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 mPvSaA__sphn for ; Sun, 7 Oct 2018 13:33:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B62D124D68 for ; Sun, 7 Oct 2018 13:33:56 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:58402 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g9FkR-0004mU-VQ; Sun, 07 Oct 2018 13:33:56 -0700 To: Paul Hoffman References: <055101d45e4f$eab33f30$c019bd90$@augustcellars.com> <735A937F-1464-464C-908F-2A107D981364@icann.org> Cc: XML Developer List From: Henrik Levkowetz Message-ID: Date: Sun, 7 Oct 2018 22:33:48 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <735A937F-1464-464C-908F-2A107D981364@icann.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MDx7pxEN1NBQCgBHE1sHOVOcIKfxxapEO" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, paul.hoffman@icann.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #39: Schema Issue, RFC 7991, New Section 2.20.4, "indent" Attribute 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2018 20:33:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MDx7pxEN1NBQCgBHE1sHOVOcIKfxxapEO Content-Type: multipart/mixed; boundary="Kp9ApO7SK1cSg8PuvbktmbjxlK6auWXoX"; protected-headers="v1" From: Henrik Levkowetz To: Paul Hoffman Cc: XML Developer List Message-ID: Subject: Re: [Ext] [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, New Section 2.20.4, "indent" Attribute References: <055101d45e4f$eab33f30$c019bd90$@augustcellars.com> <735A937F-1464-464C-908F-2A107D981364@icann.org> In-Reply-To: <735A937F-1464-464C-908F-2A107D981364@icann.org> --Kp9ApO7SK1cSg8PuvbktmbjxlK6auWXoX Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-10-07 22:20, Paul Hoffman wrote: > On Oct 7, 2018, at 8:18 AM, Henrik Levkowetz wro= te: >> The reason I expressed this in en-space is that as a rule of thumb, th= e >> average character width in a proportional font is 1 en. If we apply t= he >> indent figure as number of em-spaces, the visual impression will be a >> much larger indentation when using proportional fonts than for monospa= ced >> fonts. >=20 > This makes sense, but the reason I proposed using the em unit earlier > is that em is defined in CSS, but (I'm pretty sure) en is not. This > would make the HTML much easier to render directly, I think. I understand, but I think I covered this in both my first (and second, just now) proposal. =20 --- 2.20.4. "indent" Attribute Indicates the indentation to be used for the second and following lines of item rendering (the first line starts with the term, and is not indented). The indentation is to be interpreted as characters in text/plain rendering, and en-space units when using renderings with richer typographic support, such as html or pdf. One en-space is= assumed to be the length of 0.5 em-space in CSS units. --- The reason to use en-space is to get a comparable rendering. Equating one character step with an em-space results in very different renderings.= Using steps of 0.5em in CSS is trivial. If it makes you happier, we could change the text above to say ... the length 0.5em in CSS units. Henrik --Kp9ApO7SK1cSg8PuvbktmbjxlK6auWXoX-- --MDx7pxEN1NBQCgBHE1sHOVOcIKfxxapEO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu6bawACgkQTptXS4+7 Fxq5UA/+IDnXONa5fW1kjpqmHeseG6o5wdlpsWbUZJA9fUAnlg5oh3WeAxe4gKg6 21txwGrKXA5zVLigCwGTcy1fsJK8woZ9hAawMqU/LIQdDMrmFfoGZox+TpzvN6Lg QaqLkXfionwM6ytcbFRp4qspD8F6ANbtUB8qWoZ/MiY+khCDXQ8DlADggIND6f5u dN8qNdbWwKIzfGJk+/h5QiggSq6S9MphUBii+ysHexUZtyWvLYX/2ygulnszLhtb +zulz7iUg8qwGFr4pVkwD7XNTsRDeHGCUQOWYN1l0yJhtgZTZUku2msHtCTU/vRC jNTC6SZ73FVPwOtPTjFIV8pWUgfHUoMB3AXhlB4pgv7FiLbeB5HpeCv/JNdt7Jjb civKRY1fa5xo7E4+BaGfPIgbOenoYrVJNv6iXcWYjHWxh9icyM5YatAF8bs9P0iN 9MRciow3vZvDqsPMHlgKZopxfxcuNZJVjfWJpMQEvrqFpckMAm+JW0el9gDor9RF k/j7fey2rbvMWoNkfYdsL6ZyQyblst0jrf9kGzwq80blENRwPG3bRnOgePImkwPt Q41x/dpRjX0D6MOWZMaSfYaGy/Bbrinn2ro46RopRWgU4Hv6jHZYxI8qBGY+blMg s4nOSZf1T+DvQufuaCQv31f+h0pw9NRfUE4eSQH7lXHYLQv0JyU= =BYRI -----END PGP SIGNATURE----- --MDx7pxEN1NBQCgBHE1sHOVOcIKfxxapEO-- From nobody Sun Oct 7 14:18:52 2018 Return-Path: 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 69023130E11 for ; Sun, 7 Oct 2018 14:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 1tXJ_LS6e85m for ; Sun, 7 Oct 2018 14:18:49 -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 1000D126CC7 for ; Sun, 7 Oct 2018 14:18:49 -0700 (PDT) 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 Microsoft SMTP Server (TLS) id 15.0.1367.3; Sun, 7 Oct 2018 14:18:47 -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; Sun, 7 Oct 2018 14:18:47 -0700 From: Paul Hoffman To: Henrik Levkowetz CC: XML Developer List Thread-Topic: [Ext] [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, New Section 2.20.4, "indent" Attribute Thread-Index: AQHUXnsvXq9/RoMZZkmrB2doJjff6aUUsnwAgAAMkAA= Date: Sun, 7 Oct 2018 21:18:46 +0000 Message-ID: References: <055101d45e4f$eab33f30$c019bd90$@augustcellars.com> <735A937F-1464-464C-908F-2A107D981364@icann.org> In-Reply-To: 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=_38414EEA-B972-4C54-8EBE-54BF00FA7C0F"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #39: Schema Issue, RFC 7991, New Section 2.20.4, "indent" Attribute 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2018 21:18:50 -0000 --Apple-Mail=_38414EEA-B972-4C54-8EBE-54BF00FA7C0F Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Oct 7, 2018, at 1:33 PM, Henrik Levkowetz wrote: > > If it makes you happier, we could change the text above to say > > ... the length 0.5em in CSS units. Yes, giving the unit as ems would make it more definitive. --Paul Hoffman --Apple-Mail=_38414EEA-B972-4C54-8EBE-54BF00FA7C0F Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAwNzIxMTg0N1owIwYJKoZIhvcNAQkEMRYEFIZwKniJvTngYSrwuRY6rA6YJ3bdMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQB79TJSEkMNvk4sPCUGGwFiFkuJD/g4BfPFKLPtWpdp2/PHCReu7/PB4pGE3VPZfXtUzkfL 3kTHpXPUn/zXE6wbvPJFcJEvDVIcMW+BppzmORt/AgQn9hjdBxCxK71vIBltnEaOCLrRQ0ID3L2q lRii3gPV+Kg4gGWwkSMpfKvERsXZ5G1IN7Db1hCiq4OvRiE31PlqvzEv+3UvEX3jAIfb3hO5R2Ar R2K3hMKgJNuA0SDgE1mSfThOLw3k9jNRJxvuY24PYMfypAHEbeUsQJbADJL8LKiwA0VbGQyjKnLM sMEIeFJPh4lr2L9CihMLbmRpxYzdyG8ma/yc07+wbRMxAAAAAAAA --Apple-Mail=_38414EEA-B972-4C54-8EBE-54BF00FA7C0F-- From nobody Sun Oct 7 14:54:45 2018 Return-Path: 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 B873212777C for ; Sun, 7 Oct 2018 14:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 tztmdZr31A3F for ; Sun, 7 Oct 2018 14:54:41 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E2F6127332 for ; Sun, 7 Oct 2018 14:54:41 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:58648 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g9H0a-0006UZ-IS; Sun, 07 Oct 2018 14:54:41 -0700 To: Paul Hoffman References: <055101d45e4f$eab33f30$c019bd90$@augustcellars.com> <735A937F-1464-464C-908F-2A107D981364@icann.org> Cc: XML Developer List From: Henrik Levkowetz Message-ID: <775235a4-461b-ae58-473f-84c9b14811f4@levkowetz.com> Date: Sun, 7 Oct 2018 23:54:32 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="aBJFjP4EGf2SF5OillR0sjMES0RkO6mDu" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, paul.hoffman@icann.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #39: Schema Issue, RFC 7991, New Section 2.20.4, "indent" Attribute 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2018 21:54:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aBJFjP4EGf2SF5OillR0sjMES0RkO6mDu Content-Type: multipart/mixed; boundary="cxcbNrdIfVc0RsrpIesWXkSSW2j7iiJeR"; protected-headers="v1" From: Henrik Levkowetz To: Paul Hoffman Cc: XML Developer List Message-ID: <775235a4-461b-ae58-473f-84c9b14811f4@levkowetz.com> Subject: Re: [Ext] [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, New Section 2.20.4, "indent" Attribute References: <055101d45e4f$eab33f30$c019bd90$@augustcellars.com> <735A937F-1464-464C-908F-2A107D981364@icann.org> In-Reply-To: --cxcbNrdIfVc0RsrpIesWXkSSW2j7iiJeR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-10-07 23:18, Paul Hoffman wrote: > On Oct 7, 2018, at 1:33 PM, Henrik Levkowetz wro= te: >>=20 >> If it makes you happier, we could change the text above to say >>=20 >> ... the length 0.5em in CSS units. >=20 > Yes, giving the unit as ems would make it more definitive. Ok. Henrik --cxcbNrdIfVc0RsrpIesWXkSSW2j7iiJeR-- --aBJFjP4EGf2SF5OillR0sjMES0RkO6mDu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu6gJgACgkQTptXS4+7 FxroHg/7B8wY0qGLYoWGjddhqq/lW8FYq4Dvhfki6KFPkCGgxwP4MXUISgJRkMU9 GNKzz1ppOmbXiiL8iiRb5QhAgUVPyXXHRi/Y5M4xffyFJzZODCiQ2RoSsExCTyOo Rzh0KF4sB9SKDVPtFcgWqkQCAlAi+8bkfhOV5Jw7MkDC9/fdReRQbZbc2AjODBLC cDAPdtiHgma6WavvRea22fJNj5Ja4L0SXLGv3cx2DMM2OEmCoW/9O/pm9QJkxCIR hRl0sIXCKwL7erQKxrFW9M/w3iQZ6he3nyhj/ppQmFo/LSI+b/M83WX74hrd0zTP 4KHs+1tCNU5rsgRiImPok6BYMnaoR1BtRyox55W134bVGhNbwODrTE4wMzxQcTD2 1q/nt7a2YGNRBsZPqjPg82NouP/5ke1gugJaV8ZUs1xiaZbdg53K3drqkNGUc3Gq sVyyvTvQH614FoypU3AJC7K96/hUxcmprUuxP3XsI9KZqHntCiLEsM1rqiBMNba/ EsDW0DrmDem+MBtKEhNKKZ+sO3VwGKSofVKQx3hmxctpCEGpOl1VQiXxFgWLRArd PCpzSS4Dnb9L8uaPwXQpZ07gX3r0YzfY+Pn9rj6OGhCKELP9xYVj4cZ24zjFpCdf Ym8Wi5TSlftEZDWIdHu9poPN/ujBnhLTceK5YXavLw3HbCIFXWw= =Wfik -----END PGP SIGNATURE----- --aBJFjP4EGf2SF5OillR0sjMES0RkO6mDu-- From nobody Sun Oct 7 16:19:08 2018 Return-Path: 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 2F8C012F1AB for ; Sun, 7 Oct 2018 16:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 WuYfj4Tsq9mc for ; Sun, 7 Oct 2018 16:19:04 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C27B01277C8 for ; Sun, 7 Oct 2018 16:19:03 -0700 (PDT) Received: from Jude (192.168.0.11) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 7 Oct 2018 16:14:21 -0700 From: Jim Schaad To: 'Henrik Levkowetz' , References: <055101d45e4f$eab33f30$c019bd90$@augustcellars.com> <057801d45e7a$8f7c5c20$ae751460$@augustcellars.com> In-Reply-To: Date: Sun, 7 Oct 2018 16:18:56 -0700 Message-ID: <059401d45e94$2029fb60$607df220$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQE/60/iC0oW5uFeRsGOaCY9EO+4sAJMfbGjAKtuqJsCbqsHJQHSk4ieASEJhGQCk5C8OwGRWQHWpdlVDRA= Content-Language: en-us X-Originating-IP: [192.168.0.11] Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, New Section 2.20.4, "indent" Attribute 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2018 23:19:07 -0000 > -----Original Message----- > From: Henrik Levkowetz > Sent: Sunday, October 7, 2018 1:26 PM > To: Jim Schaad ; xml2rfc-dev@ietf.org > Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, = New > Section 2.20.4, "indent" Attribute >=20 > n 2018-10-07 22:15, Jim Schaad wrote: > > > >> -----Original Message----- > >> From: Henrik Levkowetz > >> Sent: Sunday, October 7, 2018 8:18 AM > >> To: Jim Schaad ; xml2rfc-dev@ietf.org > >> Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC > >> 7991, New Section 2.20.4, "indent" Attribute > >> > >> Hi Jim, > >> > >> On 2018-10-07 17:10, Jim Schaad wrote: > >> > > >> > > >> >> -----Original Message----- > >> >> From: xml2rfc-dev On Behalf Of > >> >> Henrik Levkowetz > >> >> Sent: Sunday, October 7, 2018 7:14 AM > >> >> To: xml2rfc-dev@ietf.org > >> >> Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC > >> >> 7991, New Section 2.20.4, "indent" Attribute > >> >> > >> >> I propose closing this ticket with the following resolution: > >> >> > >> >> Add an attribute "indent" to
    , signifying the character > >> >> indentation in monospace rendering, and the indentation measured > >> >> in en-space [1] units in other renderings. > >> >> > >> >> If there are no objections to the resolution by EOB Monday, I'll > >> >> close the > >> ticket. > >> >> > >> >> With respect to document text, I propose the following new text > >> >> under Section 2.20.
    : > >> >> > >> >> --- > >> >> 2.20.4. "indent" Attribute > >> >> > >> >> Indicates the indentation to be used for the second and = following > >> >> lines of item rendering (the first line starts with the term, = and > >> >> is not indented). The indentation is to be interpreted as = characters > >> >> for monospace renderings, and en-space units when using = proportional > >> >> fonts. One en-space is assumed to be the length of 0.5 = em-space in > >> >> CSS units. > >> > > >> > I think it would be fine just to use em rather than en. Also I > >> > don't think that the text needs to be written as different = between > >> > monospace and proportional fonts. The width of an em is going to = be > >> > font specific and is equal to a character width for monospace. If > >> > you don't do the 0.5 but just use em to start with then = everything > >> > is consistant. > >> > >> The reason I expressed this in en-space is that as a rule of thumb, > >> the average character width in a proportional font is 1 en. If we > >> apply the indent figure as number of em-spaces, the visual = impression > >> will be a much larger indentation when using proportional fonts = than for > monospaced fonts. > > > > My worry is that this means that trying to get the value right in = css > > is going to based on if the current paragraph is using a mono-space > > font (n * em) or a proportional font ( n / 2 * em). For some places = a > > mono-space font is going to be more readable and you are now getting > > different displays. >=20 > Ah. Ok, got you. What about this, then: >=20 > --- > 2.20.4. "indent" Attribute >=20 > Indicates the indentation to be used for the second and following > lines of item rendering (the first line starts with the term, and > is not indented). The indentation is to be interpreted as = characters > in text/plain rendering, and en-space units when using renderings > with richer typographic support, such as html or pdf. One en-space = is > assumed to be the length of 0.5 em-space in CSS units. > --- It took me twice to figure out what was different, but yes I think that = this works just fine. =20 Jim >=20 > > > > I understand what you are saying, I am just not too sure if it is > > going to be the correct answer in all cases. >=20 > Ack. >=20 > Henrik >=20 >=20 >=20 >=20 > > Jim > > > >> > >> > >> Best regards, > >> > >> Henrik > >> > >> > >> > > >> > Jim > >> > > >> >> > >> >> --- > >> >> > >> >> [1] https://en.wikipedia.org/wiki/En_(typography) > >> >> > >> >> > >> >> Best regards, > >> >> > >> >> Henrik > >> >> > >> >> > >> >> On 2018-10-01 14:39, Henrik Levkowetz wrote: > >> >> > Hi Julian, > >> >> > > >> >> > On 2018-10-01 14:09, Julian Reschke wrote: > >> >> >> On 10/1/2018 1:36 PM, henrik@levkowetz.com wrote: > >> >> >>> This captures an issue noted during implementation, also > >> >> >>> described in > >> >> >>> = https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-impleme > >> >> >>> nta > >> >> >>> tio > >> >> >>> n#section-3.1.4 > >> >> >>> > >> >> >>> --- > >> >> >>> New Section 2.20.4, "indent" Attribute > >> >> >>> > >> >> >>> The deprecation of the "hangIndent" attribute on = leaves no > >> >> >>> opportunity to control the size of the hanging indent. = In some > >> >> >>> definition lists, it is desirable to have a wide = indentation, in order > >> >> >>> to clearly show the terms, in other cases it is more = important to > allow > >> >> >>> for a larger text volume than the width of the terms = would allow. > >> >> >>> > >> >> >>> Recommendation: Add an "indent" attribute on
    to > >> >> >>> control the > >> size > >> >> >>> of the hanging indent. > >> >> >>> > >> >> >>> Implementation: The current version of xml2rfc does not = support > the > >> >> >>> attribute, but has all the underlying = functions needed > >> >> >>> to apply such an attribute. = Internally, an indentation > >> >> >>> is calculated based on length of the =
    text and the > >> >> >>> settings of some of the other = attributes. > >> >> >>> --- > >> >> >>> ... > >> >> >> > >> >> >> I agree that this would be useful - however we'll need to > >> >> >> define it in a way that works well with non-monospaced fonts. > >> >> > > >> >> > Agreed. > >> >> > > >> >> > What about specifying indentation as a number that would > >> >> > indicate characters in monospaced output, and en-space = otherwise? > >> >> > >> > > >> > > >> > > > > > > > From nobody Sun Oct 7 22:22:55 2018 Return-Path: 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 712FC1294D0 for ; Sun, 7 Oct 2018 22:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 IXr78mzVIYXG for ; Sun, 7 Oct 2018 22:22:51 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 421C9128B14 for ; Sun, 7 Oct 2018 22:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w985MBdd006368; Mon, 8 Oct 2018 07:22:11 +0200 (CEST) Received: from [192.168.217.102] (p54A6C3C7.dip0.t-ipconnect.de [84.166.195.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42T7yq0RdhzDWdy; Mon, 8 Oct 2018 07:22:11 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <055101d45e4f$eab33f30$c019bd90$@augustcellars.com> Date: Mon, 8 Oct 2018 07:22:10 +0200 Cc: Henrik Levkowetz , xml2rfc-dev@ietf.org X-Mao-Original-Outgoing-Id: 560668929.0377181-6b618764578014d1eb6ceb5d9f3fcc99 Content-Transfer-Encoding: quoted-printable Message-Id: <9EB6143C-F5A1-442B-9BC8-5F181754D3D6@tzi.org> References: <055101d45e4f$eab33f30$c019bd90$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, New Section 2.20.4, "indent" Attribute 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 05:22:53 -0000 On Oct 7, 2018, at 17:10, Jim Schaad wrote: >=20 > an em is going to be font specific One em is the nominal point size, which is approximately the character = height plus minimal (=E2=80=9C1.0 space=E2=80=9D) leading. > and is equal to a character width for monospace I don=E2=80=99t think so (except for square fonts such as for fullwidth = Hanzi). Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Oct 8 02:09:02 2018 Return-Path: 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 BBA80130E2E for ; Mon, 8 Oct 2018 02:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 jQdispmtWii8 for ; Mon, 8 Oct 2018 02:09:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 839B61292F1 for ; Mon, 8 Oct 2018 02:09:00 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:63934 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g9RX9-0004J1-MR; Mon, 08 Oct 2018 02:09:00 -0700 To: Carsten Bormann , Jim Schaad References: <055101d45e4f$eab33f30$c019bd90$@augustcellars.com> <9EB6143C-F5A1-442B-9BC8-5F181754D3D6@tzi.org> Cc: xml2rfc-dev@ietf.org From: Henrik Levkowetz Message-ID: Date: Mon, 8 Oct 2018 11:08:52 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <9EB6143C-F5A1-442B-9BC8-5F181754D3D6@tzi.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VB2VAVC93bQmVjPTjnKrXRq1w9pVTS13f" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, ietf@augustcellars.com, cabo@tzi.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, New Section 2.20.4, "indent" Attribute 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 09:09:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VB2VAVC93bQmVjPTjnKrXRq1w9pVTS13f Content-Type: multipart/mixed; boundary="8ld1XeAF8TQufrBFNTBRiIswne8DaluhT"; protected-headers="v1" From: Henrik Levkowetz To: Carsten Bormann , Jim Schaad Cc: xml2rfc-dev@ietf.org Message-ID: Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, New Section 2.20.4, "indent" Attribute References: <055101d45e4f$eab33f30$c019bd90$@augustcellars.com> <9EB6143C-F5A1-442B-9BC8-5F181754D3D6@tzi.org> In-Reply-To: <9EB6143C-F5A1-442B-9BC8-5F181754D3D6@tzi.org> --8ld1XeAF8TQufrBFNTBRiIswne8DaluhT Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-10-08 07:22, Carsten Bormann wrote: > On Oct 7, 2018, at 17:10, Jim Schaad wrote: >>=20 >> an em is going to be font specific >=20 > One em is the nominal point size, which is approximately the > character height plus minimal (=E2=80=9C1.0 space=E2=80=9D) leading. >=20 >> and is equal to a character width for monospace >=20 > I don=E2=80=99t think so (except for square fonts such as for fullwidth= Hanzi). I agree with this, but Jim nevertheless found an issue with the proposed text, which I believe the subsequent reformulation avoids. Best regards, Henrik --8ld1XeAF8TQufrBFNTBRiIswne8DaluhT-- --VB2VAVC93bQmVjPTjnKrXRq1w9pVTS13f Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu7HqQACgkQTptXS4+7 FxoYWxAArX/cIta2pWlc3KL+6kQHd1AVYFlXBUrQmlf7zHT74VWSGvVX9hanimAj Td2sQ/0VNwW3Sn4RkJaXh8y+C0+QGweiTamLzIqrQ+XEq6jQUVN9GvHzazdjna7S QVmgvKubY2UHWnDO34ciCCBJIyaZk/lW2SzwVdmVHZc1b/MBAMjiECUkXPykVJWB IhLBRKhiQz/U5rT9pOLel7RC7nmMdWaXhRci2AM2AWmS23/c9pG0yU21wkCVvIAM Ndi/gmdQB5esH+sK7kjYGhZx37VVIf6vMyS/PffyeC4KDVhRHocHwcueJR3XZaF1 QwcwsFiy6m/vxucJWEzKGDMAEduHh8rgeFj35c5AvlewEPDCwyls/Kl9LyqpLA2f PhCPOtOaBegAsQ7VB6NU1Uf68K+kDrfUjkjpmJ2qfuYVGSaOVUNm5XxdICV9ZoO+ +m5BXcO+2KokajMFaYwj4ioHdpqJk2WiDKiDHEnYaN4yQ/FummrME2IA8cqa5v4o lV0q1hNd9hK5wSHehRl059i/9P9ZuI3/vkBnh960MNsdWrYLJckb7AO4rdwkVCtR /LPTGtxRLKVLxzeGnmvxHVxnDE5Lhys2durlPu/Dd5ZxJZoZKxMnCkedSXdw+IJG G7xzTaS9ZWzgsQnWoAKl/A287fpPb8Ziydeg9gEvqoS9AqmjKsU= =k8wu -----END PGP SIGNATURE----- --VB2VAVC93bQmVjPTjnKrXRq1w9pVTS13f-- From nobody Mon Oct 8 07:46:39 2018 Return-Path: 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 9C6E2130E28 for ; Mon, 8 Oct 2018 07:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_MANY_HDRS_LCASE=0.01] 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 2pTXVli7tQ2r for ; Mon, 8 Oct 2018 07:46:29 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87FEB130EEE for ; Mon, 8 Oct 2018 07:46:29 -0700 (PDT) Received: from localhost ([::1]:51779 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1g9Wnl-0004WV-CR for xml2rfc-dev@ietf.org; Mon, 08 Oct 2018 07:46:29 -0700 to: xml2rfc-dev@ietf.org from: henrik@levkowetz.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Message-Id: Date: Mon, 08 Oct 2018 07:46:29 -0700 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc-dev] RFC 7991 issue #45: Schema Issue, RFC 7991, In Section 2.29,
  • , Unordered lists with arbitrary symbols 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 14:46:33 -0000 VGhpcyBjYXB0dXJlcyBhbiBpc3N1ZSBub3RlZCBkdXJpbmcgaW1wbGVtZW50YXRpb24sIGFsc28g ZGVzY3JpYmVkIGluCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sZXZrb3dldHot eG1sMnJmYy12My1pbXBsZW1lbnRhdGlvbiNzZWN0aW9uLTMuMS42LjEKClNwZWNpZmljYXRpb246 IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3OTkxI3NlY3Rpb24tMi4yOQoKLS0tClVu b3JkZXJlZCBsaXN0cyB3aXRoIGFyYml0cmFyeSBzeW1ib2xzCgogICBXaGVuIDxsaT4gaXMgdXNl ZCB3aXRoIDx1bCBlbXB0eT0idHJ1ZSI+LCB0aGUgcmVuZGVyaW5nIGlzIHVuZGVyLQogICBzcGVj aWZpZWQgKHRoZSBzcGVjaWZpY2F0aW9uIHNheXMgJ25vIGxhYmVsIHdpbGwgYmUgc2hvd24iLCBi dXQgZG9lc24ndAogICBzYXkgd2hldGhlciBsaXN0IGluZGVudGF0aW9uIChsZWFkaW5nIHdoaXRl LXNwYWNlKSBzaG91bGQgYmUgZWxpbWluYXRlZAogICBvciBub3QuCgogICBJZiB0aGUgaW50ZW50 aW9uIGlzIHRvIG1ha2UgaXQgcG9zc2libGUgdG8gcmVuZGVyIHVub3JkZXJlZCBsaXN0cyB3aXRo CiAgIGFyYml0cmFyeSBzeW1ib2xzLCBjaG9zZW4gb24gYSBwZXItbGlzdC1pdGVtIGJhc2lzLCB0 aGUgY3VycmVudAogICBhdHRyaWJ1dGVzIG9mIDxsaT4gYXJlIGluc3VmZmljaWVudCB0byBpbmRl bnQgYW5kIGxpbmUtd3JhcCBsaXN0IGl0ZW1zCiAgIHByb3Blcmx5IHdpdGggPHVsIGVtcHR5PSd0 cnVlJz4uCgogICBJdCBpcyBub3QgcG9zc2libGUsIGZvciBpbnN0YW5jZSwgdG8gdXNlIDx1bD4g bGlzdHMgdG8gZ2VuZXJhdGUgWE1MIGZvcgogICBhIHRhYmxlIG9mIGNvbnRlbnQsIHNpbmNlIGlm IHRoZSB3aWR0aCBvZiB0aGUgYnVsbGV0ICh0aGUgc2VjdGlvbgogICBudW1iZXIsIGluIHRoaXMg Y2FzZSkgaXMgdW5rbm93biwgdGhlIHByb3BlciBpbmRlbnRhdGlvbiBhbmQgbGluZQogICB3cmFw cGluZyBjYW5ub3QgYmUgZGV0ZXJtaW5lZC4KCiAgIFByb3Bvc2FsOiAgICAgICAgQWRkIGFuIGV4 cGxpY2l0ICJidWxsZXQiIGF0dHJpYnV0ZSB0byBzdXBwb3J0IHRoaXMgdXNlCiAgICAgICAgICAg ICAgICAgICAgY2FzZS4KCiAgIEltcGxlbWVudGF0aW9uOiAgTm9uZSBpbiB0aGUgY3VycmVudCB2 ZXJzaW9uIG9mIHhtbDJyZmMsIGJ1dCBpbnRlcm5hbGx5CiAgICAgICAgICAgICAgICAgICAgYnVs bGV0cyBhcmUgdGFrZW4gYSBjb25maWd1cmFibGUgYnVsbGV0IGxpc3QsIHNvCiAgICAgICAgICAg ICAgICAgICAgYWNjb21tb2RhdGluZyBzdWNoIGFuIGF0dHJpYnV0ZSB3b3VsZCBiZSB0cml2aWFs LgotLS0KClJlZ2FyZHMsCglIZW5yaWsKCi0tLQpUaGlzIGlzc3VlIGlzIHRyYWNrZWQgYXQ6CiAg IGh0dHBzOi8vZ2l0aHViLmNvbS9yZmMtZm9ybWF0L2RyYWZ0LWlhYi14bWwycmZjLXYzLWJpcy9p c3N1ZXMvNDUKCkRpc2N1c3Npb24gc2hvdWxkIHRha2UgcGxhY2Ugb24gdGhpcyBsaXN0Lg== From nobody Mon Oct 8 07:46:43 2018 Return-Path: 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 8C063130E28 for ; Mon, 8 Oct 2018 07:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_MANY_HDRS_LCASE=0.01] 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 WDIoV7cSu8Q8 for ; Mon, 8 Oct 2018 07:46:31 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27BE0130EF0 for ; Mon, 8 Oct 2018 07:46:30 -0700 (PDT) Received: from localhost ([::1]:51784 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1g9Wnm-0004qF-0T for xml2rfc-dev@ietf.org; Mon, 08 Oct 2018 07:46:30 -0700 to: xml2rfc-dev@ietf.org from: henrik@levkowetz.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Message-Id: Date: Mon, 08 Oct 2018 07:46:30 -0700 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc-dev] RFC 7991 issue #46: Schema Issue, RFC 7991, In Section 2.29,
  • , Mixed Content Model 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 14:46:34 -0000 VGhpcyBjYXB0dXJlcyBhbiBpc3N1ZSBub3RlZCBkdXJpbmcgaW1wbGVtZW50YXRpb24sIGFsc28g ZGVzY3JpYmVkIGluCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sZXZrb3dldHot eG1sMnJmYy12My1pbXBsZW1lbnRhdGlvbiNzZWN0aW9uLTMuMS42LjIKClNwZWNpZmljYXRpb246 IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3OTkxI3NlY3Rpb24tMi4yOQoKLS0tCk1p eGVkIENvbnRlbnQgTW9kZWwKCiAgIFRoZSBtaXhlZCBjb250ZW50IG1vZGVsIGZvciA8bGk+IOKA lC0gZWl0aGVyIHRleHQgYW5kIGlubGluZSBlbGVtZW50cyBsaWtlCiAgIHN1Yiwgc3VwLCBiY3Ax NCwgX29yXyA8dD4sIDx1bD4sIDxmaWd1cmU+IGV0YywgaXMgbm9uLWludHVpdGl2ZSBhbmQgbWF5 CiAgIGJlIGhhcmQgZm9yIHVzZXJzIHRvIGtlZXAgc3RyYWlnaHQuCgogICBQcm9wb3NhbDogICAg ICAgIENvbnNpZGVyIHNpbXBsaWZ5aW5nIHRoZSBzY2hlbWEgYnkgcmVxdWlyaW5nIHRoYXQgdGV4 dAogICAgICAgICAgICAgICAgICAgIGFuZCBpbmxpbmUgZWxlbWVudHMgYWx3YXlzIGFyZSBwbGFj ZWQgd2l0aGluIGEgPHQ+CiAgICAgICAgICAgICAgICAgICAgZWxlbWVudC4KCiAgIEltcGxlbWVu dGF0aW9uOiAgTm90IGRvbmUgaW4gdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB4bWwycmZjLgoKICAg VGhpcyB3b3VsZCBhcHBseSBhbHNvIHRvIG90aGVyIGVsZW1lbnRzIHRoYXQgdG9kYXkgaGF2ZSBh bHRlcm5hdGl2ZQogICBjb250ZW50IG1vZGVsczogPGJsb2NrcXVvdGU+LCA8ZGQ+LCA8dGQ+LCBh bmQgPHRoPi4KLS0tCgpSZWdhcmRzLAoJSGVucmlrCgotLS0KVGhpcyBpc3N1ZSBpcyB0cmFja2Vk IGF0OgogICBodHRwczovL2dpdGh1Yi5jb20vcmZjLWZvcm1hdC9kcmFmdC1pYWIteG1sMnJmYy12 My1iaXMvaXNzdWVzLzQ2CgpEaXNjdXNzaW9uIHNob3VsZCB0YWtlIHBsYWNlIG9uIHRoaXMgbGlz dC4= From nobody Mon Oct 8 07:46:50 2018 Return-Path: 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 B271A130EBF for ; Mon, 8 Oct 2018 07:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_MANY_HDRS_LCASE=0.01] 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 YPjvAYSBt1E0 for ; Mon, 8 Oct 2018 07:46:32 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1DD0130ECB for ; Mon, 8 Oct 2018 07:46:30 -0700 (PDT) Received: from localhost ([::1]:51787 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1g9Wnm-00053m-IV for xml2rfc-dev@ietf.org; Mon, 08 Oct 2018 07:46:30 -0700 to: xml2rfc-dev@ietf.org from: henrik@levkowetz.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Message-Id: Date: Mon, 08 Oct 2018 07:46:30 -0700 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc-dev] RFC 7991 issue #47: Schema Issue, RFC 7991, In Section 2.32, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 14:46:39 -0000 VGhpcyBjYXB0dXJlcyBhbiBpc3N1ZSBub3RlZCBkdXJpbmcgaW1wbGVtZW50YXRpb24sIGFsc28g ZGVzY3JpYmVkIGluCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sZXZrb3dldHot eG1sMnJmYy12My1pbXBsZW1lbnRhdGlvbiNzZWN0aW9uLTMuMS43CgpTcGVjaWZpY2F0aW9uOiBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzk5MSNzZWN0aW9uLTIuMzIKCi0tLQpJbiBT ZWN0aW9uIDIuMzIsIDxuYW1lPgoKICAgU28gdGhlIDxuYW1lPiBlbGVtZW50IGNhbiBjb250YWlu IHRleHQgb3IgPHR0PiwgYW5kIDx0dD4gY2FuIGNvbnRhaW4KICAgb3RoZXIgbWFya3VwIGxpa2Ug PHN1Yj4gYW5kIDxzdXA+IGV0Yy4sIGJ1dCB3aHkgY2Fubm90IDxuYW1lPiBjb250YWluCiAgIDxz dXA+IGV0Yy4gIGRpcmVjdGx5PwoKICAgUHJvcG9zYWw6ICAgICAgICBDaGFuZ2UgdGhlIDxuYW1l PiBlbGVtZW50IHNjaGVtYSB0byBwZXJtaXQgYWxsIGlubGluZQogICAgICAgICAgICAgICAgICAg IGVsZW1lbnRzIHRoYXQgPHR0PiBjYW4gY29udGFpbiwgaW4gYWRkaXRpb24gdG8gPHR0Pi4KCiAg IEltcGxlbWVudGF0aW9uOiAgTm90IGNoYW5nZWQgaW4gdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB4 bWwycmZjLgogICAgICAgICAgICAgICAgICAgIEltcGxlbWVudGluZyB0aGlzIHdvdWxkIGJlIGEg c2ltcGxlIG1hdHRlciBvZiBjaGFuZ2luZwogICAgICAgICAgICAgICAgICAgIHRoZSB2MyBzY2hl bWE7IG5vIGZvcm1hdHRlciBjaGFuZ2VzIHdvdWxkIGJlIG5lZWRlZC4KLS0tCgpSZWdhcmRzLAoJ SGVucmlrCgotLS0KVGhpcyBpc3N1ZSBpcyB0cmFja2VkIGF0OgogICBodHRwczovL2dpdGh1Yi5j b20vcmZjLWZvcm1hdC9kcmFmdC1pYWIteG1sMnJmYy12My1iaXMvaXNzdWVzLzQ3CgpEaXNjdXNz aW9uIHNob3VsZCB0YWtlIHBsYWNlIG9uIHRoaXMgbGlzdC4= From nobody Mon Oct 8 07:47:30 2018 Return-Path: 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 67073130E27 for ; Mon, 8 Oct 2018 07:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_MANY_HDRS_LCASE=0.01] 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 tj0vG8umDmSu for ; Mon, 8 Oct 2018 07:47:27 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A91E4130DEC for ; Mon, 8 Oct 2018 07:47:27 -0700 (PDT) Received: from localhost ([::1]:51808 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1g9Woh-000754-Ia for xml2rfc-dev@ietf.org; Mon, 08 Oct 2018 07:47:27 -0700 to: xml2rfc-dev@ietf.org from: henrik@levkowetz.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Message-Id: Date: Mon, 08 Oct 2018 07:47:27 -0700 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 14:47:30 -0000 VGhpcyBjYXB0dXJlcyBhbiBpc3N1ZSBub3RlZCBkdXJpbmcgaW1wbGVtZW50YXRpb24sIGFsc28g ZGVzY3JpYmVkIGluCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sZXZrb3dldHot eG1sMnJmYy12My1pbXBsZW1lbnRhdGlvbiNzZWN0aW9uLTMuMS44CgpTcGVjaWZpY2F0aW9uOiBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzk5MSNzZWN0aW9uLTIuNDAuMgoKLS0tCklu IFNlY3Rpb24gMi40MC4yLCAicXVvdGVUaXRsZSIKCiAgIFRoZSB2ZXJzaW9uIHR3byB4bWwycmZj IHByb2Nlc3NvcnMgYWxyZWFkeSBzdXBwb3J0IHRoZSBhdHRyaWJ1dGUgInF1b3RlLQogICB0aXRs ZSIuICBUaGUgYXR0cmlidXRlIG5hbWUgY2hhbmdlIGludHJvZHVjZXMgYW4gaW5jb21wYXRpYmls aXR5LiAgVGhpcwogICBpbiBwYXJ0aWN1bGFyIGltcGFjdHMgZXhpc3RpbmcgYmlieG1sIHJlZmVy ZW5jZSBmaWxlcywgd2hpY2ggc2hvdWxkIHdvcmsKICAgd2l0aCBib3RoIHZlcnNpb24gMiBhbmQg MyB2b2NhYnVsYXJ5IGRvY3VtZW50cy4KCiAgIFByb3Bvc2FsOiAgICAgICAgQ2hhbmdlIHRoZSBh dHRyaWJ1dGUgbmFtZSBiYWNrIHRvIHRoZSB2YWx1ZSBzdXBwb3J0ZWQKICAgICAgICAgICAgICAg ICAgICBieSB0aGUgdm9jYWJ1bGFyeSB2ZXJzaW9uIDIgbW9kZXMgb2YgeG1sMnJmYy4KCiAgIElt cGxlbWVudGF0aW9uOiAgVGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB4bWwycmZjIGNvbnZlcnRzICJx dW90ZS10aXRsZSIKICAgICAgICAgICAgICAgICAgICB0byAicXVvdGVUaXRsZSIgZHVyaW5nIHYy djMgY29udmVyc2lvbiwgYnV0IHRoaXMgaXMKICAgICAgICAgICAgICAgICAgICByZWFsbHkgc3Vi LW9wdGltYWwuCi0tLQoKUmVnYXJkcywKCUhlbnJpawoKLS0tClRoaXMgaXNzdWUgaXMgdHJhY2tl ZCBhdDoKICAgaHR0cHM6Ly9naXRodWIuY29tL3JmYy1mb3JtYXQvZHJhZnQtaWFiLXhtbDJyZmMt djMtYmlzL2lzc3Vlcy80OAoKRGlzY3Vzc2lvbiBzaG91bGQgdGFrZSBwbGFjZSBvbiB0aGlzIGxp c3Qu From nobody Mon Oct 8 07:47:38 2018 Return-Path: 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 0C590130DEC for ; Mon, 8 Oct 2018 07:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_MANY_HDRS_LCASE=0.01] 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 7wtUzA6QW29Q for ; Mon, 8 Oct 2018 07:47:28 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D3C130E1E for ; Mon, 8 Oct 2018 07:47:28 -0700 (PDT) Received: from localhost ([::1]:51811 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1g9Woi-00076N-7F for xml2rfc-dev@ietf.org; Mon, 08 Oct 2018 07:47:28 -0700 to: xml2rfc-dev@ietf.org from: henrik@levkowetz.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Message-Id: Date: Mon, 08 Oct 2018 07:47:28 -0700 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 14:47:30 -0000 VGhpcyBjYXB0dXJlcyBhbiBpc3N1ZSBub3RlZCBkdXJpbmcgaW1wbGVtZW50YXRpb24sIGFsc28g ZGVzY3JpYmVkIGluCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sZXZrb3dldHot eG1sMnJmYy12My1pbXBsZW1lbnRhdGlvbiNzZWN0aW9uLTMuMS45CgpTcGVjaWZpY2F0aW9uOiBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzk5MSNzZWN0aW9uLTIuNDIKCi0tLQpJbiBT ZWN0aW9uIDIuNDIsIDxyZWZlcmVuY2VzPgoKICAgVGhlIHYzIHNjaGVtYSBjYW5ub3QgcHJvcGVy bHkgbW9kZWwgbXVsdGlwbGUgcmVmZXJlbmNlIHN1YnNlY3Rpb25zCiAgIGNvbnRhaW5lZCB3aXRo aW4gb25lIG51bWJlcmVkIHNlY3Rpb24uICBUaGUgdjIgZm9ybWF0dGVyIGhhbmRsZWQgdGhpcyBi eQogICBzaWxlbnRseSBpbnNlcnRpbmcgYW4gZW5jbG9zaW5nIHNlY3Rpb24sIGJ1dCB3aXRoIHRo ZSBpbnRyb2R1Y3Rpb24gb2YKICAgdGhlIHByZXB0b29sLCB3aGljaCBpbiB0aGVvcnkgc2hvdWxk IHByb2R1Y2UgYSBtYXN0ZXIgZmlsZSBmcm9tIHdoaWNoCiAgIHZhcmlvdXMgZm9ybWF0dGVycyB3 b3VsZCBwcm9kdWNlIGVxdWl2YWxlbnQgcmVzdWx0cywgdGhpcyBiZWNvbWVzCiAgIHRyb3VibGVz b21lLCBhcyB0aGUgYXV0b21hdGljIGluc2VydGlvbiBvZiBhIGNvbnRhaW5lciBzZWN0aW9uIGlz CiAgIHNwZWNpZmllZCBmb3IgdGhlIGh0bWwgZm9ybWF0dGVyLCBpbiBzZWN0aW9uIDkuOC4gb2Yg UkZDIDc5OTIsIGJ1dCBub3QKICAgZm9yIHRoZSB0ZXh0IGZvcm1hdHRlci4gIEl0IHdvdWxkIGJl IG11Y2ggYmV0dGVyIHRvIG1ha2UgdGhlIHByZXBwZWQgeG1sCiAgIGV4cGxpY2l0bHkgc2hvdyBl eGFjdGx5IHdoYXQgc2hvdWxkIGJlIHJlbmRlcmVkLCBhbmQgbm90IHJlbHkgb24KICAgZm9ybWF0 dGVycyBzaWxlbnRseSBpbnNlcnQgZWxlbWVudHMuCgogICBQcm9wb3NhbDogICAgICAgIFVwZGF0 ZSB0aGUgc2NoZW1hIHRvIG1ha2UgaXQgcG9zc2libGUgZm9yIDxyZWZlcmVuY2VzPgogICAgICAg ICAgICAgICAgICAgIHRvIGNvbnRhaW4gPHJlZmVyZW5jZXM+LCBhbmQgaGF2ZSB0aGUgcHJlcHBl ZCB4bWwKICAgICAgICAgICAgICAgICAgICBleHBsaWNpdGx5IHNob3cgYm90aCB0aGUgZW5jYXBz dWxhdGluZyBzZWN0aW9uIGFuZCB0aGUKICAgICAgICAgICAgICAgICAgICBzdWJzZWN0aW9ucy4K CiAgIEltcGxlbWVudGF0aW9uOiAgSW1wbGVtZW50ZWQgYXMgcHJvcG9zZWQgaW4gdGhlIGN1cnJl bnQgdmVyc2lvbiBvZgogICAgICAgICAgICAgICAgICAgIHhtbDJyZmMuCi0tLQoKUmVnYXJkcywK CUhlbnJpawoKLS0tClRoaXMgaXNzdWUgaXMgdHJhY2tlZCBhdDoKICAgaHR0cHM6Ly9naXRodWIu Y29tL3JmYy1mb3JtYXQvZHJhZnQtaWFiLXhtbDJyZmMtdjMtYmlzL2lzc3Vlcy80OQoKRGlzY3Vz c2lvbiBzaG91bGQgdGFrZSBwbGFjZSBvbiB0aGlzIGxpc3Qu From nobody Mon Oct 8 07:53:31 2018 Return-Path: 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 2B733130DEC for ; Mon, 8 Oct 2018 07:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 9aiNK6Z5kA33 for ; Mon, 8 Oct 2018 07:53:22 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6721C130E27 for ; Mon, 8 Oct 2018 07:53:22 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:50448 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g9WuP-0004qh-Bv for xml2rfc-dev@ietf.org; Mon, 08 Oct 2018 07:53:22 -0700 To: XML Developer List References: <02bc01d45ac5$7ae71a10$70b54e30$@augustcellars.com> <030e01d45b29$1c7b33d0$55719b70$@augustcellars.com> <3FC3AF27-D05C-414C-BC64-776DDCCD1100@icann.org> From: Henrik Levkowetz Message-ID: <502954f2-ebda-0f84-79d6-344c72477eed@levkowetz.com> Date: Mon, 8 Oct 2018 16:53:14 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FHK7FjE9rXB038AlIolkb8NktqLWFcMNB" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #38: Schema Issue, RFC 7991, In Section 2.20,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 14:53:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FHK7FjE9rXB038AlIolkb8NktqLWFcMNB Content-Type: multipart/mixed; boundary="oDeFQqqdeJMXDIFe7mbB9J7kO5vsVBOuu"; protected-headers="v1" From: Henrik Levkowetz To: XML Developer List Message-ID: <502954f2-ebda-0f84-79d6-344c72477eed@levkowetz.com> Subject: Re: [xml2rfc-dev] RFC 7991 issue #38: Schema Issue, RFC 7991, In Section 2.20,
    References: <02bc01d45ac5$7ae71a10$70b54e30$@augustcellars.com> <030e01d45b29$1c7b33d0$55719b70$@augustcellars.com> <3FC3AF27-D05C-414C-BC64-776DDCCD1100@icann.org> In-Reply-To: --oDeFQqqdeJMXDIFe7mbB9J7kO5vsVBOuu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I propose closing this ticket with the following resolution: In Section 2.20.2. "hanging" Attribute: Change "hanging" to "newline" throughout. If there are no objections to the resolution by EOB Tuesday, I'll close t= he ticket.=20 Best regards, Henrik On 2018-10-04 01:13, Paul Hoffman wrote: > On 1 Oct 2018, at 4:35, henrik@levkowetz.com wrote: >=20 >> This captures an issue noted during implementation, also described in >> https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation#= section-3.1.3 >> >> Specification: https://tools.ietf.org/html/rfc7991#section-2.20 >> >> --- >> In Section 2.20,
    >> >> The current specification says: >> >> "The "hanging" attribute defines whether or not the term appears= on >> the same line as the definition. hanging=3D"true" indicates tha= t the >> term is to the left of the definition, while hanging=3D"false" >> indicates that the term will be on a separate line." >> >> This does not match established typographic terminology. In typogr= aphic >> terminology, "hanging indent" describes the case where the indentat= ion >> of the second and subsequent lines of a paragraph is greater than t= he >> indentation of the first line. Whether the definition in a definit= ion >> list starts on the first line or not has nothing to do with the pre= sence >> of hanging indent; our definition lists will _always_ have hanging >> indent. >> >> The 'hanging' attribute also describes something different from wha= t the >> term has been used to describe in the version 2 vocabulary. This w= ill >> be confusing to users. >> >> A more descriptive name for the attribute we're talking about would= be >> 'start-definition-on-first-line', but that's unwieldy. Maybe >> 'newline=3D"false"' to start the definition on the first line, or >> something like 'definition-start=3D"first"'? >> >> Recommendation: Change this to a different term that is more >> descriptive and does not use typographically incor= rect >> terminology. >> >> Implementation: The current version of xml2rfc still uses "hanging= ". >=20 > I like the idea of changing this to "newline" with boolean values. >=20 > --Paul Hoffman >=20 >=20 >=20 > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc-dev >=20 --oDeFQqqdeJMXDIFe7mbB9J7kO5vsVBOuu-- --FHK7FjE9rXB038AlIolkb8NktqLWFcMNB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu7b1oACgkQTptXS4+7 FxpFCQ//WWQMjXY2zTPSsYfwjcNioafDL3OzZe2TbVI3f/4Ikh7t1bLgaqrT/yCH 6Kc2g/p46iUcXV0R4QC/lEWynHhe772ogUQaLGExyZXbW4GHi8i8EnmV7cEZZi1I 0mqxsDin3BcunRzzZ3DaG0EYvdiPMgQI0za6V7i1OcUmcmlz4gcc2wYEXf9A/14d LYzWEikcoaD/BRriyFddycqLSyABuiWIeBxSn4qv9qF91dekGJ3sRNLjaC1cBg9+ lEO2zI0W9/hfCgJ05Jt39DjXhz55Z73Me+EGQebWxotXUPBu75qPsgDuObFGxG/W cJKFqLbYNm1tuExPcfGit18wFZN1ARyVUJ3Fe0dMVdy0xKuY75GW7tfrd4URqYKG /q+aLkW7Ohnq/8vd2huHgVcWB47mO3jzTXJaUoglRAH2Sf93CK7ddSNi20oDQnqD cyLmh2PG2/ZE5JfY7AGN9koedR/Z4aEQDYyC+hezruPBOb5B1VURYfENVgop8zhr ZHAH0MP5WB+Yx3kE/T/BHyujyMKDNGK6Ak/Lz3KirSdSIpM6aKj3Py9xEXckYBOy UNCZOiXoqu/D7AnEqpA8pOr58Xb2r4YqH/RMAej1hruIVOejIQE1xv6wq+rKPWuo Qz/yzmJ6G3XCVIOwDbNNKjDikgq/873ycrbhCqgaYtF+d4WtWQM= =kQnC -----END PGP SIGNATURE----- --FHK7FjE9rXB038AlIolkb8NktqLWFcMNB-- From nobody Mon Oct 8 08:05:25 2018 Return-Path: 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 901F2130E01 for ; Mon, 8 Oct 2018 08:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 HBuBpMuxlAnM for ; Mon, 8 Oct 2018 08:05:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73CE9130DCC for ; Mon, 8 Oct 2018 08:05:21 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:50512 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g9X5z-0004Lb-Lm; Mon, 08 Oct 2018 08:05:20 -0700 To: Julian Reschke , xml2rfc-dev@ietf.org References: <58b7afb2-53a4-8ee0-ba99-6d4a90c561af@gmx.de> <761f6c13-8964-ab27-2899-3d3ca1d7ab97@levkowetz.com> From: Henrik Levkowetz Message-ID: <7baec800-47b0-8ed7-115b-a5962750524c@levkowetz.com> Date: Mon, 8 Oct 2018 17:05:12 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <761f6c13-8964-ab27-2899-3d3ca1d7ab97@levkowetz.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="05iRnh8bPm2RwdWal1p3O40t6aAtQ738R" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #40: Schema Issue, RFC 7991, New Section 2.54.2 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 15:05:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --05iRnh8bPm2RwdWal1p3O40t6aAtQ738R Content-Type: multipart/mixed; boundary="U2G3L3gnOIDmqRjRx54qSO9b3PeAILNLr"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , xml2rfc-dev@ietf.org Message-ID: <7baec800-47b0-8ed7-115b-a5962750524c@levkowetz.com> Subject: Re: [xml2rfc-dev] RFC 7991 issue #40: Schema Issue, RFC 7991, New Section 2.54.2 References: <58b7afb2-53a4-8ee0-ba99-6d4a90c561af@gmx.de> <761f6c13-8964-ab27-2899-3d3ca1d7ab97@levkowetz.com> In-Reply-To: <761f6c13-8964-ab27-2899-3d3ca1d7ab97@levkowetz.com> --U2G3L3gnOIDmqRjRx54qSO9b3PeAILNLr Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I closed this ticket earlier, with reference to the earlier ticket #9, wh= ich also covered this issue. The only comment so far is a +1 from Julian. Unless there are additional= comments, I'll take this as accepted at EoB Tuesday. With respect to document text, I propose the following new text under a new Section 2.54.1, which bumps the current 2.54.1 up to 2.54.2, due to alphabetic ordering of sections based on the attribute names. --- 2.56.1. "align" Attribute Controls whether the table as a whole appears left justified, centered= (default), or right justified. Allowed values: o "left" o "center" (default) o "right" --- Best regards, Henrik On 2018-10-01 14:45, Henrik Levkowetz wrote: >=20 > On 2018-10-01 14:11, Julian Reschke wrote: >> On 10/1/2018 1:36 PM, henrik@levkowetz.com wrote: >>> This captures an issue noted during implementation, also described in= >>> https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation= #section-3.1.5 >>>=20 >>> --- >>> New Section 2.54.2 >>>=20 >>> The version 3 schema deprecates the previously available 'align' >>> attribute for the tables, and the V2 to V3 converter will remove = this >>> attributes if used. This makes a previous feature that was appre= ciated >>> by some authors unavailable. In the text formatter, the effect i= s >>> simply to make all tables left-aligned, which may not be the most= >>> readable and polished output, but for the HTML formatter it also >>> potentially removes the option of letting text flow around smalle= r >>> tables in a controlled way. >>>=20 >>> Recommendation: Make the 'align' attribute for tables available = again. >>>=20 >>> Implementation: Implemented but inactive in the current version = of >>> xml2rfc. The current text formatter code alread= y has >>> support for the 'align' attribute for these elem= ents; >>> but since the schema does not permit the attribu= te for >>>
    • , the code is never invoked. >>> --- >>> ... >>=20 >> +1, but duplicates #9. >=20 > Ack. >=20 > Henrik >=20 >=20 >=20 > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc-dev >=20 --U2G3L3gnOIDmqRjRx54qSO9b3PeAILNLr-- --05iRnh8bPm2RwdWal1p3O40t6aAtQ738R Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu7cigACgkQTptXS4+7 FxqIfg/7Bx8Nm6fXpkTvQ1NH5VxCBi2Zolg+SS5MMAccmkjhvdJtWiB5OYThcHCF ZytLAJtUb/+YaMelv6y+YobIRU6G8XqdAjGl/JMdIUeDLsBZOLy1vOD8N42SSETL WFDO5KhRWFCRXnteD1ewBocW8o/gz808IMfx5qTB03kNjS2QypR47J/iefwmiZrB 6QR9aoOFWkkzUOoHWYBI98Kd5hekO5Kt3AguUjd92ABw/KhumYX14N6iZsi0gY9f vEJ9FqED8oR8XDsMJgB8ZrQmEMa/zmJp1PytJRYbheVv1FfjorTos67DJ+M3Fm82 4LLY3EO7fWIE/M8O0v8YX2Uh9hXVAjOcJkLGR/3txFnY4FvtVUSIP64ST9LIfavy hj1QsVmWLTtVrEJIn1MD3J/bmCAcw6x45YN5hGn0K3A43ucdmF2To0Dy4wsJ1p7t Tn4xCSwDeOkg1zYaWMI6qqkzNDMZeCLqlhTWSwWCek/4ibdGHAhsO+tujdOE8m61 JX3U/csvNogecgJtv6BXsYGh+0aFx/wfncwHfBT0Gd2lpb7B6jyBp6pg7jwuJVWZ 7mHcT90aXO0FY0Pm9PMLH+KZ9dGYjm8yplCRanC3Z9271Z5UxpCABGe4qqdM62CX XRksC7w93GMzeVrX8ZzouU2N7GZk2ngUTuC08NJkrhZGUG5JpiI= =Lo+I -----END PGP SIGNATURE----- --05iRnh8bPm2RwdWal1p3O40t6aAtQ738R-- From nobody Mon Oct 8 08:08:53 2018 Return-Path: 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 B08AA130E61 for ; Mon, 8 Oct 2018 08:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 gEkToJk5jlUM for ; Mon, 8 Oct 2018 08:08:46 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16406130E0A for ; Mon, 8 Oct 2018 08:08:45 -0700 (PDT) Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LaKaw-1fQ02d3uOM-00m1Fi; Mon, 08 Oct 2018 17:08:29 +0200 Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LaKaw-1fQ02d3uOM-00m1Fi; Mon, 08 Oct 2018 17:08:29 +0200 To: henrik@levkowetz.com, xml2rfc-dev@ietf.org References: From: Julian Reschke Message-ID: Date: Mon, 8 Oct 2018 17:08:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:3s45DiHwya5xXUnTYsF5vTKTKoOGS9FB8I19dcxhUa0v4Jmm0HV oZ52AF2fBdylhZG6IZtFyG4kIK9K2qMFMUQM7XCk1iXuJ5cxzCNeD8osSwHdWsOV8HW2JiG A846jt4KFk+town/dCy89hSMB5ZgW8/Pv5KfL1Ns9N0kcGEp5I/5GB/tiJgLsB2mZk/d3O3 liAZe6xF6SBhYBb3tPv3w== X-UI-Out-Filterresults: notjunk:1;V01:K0:/o47TOj3Krk=:KoQOidpD8GVnGt4h8Jb3BI ygiwbRJ1ZDNsNq1X9CGvBmqN3ODU1c3ERJMbCmMklYe5SOZ1yg5FiVFEaiArrhdoQ0QL80I2d y3CbC1PwdifJIq4+EFAaFtg+dfLD3HmrH2UfgylRbgTcF/pFFTaUY8nZQ3j/Iq8phN4FYopdB n0sOCzagTFKn1EpFdAhG1eRa0YUbnyUS24bXNTO5S2yRg64uSPSZ2Y3zhGDcILEQ/qGn16jK/ n7ADhBylmS0ozmOmCxAAUg9UMCRiJy2TTNcvlUUUVgjQgj/TvLiv4pKRduZB77tiK+r9hoZDC HyWzTdSRxFOeLzD2HhoxHIgx5FqaFQDFSzZk4395K+0cOCo5vf3bs8JRo4HOgm5S1blcjeZ/A gGfui3w2RkJD6u2N3ZqLhMtc0eSjNCbV2bAheY3tGyScBi3Dpum0hC0kmSlj4291cj4sDVvM2 aZFJbFsrGP2PysvFS7gNh2KapX7OR7jmVz5LGUdfKPQiq2ugNhIhbcFuxuH86e76g0W98SQWA jcudZkFFxAOzcIg9oAPp4Njy40O1doXfaHQxSikB80dRVHQas+IDogiH8rKhmC4MSE4wKqSLJ /0c5M+qPNHR1zndHzPfU7bcRfLr16Mn1X83BA59blc8Yl4uvTbnLQpexWgClylo1MMrKye1mA G1ChvYuVL4it6+o/O3EEAWsVf2AIgtgwgZaHLQ7sOQuYDJyM/CW1FziCEeIg8lyOPEMrOU5KQ bxX2FTIJjo2FhqifZK4WCOMU91Th2lNJTpB0p8Du8PNwDZZrc7q6LFzNV8qzox8E6iujl7j6J /XvvM9hDRqcHp5huT+n/6KkYc1gDXZA4O/7XhJh8PECPY5aV5A= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #45: Schema Issue, RFC 7991, In Section 2.29,
  • , Unordered lists with arbitrary symbols 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 15:08:52 -0000 On 2018-10-08 16:46, henrik@levkowetz.com wrote: > This captures an issue noted during implementation, also described in > https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation#section-3.1.6.1 > > Specification: https://tools.ietf.org/html/rfc7991#section-2.29 > > --- > Unordered lists with arbitrary symbols > > When
  • is used with
      , the rendering is under- > specified (the specification says 'no label will be shown", but doesn't > say whether list indentation (leading white-space) should be eliminated > or not. Well, rendering in general is not well specified. In particular not for plain text output. For HTML it mainly depends on the CSS, which is essentially configurable and outside the scope of the language definition. > If the intention is to make it possible to render unordered lists with > arbitrary symbols, chosen on a per-list-item basis, the current > attributes of
    • are insufficient to indent and line-wrap list items > properly with
        . No, that was not the intent. > It is not possible, for instance, to use
          lists to generate XML for > a table of content, since if the width of the bullet (the section > number, in this case) is unknown, the proper indentation and line > wrapping cannot be determined. I understand that you'd like the vocabulary to do extra as intermediate format inside your implementation. That's your design choice, but it doesn't need to affect the user-visible vocabulary. For instance, you can implement whatever you need to augment the XML in a separate XML namespace. > Proposal: Add an explicit "bullet" attribute to support this use > case. > > Implementation: None in the current version of xml2rfc, but internally > bullets are taken a configurable bullet list, so > accommodating such an attribute would be trivial. > --- -1, for the above reasons. That said, I'm not against having unordered lists with custom symbols, but the way you arrived at this proposal doesn't work for me. Best regards, Julian From nobody Mon Oct 8 08:10:39 2018 Return-Path: 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 63B86130DCE for ; Mon, 8 Oct 2018 08:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 97THDa_HQFTd for ; Mon, 8 Oct 2018 08:10:36 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AC5B130DEC for ; Mon, 8 Oct 2018 08:10:36 -0700 (PDT) Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M8JyQ-1fn2Ev3WUc-00vxyf; Mon, 08 Oct 2018 17:10:23 +0200 Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M8JyQ-1fn2Ev3WUc-00vxyf; Mon, 08 Oct 2018 17:10:23 +0200 To: henrik@levkowetz.com, xml2rfc-dev@ietf.org References: From: Julian Reschke Message-ID: Date: Mon, 8 Oct 2018 17:10:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:2dcU3BMM1jBdNdWBGgnDnz4z6B+XaaJsqJq6W58yDGnPfj3r7kV raNyZ2Ix1f93sIgRp6uXkvP41Tci+f8jKv6K1Szsir/Ml4N8OnYtUppfpvHC4wQVcolNSPo opCRNWhkWX1tAuUJHfM88FRCN4XjUyfeTsrtMXgKw0Lh5iBSCS5vtE02UL4TZJ0KeeCwT0z lAGnaj+xheL8PXykSnZvw== X-UI-Out-Filterresults: notjunk:1;V01:K0:4XLO7BU9+Hk=:adKH2gmDAO40CMHKKFhuKp 1oM9S3YQk36kfdolgCEkInwL1AQtGtu1liDuQ2Aym3w2z+c3lbqQ4ZSRIpPNWhXkXQvWFHs0N 5sIv4xIGt1kB2Q4NQJCQJt7Fms6eFM7KeNL2Poft4Db7xDBNIuxx63hLrJBeb8AAv1ltpKw/u bn802rCuGQVjp2/8LClSn/27cXqyosFWyvFQcBa5OENHfo1JI0nQwTq3nc9fikYCpxD6/gbn7 ohirn2ltLHaCxxkY6v8Umz2KqvePTHRYTfogtz0LjJhzt8ZAZ9z1nghlZFUFMj9jQ6Tq4CvaT q18rOyHVEJ7zpq4pqYeedNg/hn6b/l8iUo7WVAKwgxsr8mOwxyvWGtCV5Rnqd/uVm0Ec2ehel M1GD2p0Rt69Efj7Clmn+NYIWKW14Ty/z5oP/IVmfJxR8XvfOnDxJhKNinW4hnkdwLc/s0Vosl 4vCDXtgS/gpWi9HnCvqPpwQHxfUFWbXGl5Hqz95U+slrQ6omVfeadQYU9ACSW8Cb9nnpJR5d8 AqKetRTGlsmlm76Ek0nQDH8TZMoPxqrzePCA4aKggfS+L2Bpoc1AWl4zFDOjGH8wZpO+ISWNy 0t5+9sy1sjhu4ytCOFJLYqsMqw15vgnHImuOpJs1WqDNcELm5MzEpzJvzJKd7ssiCukU90kan /yynTIV0SoRtzgC5yKrig+2xPLgxAl1GKWfkcweUvUHXzRSVy0PVx9vKvmGmGa1txigj2klAg 4WLIMUC59TsqQjIV5nmw0YHSrkkOB8FjKO9i4mfZ1AeDh+gYY0/8zVhfsAJw5Wud8MRqaS6LF K74WFNNz14Xki/CK69mLhb2J22BQUDIkMCWRSMlokV50RmNYLU= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #46: Schema Issue, RFC 7991, In Section 2.29,
        • , Mixed Content Model 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 15:10:38 -0000 On 2018-10-08 16:46, henrik@levkowetz.com wrote: > This captures an issue noted during implementation, also described in > https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation#section-3.1.6.2 > > Specification: https://tools.ietf.org/html/rfc7991#section-2.29 > > --- > Mixed Content Model > > The mixed content model for
        • —- either text and inline elements like > sub, sup, bcp14, _or_ ,
            ,
            etc, is non-intuitive and may > be hard for users to keep straight. > > Proposal: Consider simplifying the schema by requiring that text > and inline elements always are placed within a > element. > ... The goal of the current design was to keep simple lists simple, but to *allow* more complex lists. Eliminating the simple form IMHO makes authoring harder,, not easier. Best regards, Julian From nobody Mon Oct 8 08:12:03 2018 Return-Path: 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 29E35130DCE for ; Mon, 8 Oct 2018 08:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 sYj9oVFnxWyR for ; Mon, 8 Oct 2018 08:12:00 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04700130DF0 for ; Mon, 8 Oct 2018 08:11:59 -0700 (PDT) Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MX19U-1gEuzG2tZk-00Vx9s; Mon, 08 Oct 2018 17:11:46 +0200 Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MX19U-1gEuzG2tZk-00Vx9s; Mon, 08 Oct 2018 17:11:46 +0200 To: henrik@levkowetz.com, xml2rfc-dev@ietf.org References: From: Julian Reschke Message-ID: <68a4ded2-792b-e357-564a-69d69fbffb6b@gmx.de> Date: Mon, 8 Oct 2018 17:11:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:6Xe7oCwElnJGcgsUbVLkjy14+7ioH3vcePIfqkLACaC5OwrfHqU X+vwW5PLY3ZFtiuNvkm1jh58r5hKWRRetpFV9uQX+efJawFKVS974tFElJg8fotq6nCCIxV je8qquvq+CfvCkcYJZSd7HKh8QSyvOSKbqNAk4htHWIMT3rtphzn17cY6DQlkA2DImd5sXw Xz/LSvSKMV72KVgK/Y27g== X-UI-Out-Filterresults: notjunk:1;V01:K0:RhsLyGs1yG8=:gUwuqgEU+3G16JufCb/SLO XS4+yHN7eTi+LoIg3gASNbeFMgHg2Knc6cGLYQuGXdmHXRIIckmzo7HIno1+oQMwPzw4jdVIo +jkibntGKmNTg/fUe2ak8aZ1H82JGhUzlPwFCpDR+XYnak1MrvxwWMSoO2D6ex6sWejOwW3FR 3HvT+UMFiFsAE8NlJLr0gFlTZn9F1e+nghIYD4qPDYVqnmNIjWOONl6YUBlljd52ykr55Jovd 0F2pofwuEaMGknE41VdhC0Hyjeh1tDKUIZd1wE3cxCoghv9RCLqykEBmh+xBnNRg5gjjrUkt9 3HGsjsborGr707jHu+Phl0xkWKIggsntUaWrcfJLSjGo5Ne1NTg62slL2+ImyALKAsehxY8aj bBCK8K7xNhhx5ah8erlYxxKGttO7H01T+PcZWKso/b1MqgeCcnmDxChIbW1P3C9LV6mWgB+6s F1fuBSwgp8oir569+XN3HhTwBY7/sLJjeTQ7o7gV7JzkmiwKNsoUJHwGlpr5y6+YxrjxJDqhT IXx9jLfO8JDfSY1Zn6lFJdm00XGQjM9cTIT2HkVty+2kHkROV00DnNeFZa60GBcsByZGCs4KC 5ToFoB1zYDZiMMcia6rJk5UQInx1OXcCO23/SqfivHX7PaScGeGM9zAf6rJ2Gv+62dsSA31nc 83IvxTf9ZQJj6shiJC/QmM9Cq4Ay2rd9AUn4gEAHhLeW5BJ6IBaeyumIYe0LGEMgy1B/Xbke9 6SbqkbYwBl/iyi0o/7t7LuYaaP1HulgcyfP2TlHrdepZ4EYgDnZ9rVnjfrGEGcUCZylP1tVS3 zIwxv5VwU69z73cHIG3SJUKlw/pWi/F/QjsFt1A3T74xYoiWq0= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #47: Schema Issue, RFC 7991, In Section 2.32, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 15:12:02 -0000 On 2018-10-08 16:46, henrik@levkowetz.com wrote: > This captures an issue noted during implementation, also described in > https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation#section-3.1.7 > > Specification: https://tools.ietf.org/html/rfc7991#section-2.32 > > --- > In Section 2.32, > > So the element can contain text or , and can contain > other markup like and etc., but why cannot contain > etc. directly? > > Proposal: Change the element schema to permit all inline > elements that can contain, in addition to . > --- +1 in general (but we should double-check that none of the additional elements will cause weirdness in titles...) Best regards, Julian From nobody Mon Oct 8 08:21:22 2018 Return-Path: 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 8CC2B130DEC for ; Mon, 8 Oct 2018 08:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 HFT-EXLA7JTt for ; Mon, 8 Oct 2018 08:21:18 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0B53130E01 for ; Mon, 8 Oct 2018 08:21:17 -0700 (PDT) Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MEWxh-1ftopA1qcz-00FnmT; Mon, 08 Oct 2018 17:21:01 +0200 Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MEWxh-1ftopA1qcz-00FnmT; Mon, 08 Oct 2018 17:21:01 +0200 To: henrik@levkowetz.com, xml2rfc-dev@ietf.org References: From: Julian Reschke Message-ID: Date: Mon, 8 Oct 2018 17:21:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:PEej9g6f/K8HlFgiojkIrtjs6KgKNVZiV8o+5BH2sve4KptPmKA 9gXyANZ+tFaw6tSoFRp69tIC2r7RdjXpE4Bta2NMtapza/z7GWYsKna+MirMs2XYyHhAyuQ p6Vf2qCGSHBw7JNwdO8N9PSc1WEP4K8NakbmszYVq1cskwT4zZ8hElyVD4KY7C7fAdgouy5 gFMFIQ49KVuikP1GT3N2w== X-UI-Out-Filterresults: notjunk:1;V01:K0:1ektOqwrYyk=:CaXPwbtjvGjeVWB3vvoOev DGa3kyP+QZpFXd8mYv76sckMqD7DtnrhdyvNpAOkgRwHMlkBS439lAGXl3Cg3tIOTfVFaLuKr N8aOtfITvsSVW6d8eVIVwdSmsbBIq2MeTNaPuJeJUKXhqRENfbM+OzylxOtBpgHR5NH0r5Fo/ pl8sj7lbxusdalmNj5rMVr0gK8G+t5lrr1F91L9I/8wcRaF/7DeAhRO6RZz0YTgNcmt9emjWN y7e9zZo+t610j10nCmGE2bzEvT7CjB5Mi9ZpHs+ZHHTLPYlZ7gGgPrLCBrgFpbB2YCO2ODvkP uWzBWWavnUeyfhn/btJvi4lbrfYOV7hgMu+0xHKFFaFWCw8zG5BU5XmmqLH1VCI0DFe8xbXOE 39kGsjzdDkLLDFO2mHDNVvn1a3rNsfsRul6Vee8v4RH+KGhSA4tGyDDlWAk6HDm3CFW40frcs 7IYzx7TXjLii47KqvbqiVy7WzmUPTWGInxnv7C83F+a1wk0ZPzPVSJMsgMem1qI632skUGFSS TFuaeUEBn7JoQhIo+tAh9ZhTJAUukeHVwUujHXK8BwHmZANyMgs1upOt5UedXJdXEYvM+pGxO PZIv+tvrbe3/fTVJthiOHBMDtXteklnoLFQN1hDHiubNJA0lOKYX+zo6zVZ+Ip+18JQhuZ00e 73GAwYnf/Z8m0a3nMfMVNrokbI8ZZdjlafdS68BE5U3bxp6+BHBlLJmSWmD26KWuDzEmQem0D MdB8ndZsIn2LmQMGHiKfsgplDkq5TiXK1oHheUaY5/WoBy5MTRQ0FdYsEZ82oDN04SxkPxozy 5mXv0hcSx98k1Ayh/efSWaOd9RiG/iZ9BjEgKgvBNAqSUAmnrI= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 15:21:21 -0000 On 2018-10-08 16:47, henrik@levkowetz.com wrote: > This captures an issue noted during implementation, also described in > https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation#section-3.1.8 > > Specification: https://tools.ietf.org/html/rfc7991#section-2.40.2 > > --- > In Section 2.40.2, "quoteTitle" > > The version two xml2rfc processors already support the attribute "quote- > title". The attribute name change introduces an incompatibility. This > in particular impacts existing bibxml reference files, which should work > with both version 2 and 3 vocabulary documents. This is an interesting point which we really should discuss first and separately, as it also affects "seriesInfo", which is a much bigger change. That said, this is not an incompatibility. It's awkward if you need to support both, yes. That said, it's not in RFC 7791, so apparently it slipped into xml2rfc between v2 and v3. I see it used in the XML sources of ca. 10 RFCs. FWIW, the reason why we switched to camel case was consistency with other attributes. > ... Best regards, Julian From nobody Mon Oct 8 08:25:35 2018 Return-Path: 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 1CD23130E0A for ; Mon, 8 Oct 2018 08:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 iD4mBBQYTl0j for ; Mon, 8 Oct 2018 08:25:32 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CC3E130E01 for ; Mon, 8 Oct 2018 08:25:31 -0700 (PDT) Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M2FhY-1ft6Py10Jo-00s8RT; Mon, 08 Oct 2018 17:25:18 +0200 Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M2FhY-1ft6Py10Jo-00s8RT; Mon, 08 Oct 2018 17:25:18 +0200 To: henrik@levkowetz.com, xml2rfc-dev@ietf.org References: From: Julian Reschke Message-ID: Date: Mon, 8 Oct 2018 17:25:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:oQbZULVUJm6cESOecxqLpjk49wR3rOzNk2+swyQfroscckOH4fg HccKYptSJ4hLF+i+RwPUfCCV1u9eKmEbLPl5KdUAZFOyq+IJ9wooX3TyKpR7czQzGxox5A+ FG2+A2VXOoIuVcUjal2sjI5VcWTljd1hXemAXFA6up7QoqdqN28M18tRmUfUzGEUb8c4Zx4 EmFGUiS62Z1ccKLLC5Y5g== X-UI-Out-Filterresults: notjunk:1;V01:K0:/RM/w1A10Ic=:kMuPzPhCSJ+kl7okrfnR5F B9kM7Fiah05w1ZPN9t589KF+b/drIINPW7aeOp6cspoSpGKNInQFLPHAzQ/wd6SnWthIzFl6h 55KUU2ZIXsXjRdWr5lGC2lyPbvsjc4/2zVdGq3+rWmNTZ+YDHObNyvnMA8zTLkurZGrIao7ae pbkqmMy+qNRKwfyikgFBGX7IKnA4P6mLfiJNxcUyvLW0GbPMeqcsMOYWoOEBXqjkPe1Dr54UI yYCBnKOuO9uzKOa6RnENlKOpk1ntW+ZNI/GqbOSFXAs9Ofb19PGjowvlHWxNaZSJ/77TOvbJI e4bg7SyOB2t8A3j6doa8990pzq7zj4ELEW0JsSP9FbkqsY5/4FGlRSNq6xqWHlfJy3YyEoFiH i4v5sQS9bt5Enu/UcK7iP0kLfG3jAtZ3iHKBttjR8Wr+iG+8QIxJQF9eczk/Lf+lzoSNzexQ1 im0L1bsg/gFBbYTtxQSjE2dWBAK7MXm7L1ztg1hcRlUc8E7pI89CnLQpp8XXMaQMkytYCjUcw DIa6I5SqAXBo16+SHlcm8WBp8Pjl5xxijh5ZGEyXnLfNxHN3SeSzobRoNWLfoZuY7hDVFDAzs lf2SFvL82/012uqrE9xByCpO92V+K0PRHCfDax6JjieU3di9GJ6BSSIwEayZsLSVghD7uTnUx NTIAHe19g8ZBGWghArTO58+cn9t9h3jBIo7jfqbTlO+ZKdFVz+jZy9Ry7tm8PegYUADGrtxSt CmSrNgQ2HToHeJTFzomyFQiL5tCW6bs75ghaiBJpg9bbBc1VGJbch1SaP65LGVKUpU9/RK/tC qecMDy92PGpjZFTsFWf9Gfdt9dYz9Eo95UzRkcEe1MLraYk66E= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 15:25:34 -0000 On 2018-10-08 16:47, henrik@levkowetz.com wrote: > This captures an issue noted during implementation, also described in > https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation#section-3.1.9 > > Specification: https://tools.ietf.org/html/rfc7991#section-2.42 > > --- > In Section 2.42, > > The v3 schema cannot properly model multiple reference subsections > contained within one numbered section. The v2 formatter handled this by > silently inserting an enclosing section, but with the introduction of > the preptool, which in theory should produce a master file from which > various formatters would produce equivalent results, this becomes > troublesome, as the automatic insertion of a container section is > specified for the html formatter, in section 9.8. of RFC 7992, but not > for the text formatter. It would be much better to make the prepped xml ...because essentially nothing is specified for the text formatter - so I do not agree this is a valid argument. IMHO, the output of the text formatter should be equivalent to running the HTML format through an HTML-to-text converter. > explicitly show exactly what should be rendered, and not rely on > formatters silently insert elements. > > Proposal: Update the schema to make it possible for > to contain , and have the prepped xml > explicitly show both the encapsulating section and the > subsections. > ... Not convinced, because: 1) It hasn't been an issue up until now, and 2) allowing to contain creates a new nesting issue. Best regards, Julian From nobody Mon Oct 8 08:44:14 2018 Return-Path: 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 D06CE130E22 for ; Mon, 8 Oct 2018 08:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ptTC1jt62333 for ; Mon, 8 Oct 2018 08:44:09 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2430130E01 for ; Mon, 8 Oct 2018 08:44:09 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:50700 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g9XhX-0002sa-S0; Mon, 08 Oct 2018 08:44:08 -0700 To: Julian Reschke , xml2rfc-dev@ietf.org References: From: Henrik Levkowetz Message-ID: <02650818-d90c-af91-27e4-d0a9ce18d1d3@levkowetz.com> Date: Mon, 8 Oct 2018 17:44:00 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="b7KRdHdjJ37ikVXr0Nha1k3rtom7lkRxg" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #45: Schema Issue, RFC 7991, In Section 2.29,
          • , Unordered lists with arbitrary symbols 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 15:44:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --b7KRdHdjJ37ikVXr0Nha1k3rtom7lkRxg Content-Type: multipart/mixed; boundary="jgWIMMRMfuWLT3vhU20GDroqEaHvKvp3o"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , xml2rfc-dev@ietf.org Message-ID: <02650818-d90c-af91-27e4-d0a9ce18d1d3@levkowetz.com> Subject: Re: [xml2rfc-dev] RFC 7991 issue #45: Schema Issue, RFC 7991, In Section 2.29,
          • , Unordered lists with arbitrary symbols References: In-Reply-To: --jgWIMMRMfuWLT3vhU20GDroqEaHvKvp3o Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Julian, On 2018-10-08 17:08, Julian Reschke wrote: > On 2018-10-08 16:46, henrik@levkowetz.com wrote: >> This captures an issue noted during implementation, also described in >> https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation#= section-3.1.6.1 >>=20 >> Specification: https://tools.ietf.org/html/rfc7991#section-2.29 >>=20 >> --- >> Unordered lists with arbitrary symbols >>=20 >> When
          • is used with
              , the rendering is under= - >> specified (the specification says 'no label will be shown", but do= esn't >> say whether list indentation (leading white-space) should be elimi= nated >> or not. >=20 > Well, rendering in general is not well specified. In particular not for= =20 > plain text output. For HTML it mainly depends on the CSS, which is=20 > essentially configurable and outside the scope of the language definiti= on. Understood, but it's still a good thing if there's some consistency to th= is, so in some cases guidance on indentation might be warranted. >> If the intention is to make it possible to render unordered lists = with >> arbitrary symbols, chosen on a per-list-item basis, the current >> attributes of
            • are insufficient to indent and line-wrap list i= tems >> properly with
                . >=20 > No, that was not the intent. Ok. >> It is not possible, for instance, to use
                  lists to generate XM= L for >> a table of content, since if the width of the bullet (the section >> number, in this case) is unknown, the proper indentation and line >> wrapping cannot be determined. >=20 > I understand that you'd like the vocabulary to do extra as intermediate= =20 > format inside your implementation. That's your design choice, but it=20 > doesn't need to affect the user-visible vocabulary. For instance, you=20 > can implement whatever you need to augment the XML in a separate XML=20 > namespace. Ok. There's more to it than this, but that will appear as a separate issue. >=20 >> Proposal: Add an explicit "bullet" attribute to support thi= s use >> case. >>=20 >> Implementation: None in the current version of xml2rfc, but inter= nally >> bullets are taken a configurable bullet list, so >> accommodating such an attribute would be trivial.= >> --- >=20 > -1, for the above reasons. >=20 > That said, I'm not against having unordered lists with custom symbols, = > but the way you arrived at this proposal doesn't work for me. Understood. Would you like to make a separate proposal (with a more generic argument, I assume) for unordered lists with custom symbols? Best regards, Henrik --jgWIMMRMfuWLT3vhU20GDroqEaHvKvp3o-- --b7KRdHdjJ37ikVXr0Nha1k3rtom7lkRxg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu7e0AACgkQTptXS4+7 FxruhhAAvTrrH5oU6w3joQku5s4ePlk62P5lylgQYGOsnVzUm2ZfbsaJ0f1GiXGz KYw397UOLM1hAeCZdSKqwB2OaQH/t9itVs0N8A1IYwV/2OmrC5lcw+JV2v07aHvq b7MzLCpRk4R4Uf2MUwGafOyciRJEDrtHoKdYEucVKfzwmdG8G9aGyEiqo6WHl+HZ wk+5oXbltNhTK5jmCAJT8Duyyc7pfMkWpvvg0Bth57GUMQx7UHYDMgXIp4jB7KcW MRXaf5P+QGl5idb0MLaWpHcV5rxw7HksV+nv46G6z80xhYL/qBZOza8WdKNCq6oK zxpQPPw4O7b9EFtJa5++rQTCkjLUoO0KPDfkqeL7EwOGRb4htHuODBT15cJD/+0h EvNrjhYS/ZRZTCUoWn7UfdSCvwdo6MYBw01PiaKo+TauZEKNp4ulhF4E4L8ff0B+ BcfePQFG7kqb1sxTfQJ6QBoxrE6g48d1CIkIVPtBIOjU6QTAyiLD4JRLUAvV55kG 6V65KFs1uGKw77BzM+JhRZC3OvYqaOaraoVzT4cDi1KGEDSpTUDmvwiMdtSFN25R QwXonD6hJw5TUsUqRk9TnqY+KSRc8lr0SvDYkcTk19/eg5LW3j/Yn/WGr7AWxTDx XJPx8Q2kLPH7ICYNfJrTAONZrnQCI8EFC6J5LliMbLqQsmGRQoU= =+dQp -----END PGP SIGNATURE----- --b7KRdHdjJ37ikVXr0Nha1k3rtom7lkRxg-- From nobody Mon Oct 8 08:46:40 2018 Return-Path: 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 57EC6130E27 for ; Mon, 8 Oct 2018 08:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 vktoJ-CvLMv9 for ; Mon, 8 Oct 2018 08:46:36 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AAC6130E01 for ; Mon, 8 Oct 2018 08:46:36 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:50714 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g9Xjn-0002N9-MJ; Mon, 08 Oct 2018 08:46:34 -0700 To: Julian Reschke , xml2rfc-dev@ietf.org References: From: Henrik Levkowetz Message-ID: Date: Mon, 8 Oct 2018 17:46:18 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Ex57O7LnHasvxW56rTfWIvA2VxUBTHu3u" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #46: Schema Issue, RFC 7991, In Section 2.29,
                • , Mixed Content Model 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 15:46:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ex57O7LnHasvxW56rTfWIvA2VxUBTHu3u Content-Type: multipart/mixed; boundary="uQSuwOHHDcTIf4hlwNEdiClQV7qoBxbT1"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , xml2rfc-dev@ietf.org Message-ID: Subject: Re: [xml2rfc-dev] RFC 7991 issue #46: Schema Issue, RFC 7991, In Section 2.29,
                • , Mixed Content Model References: In-Reply-To: --uQSuwOHHDcTIf4hlwNEdiClQV7qoBxbT1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Julian, On 2018-10-08 17:10, Julian Reschke wrote: > On 2018-10-08 16:46, henrik@levkowetz.com wrote: >> This captures an issue noted during implementation, also described in >> https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation#= section-3.1.6.2 >>=20 >> Specification: https://tools.ietf.org/html/rfc7991#section-2.29 >>=20 >> --- >> Mixed Content Model >>=20 >> The mixed content model for
                • =E2=80=94- either text and inline= elements like >> sub, sup, bcp14, _or_ ,
                    ,
                    etc, is non-intuitive an= d may >> be hard for users to keep straight. >>=20 >> Proposal: Consider simplifying the schema by requiring that= text >> and inline elements always are placed within a >> element. >> ... >=20 > The goal of the current design was to keep simple lists simple, but to = > *allow* more complex lists. >=20 > Eliminating the simple form IMHO makes authoring harder,, not easier. Understood. I think a distinction could be that it's maybe easier to wor= k, with once understood, but also maybe harder to grasp. It would be good to hear thoughts on this from people who are users but w= ere not part of the design team, also. Best regards, Henrik --uQSuwOHHDcTIf4hlwNEdiClQV7qoBxbT1-- --Ex57O7LnHasvxW56rTfWIvA2VxUBTHu3u Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu7e8oACgkQTptXS4+7 FxrEFBAAyEmyNhTDUl9e9xQmPaxl8WfSEUhhnqTZMJGii5I+YEKs1g2KDQTN3GYS dXwDckJKjErnxPkhLf6b3pvi7A1JPSP4N/gDnsjxcOlggFCfrAxW72PM95kbTAev CqBf7e4qyosqtgj2cgJ/kZIwAAVDXjb6jqUzdo6IrU2tKiuqxf/XXp9cmfptZhDZ PAEw6fNDVqrc8TIzRSskIHc1tlI9BBJ+WGvzjIunf64JYZmBRV26iqwUKDpiO9t5 uehG25NrGeeibwLOWtrxgwx6jF0fxNyrVxcpcDsb/RusPqjci+3H9/aFQeGNYjhf beH6TzkL73B9qD69191QV85mBsGUHVeH6n6WPwr7aVAE782Dlw3lAu9BxzJTM48y zbfQm1yeZbWv+7RWpHyqelTosxBRcxBE7uRRyvv0cwn5lwiaeXiUxV4IHIMT0WXK h39+xHnb0GuBcLYXBurl3u6U6ZicRd09oSzP9Ud6RQUUT/Q80qf5HLATEeELuDbp 3JxwAtNgBfBNupcWzH5zTxlpNufYp4Yp5THCLhWzH0GIKg6Ps+VsCCTXXpgp4k6w ooEVFcSEUEt7q+a4iaoY8UlNYys7nMzcrwY5HLJBVYBi4cFn3HOIP9z8NiAJegZM 2cWi87PIi/1rJW1JMcd9KgvDrEq9gRUYKqsS1juI0L8abHjum0k= =B/vK -----END PGP SIGNATURE----- --Ex57O7LnHasvxW56rTfWIvA2VxUBTHu3u-- From nobody Mon Oct 8 08:52:25 2018 Return-Path: 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 89266130E25 for ; Mon, 8 Oct 2018 08:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 AoWq3X_I8uFF for ; Mon, 8 Oct 2018 08:52:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEA70130E22 for ; Mon, 8 Oct 2018 08:52:20 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:50743 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g9XpT-000728-Qj; Mon, 08 Oct 2018 08:52:20 -0700 To: Julian Reschke , xml2rfc-dev@ietf.org References: <68a4ded2-792b-e357-564a-69d69fbffb6b@gmx.de> From: Henrik Levkowetz Message-ID: <50bc63c1-c910-3e9c-2c3f-45fe7dc8af7d@levkowetz.com> Date: Mon, 8 Oct 2018 17:52:12 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <68a4ded2-792b-e357-564a-69d69fbffb6b@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QH3BoR1h8cOiTn3i7k32jOEd1CbBDjdjU" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #47: Schema Issue, RFC 7991, In Section 2.32, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 15:52:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QH3BoR1h8cOiTn3i7k32jOEd1CbBDjdjU Content-Type: multipart/mixed; boundary="0qsQHaT9IOdeuWEFSbCSsEL0i9nQR7FGM"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , xml2rfc-dev@ietf.org Message-ID: <50bc63c1-c910-3e9c-2c3f-45fe7dc8af7d@levkowetz.com> Subject: Re: [xml2rfc-dev] RFC 7991 issue #47: Schema Issue, RFC 7991, In Section 2.32, References: <68a4ded2-792b-e357-564a-69d69fbffb6b@gmx.de> In-Reply-To: <68a4ded2-792b-e357-564a-69d69fbffb6b@gmx.de> --0qsQHaT9IOdeuWEFSbCSsEL0i9nQR7FGM Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Julian, On 2018-10-08 17:11, Julian Reschke wrote: > On 2018-10-08 16:46, henrik@levkowetz.com wrote: >> This captures an issue noted during implementation, also described in >> https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation#= section-3.1.7 >>=20 >> Specification: https://tools.ietf.org/html/rfc7991#section-2.32 >>=20 >> --- >> In Section 2.32, >>=20 >> So the element can contain text or , and can conta= in >> other markup like and etc., but why cannot cont= ain >> etc. directly? >>=20 >> Proposal: Change the element schema to permit all in= line >> elements that can contain, in addition to . >> --- >=20 > +1 in general (but we should double-check that none of the additional=20 > elements will cause weirdness in titles...) Would not that already be an issue if one of the elements that would be used directly within with this change were used within within= with the earlier schema? Best regards, Henrik --0qsQHaT9IOdeuWEFSbCSsEL0i9nQR7FGM-- --QH3BoR1h8cOiTn3i7k32jOEd1CbBDjdjU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu7fSwACgkQTptXS4+7 FxqTiA//cmh6ksrgxXr4DPHJTct2jnzRqxWa/TN+ywa9wXOvscGHgEeDUxkcFYcQ cJqZzjtPWWw97CnquQUvUOi90GlU0N8eRkqPtuc3e2git9uB9yCWKG1S9s4U4H0Q SkALK0ndIa0zVWURQnbiqndvYzgpc+YIdPOGrWYXbsMoe1iTvjEDT/aC/2M1SjSD zAgRXpJ8Km+rS2noeyEOlBuj8uOF9Kn4ql3+qXDeIWmj/oupDRJluKl816CC0bUc jTxtCcNb/XN3K0xcAixdzCPQJZz7E4ZMYuhFDuo2YrZNDgA1BlUSPd/T1BcxhiZM ObhmriJkN8f6/Hz2mwoxZdwdo2zNsCZ30zgTiP0xPnRjJCOPXvOpjQWqDiCCyAGc OB+r2p+/t0hqIP88Xawf/QA/W0AlRXkqhluOJmsbJ1bqX36fUkHUVXyQI/dLcO/x JuWeUyqy+fjXsEVVaFkB7Y+vY4+Yfeqb+QA43+vlmV46BKaMvYxPS9xNwtnWcBkO D/r+/mzGDzyN2V6J2KBHbuq5AWxBwYI3MGWtJd0IWGqumh+Mlg58WrGbewCWfCjI WGuR1yJ5OQN5v8HnDAjLQ5RYXFI48a6KE/tbdR4EbO6FxSa10T7KADCCcqk61FDe G/jgKI7n9tTukzqeaOBe0IjnAS5q9dON0JynWunPfVQwmKJxTQs= =C2eY -----END PGP SIGNATURE----- --QH3BoR1h8cOiTn3i7k32jOEd1CbBDjdjU-- From nobody Mon Oct 8 09:01:50 2018 Return-Path: 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 6D2ED130E7C for ; Mon, 8 Oct 2018 09:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Rn0Rt6oj6Rlk for ; Mon, 8 Oct 2018 09:01:41 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA4E6130E28 for ; Mon, 8 Oct 2018 09:01:41 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:50778 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g9XyW-0005kh-Mg; Mon, 08 Oct 2018 09:01:41 -0700 To: Julian Reschke , xml2rfc-dev@ietf.org References: From: Henrik Levkowetz Message-ID: Date: Mon, 8 Oct 2018 18:01:33 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bAUAMcJ3Vi2JwuPh0ivRBQWiJl5IhTg1D" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 16:01:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bAUAMcJ3Vi2JwuPh0ivRBQWiJl5IhTg1D Content-Type: multipart/mixed; boundary="FCalqbsUCPFI7k36oGUjnJKNpBn43c1nx"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , xml2rfc-dev@ietf.org Message-ID: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, References: In-Reply-To: --FCalqbsUCPFI7k36oGUjnJKNpBn43c1nx Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Julian, On 2018-10-08 17:25, Julian Reschke wrote: > On 2018-10-08 16:47, henrik@levkowetz.com wrote: >> This captures an issue noted during implementation, also described in >> https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation#= section-3.1.9 >>=20 >> Specification: https://tools.ietf.org/html/rfc7991#section-2.42 >>=20 >> --- >> In Section 2.42, >>=20 >> The v3 schema cannot properly model multiple reference subsections= >> contained within one numbered section. The v2 formatter handled t= his by >> silently inserting an enclosing section, but with the introduction= of >> the preptool, which in theory should produce a master file from wh= ich >> various formatters would produce equivalent results, this becomes >> troublesome, as the automatic insertion of a container section is >> specified for the html formatter, in section 9.8. of RFC 7992, but= not >> for the text formatter. It would be much better to make the prepp= ed xml >=20 > ...because essentially nothing is specified for the text formatter - so= =20 > I do not agree this is a valid argument. >=20 > IMHO, the output of the text formatter should be equivalent to running = > the HTML format through an HTML-to-text converter. I can understand this viewpoint; I haven't actually tried this, so have no particular viewpoint on how feasible that would be. However, this is still an issue, even if we disregard the text vs. html specification part. >=20 >> explicitly show exactly what should be rendered, and not rely on >> formatters silently insert elements. >> >> Proposal: Update the schema to make it possible for >> to contain , and have the prepped xml= >> explicitly show both the encapsulating section an= d the >> subsections. >> ... >=20 > Not convinced, because: >=20 > 1) It hasn't been an issue up until now, and So the reason it has not been an issue up to now is because the formatter= s have been doing 'magic'. The introduction of a normative xml format make= s that problematic. I believe that the output of the preptool should ideal= ly not leave it up to the formatters to do any magic at all; the content sho= uld fully and completely specify what would go into a formatted output. This= is the underlying issue I see here; apologies if I haven't expressed it well= =2E > 2) allowing to contain creates a new nesting = > issue. In that case, I think I'd be just as happy with having the contain= a
                    that would hold the two . Best regards, Henrik --FCalqbsUCPFI7k36oGUjnJKNpBn43c1nx-- --bAUAMcJ3Vi2JwuPh0ivRBQWiJl5IhTg1D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu7f10ACgkQTptXS4+7 FxqI1w//aqfIc8S+txVUNoDC0nRKzR3jRl2lIPq69E2MOsjeI4o11zdcaRXPyG+v qy9UZ9cPH8N9O8ClOhjQIVdAD6k9uVegu+8Mula0WCB0QxIWWeJNLSqA0ZV9s7g6 aDOhhmnA7n5BFYRKUM2YTAlNz1kBJGQ2FhejGhiyGm4Xkw/OnYil9tzgmYYctcGC 7cyptdli2h2wewZwPL9UFwAZlBocgjAs82iDuuwz9raBGh/LIc9ZexN6a2ni9puv iPBNKdBFmY2gt7rubE2N5mnaMmPwC8e+0oNgdz8WbDC8dA43LxovWwMZpEu1Pzfv nUQh3pcLOr8pXHGMURcCBqo+iS6OQWy80EsacPqOQdMfSodU70LspKGbOrz6Ixko Asy+PfXvVbuIOqzD+WoyCcH7NIvoAKc9Nok28BG19DC1fj4sJ3b3nZQ+Re1byFnF RFenUwPDmF6Fd+WvITxm5MKpB0NGkbJxTxBf8oHURX2aKiixPdW9jDej4zeKWxXL VxYYlf704Gad1z1CtntgpGQwxCqQTwn8VBJSpVG9vOGESUjguP1xAb4YpBnRa/79 KbnbVbIPSPiC3ZPgf9cj+7AcIyCRNc0jzYGV/olp4f9PJ2aMggT0h1dgxwd+/LyQ lzFvUpZOAb4wGkk8xXt/CABnhUX9FL9gcEgBhqFYcfd360QgxlY= =uILa -----END PGP SIGNATURE----- --bAUAMcJ3Vi2JwuPh0ivRBQWiJl5IhTg1D-- From nobody Mon Oct 8 09:40:48 2018 Return-Path: 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 0BB8C129BBF for ; Mon, 8 Oct 2018 09:40:46 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 dQdU4U0WwgKw for ; Mon, 8 Oct 2018 09:40:43 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74B991286E3 for ; Mon, 8 Oct 2018 09:40:43 -0700 (PDT) Received: from Jude (192.168.0.11) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 8 Oct 2018 09:35:58 -0700 From: Jim Schaad To: 'Julian Reschke' , , References: In-Reply-To: Date: Mon, 8 Oct 2018 09:40:32 -0700 Message-ID: <061301d45f25$a333d9e0$e99b8da0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLsbhbghawLf5Gn5PB1ZTH9RRSghAEfEY14otx2QzA= Content-Language: en-us X-Originating-IP: [192.168.0.11] Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #46: Schema Issue, RFC 7991, In Section 2.29,
                  • , Mixed Content Model 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 16:40:46 -0000 > -----Original Message----- > From: xml2rfc-dev On Behalf Of Julian > Reschke > Sent: Monday, October 8, 2018 8:10 AM > To: henrik@levkowetz.com; xml2rfc-dev@ietf.org > Subject: Re: [xml2rfc-dev] RFC 7991 issue #46: Schema Issue, RFC 7991, = In > Section 2.29,
                  • , Mixed Content Model >=20 > On 2018-10-08 16:46, henrik@levkowetz.com wrote: > > This captures an issue noted during implementation, also described = in > > https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3- > implementation#section-3.1.6.2 > > > > Specification: https://tools.ietf.org/html/rfc7991#section-2.29 > > > > --- > > Mixed Content Model > > > > The mixed content model for
                  • =E2=80=94- either text and = inline elements like > > sub, sup, bcp14, _or_ ,
                      ,
                      etc, is non-intuitive = and may > > be hard for users to keep straight. > > > > Proposal: Consider simplifying the schema by requiring = that text > > and inline elements always are placed within a = > > element. > > ... >=20 > The goal of the current design was to keep simple lists simple, but to > *allow* more complex lists. >=20 > Eliminating the simple form IMHO makes authoring harder,, not easier. I am neutral on this one. I don't think that it really makes things = either easier or harder by having or not having the required = element. I would say keep things as they are until it is proven that = this is a problem. Jim >=20 > Best regards, Julian >=20 > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc-dev From nobody Mon Oct 8 09:41:34 2018 Return-Path: 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 00C69129BBF for ; Mon, 8 Oct 2018 09:41:33 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Rned88ko0a1f for ; Mon, 8 Oct 2018 09:41:31 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAE0E1286E3 for ; Mon, 8 Oct 2018 09:41:30 -0700 (PDT) Received: from Jude (192.168.0.11) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 8 Oct 2018 09:36:48 -0700 From: Jim Schaad To: 'Julian Reschke' , , References: <68a4ded2-792b-e357-564a-69d69fbffb6b@gmx.de> In-Reply-To: <68a4ded2-792b-e357-564a-69d69fbffb6b@gmx.de> Date: Mon, 8 Oct 2018 09:41:23 -0700 Message-ID: <061401d45f25$c186e9a0$4494bce0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGRA9mIRg6clGMqw83DGmEMB7/GegHOB73apY3TgnA= Content-Language: en-us X-Originating-IP: [192.168.0.11] Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #47: Schema Issue, RFC 7991, In Section 2.32, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 16:41:33 -0000 > -----Original Message----- > From: xml2rfc-dev On Behalf Of Julian > Reschke > Sent: Monday, October 8, 2018 8:12 AM > To: henrik@levkowetz.com; xml2rfc-dev@ietf.org > Subject: Re: [xml2rfc-dev] RFC 7991 issue #47: Schema Issue, RFC 7991, In > Section 2.32, > > On 2018-10-08 16:46, henrik@levkowetz.com wrote: > > This captures an issue noted during implementation, also described in > > https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3- > implementation#section-3.1.7 > > > > Specification: https://tools.ietf.org/html/rfc7991#section-2.32 > > > > --- > > In Section 2.32, > > > > So the element can contain text or , and can contain > > other markup like and etc., but why cannot contain > > etc. directly? > > > > Proposal: Change the element schema to permit all inline > > elements that can contain, in addition to . > > --- > > +1 in general (but we should double-check that none of the additional > elements will cause weirdness in titles...) > +1 Jim > Best regards, Julian > > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc-dev From nobody Mon Oct 8 10:19:00 2018 Return-Path: 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 19A3E130EDD for ; Mon, 8 Oct 2018 10:18:58 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 1QgSDs8pqbhy for ; Mon, 8 Oct 2018 10:18:55 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39EF9130E5A for ; Mon, 8 Oct 2018 10:17:25 -0700 (PDT) Received: from Jude (192.168.0.11) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 8 Oct 2018 10:12:20 -0700 From: Jim Schaad To: 'Henrik Levkowetz' , 'Julian Reschke' , References: In-Reply-To: Date: Mon, 8 Oct 2018 10:16:55 -0700 Message-ID: <062501d45f2a$b8220750$286615f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKMgMAK0VYejNR5SBI3Ju6yzqYpwAJgfmWrAYJ4yUajhjrAwA== Content-Language: en-us X-Originating-IP: [192.168.0.11] Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 17:18:58 -0000 > -----Original Message----- > From: xml2rfc-dev On Behalf Of Henrik > Levkowetz > Sent: Monday, October 8, 2018 9:02 AM > To: Julian Reschke ; xml2rfc-dev@ietf.org > Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, = In > Section 2.42, >=20 > Hi Julian, >=20 > On 2018-10-08 17:25, Julian Reschke wrote: > > On 2018-10-08 16:47, henrik@levkowetz.com wrote: > >> This captures an issue noted during implementation, also described = in > >> = https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation > >> #section-3.1.9 > >> > >> Specification: https://tools.ietf.org/html/rfc7991#section-2.42 > >> > >> --- > >> In Section 2.42, > >> > >> The v3 schema cannot properly model multiple reference = subsections > >> contained within one numbered section. The v2 formatter = handled this by > >> silently inserting an enclosing section, but with the = introduction of > >> the preptool, which in theory should produce a master file from = which > >> various formatters would produce equivalent results, this = becomes > >> troublesome, as the automatic insertion of a container section = is > >> specified for the html formatter, in section 9.8. of RFC 7992, = but not > >> for the text formatter. It would be much better to make the > >> prepped xml > > > > ...because essentially nothing is specified for the text formatter - > > so I do not agree this is a valid argument. > > > > IMHO, the output of the text formatter should be equivalent to = running > > the HTML format through an HTML-to-text converter. >=20 > I can understand this viewpoint; I haven't actually tried this, so = have no > particular viewpoint on how feasible that would be. >=20 > However, this is still an issue, even if we disregard the text vs. = html > specification part. > > > >> explicitly show exactly what should be rendered, and not rely = on > >> formatters silently insert elements. > >> > >> Proposal: Update the schema to make it possible for = > >> to contain , and have the prepped = xml > >> explicitly show both the encapsulating section = and the > >> subsections. > >> ... > > > > Not convinced, because: > > > > 1) It hasn't been an issue up until now, and >=20 > So the reason it has not been an issue up to now is because the = formatters have > been doing 'magic'. The introduction of a normative xml format makes = that > problematic. I believe that the output of the preptool should ideally = not leave it > up to the formatters to do any magic at all; the content should fully = and > completely specify what would go into a formatted output. This is the > underlying issue I see here; apologies if I haven't expressed it well. I am sympathetic to the idea that the XML file should have the same = structure as any resulting rendering and thus it makes sense to allow = for references to be a child of references. >=20 > > 2) allowing to contain creates a new = nesting > > issue. I don't know that I see what the nesting problem that Julian is talking = about here. While it would be odd to have a three level deep references = tree I don't know that this makes a problem for tooling purposes. I = would expect that the current RPC would reject this as not being of the = correct form. >=20 > In that case, I think I'd be just as happy with having the = contain a >
                      that would hold the two . I think this would be a problem as you could end up with a references = section in the middle of the set of appendixes. Jim >=20 >=20 > Best regards, >=20 > Henrik From nobody Mon Oct 8 10:25:35 2018 Return-Path: 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 75F9B13115F for ; Mon, 8 Oct 2018 10:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 i2915fK3ozUh for ; Mon, 8 Oct 2018 10:25:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CE1A130FDE for ; Mon, 8 Oct 2018 10:21:58 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:51235 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g9ZED-0005SV-96; Mon, 08 Oct 2018 10:21:58 -0700 To: Jim Schaad , 'Julian Reschke' , xml2rfc-dev@ietf.org References: <062501d45f2a$b8220750$286615f0$@augustcellars.com> From: Henrik Levkowetz Message-ID: Date: Mon, 8 Oct 2018 19:21:49 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <062501d45f2a$b8220750$286615f0$@augustcellars.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qNtxbgkGDNgavcmux8tGHDFJH6L622Hv4" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, julian.reschke@gmx.de, ietf@augustcellars.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 17:25:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qNtxbgkGDNgavcmux8tGHDFJH6L622Hv4 Content-Type: multipart/mixed; boundary="Jd8c7IJs8luOXAWR9LWJLcb4MnbGLRiWI"; protected-headers="v1" From: Henrik Levkowetz To: Jim Schaad , 'Julian Reschke' , xml2rfc-dev@ietf.org Message-ID: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, References: <062501d45f2a$b8220750$286615f0$@augustcellars.com> In-Reply-To: <062501d45f2a$b8220750$286615f0$@augustcellars.com> --Jd8c7IJs8luOXAWR9LWJLcb4MnbGLRiWI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jim, Some small comments inline: On 2018-10-08 19:16, Jim Schaad wrote: >=20 >> -----Original Message----- >> From: xml2rfc-dev On Behalf Of Henrik >> Levkowetz >> Sent: Monday, October 8, 2018 9:02 AM >> To: Julian Reschke ; xml2rfc-dev@ietf.org >> Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991,= In >> Section 2.42, >>=20 >> Hi Julian, >>=20 >> On 2018-10-08 17:25, Julian Reschke wrote: >> > On 2018-10-08 16:47, henrik@levkowetz.com wrote: >> >> This captures an issue noted during implementation, also described = in >> >> https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementati= on >> >> #section-3.1.9 >> >> >> >> Specification: https://tools.ietf.org/html/rfc7991#section-2.42 >> >> >> >> --- >> >> In Section 2.42, >> >> >> >> The v3 schema cannot properly model multiple reference subsecti= ons >> >> contained within one numbered section. The v2 formatter handle= d this by >> >> silently inserting an enclosing section, but with the introduct= ion of >> >> the preptool, which in theory should produce a master file from= which >> >> various formatters would produce equivalent results, this becom= es >> >> troublesome, as the automatic insertion of a container section = is >> >> specified for the html formatter, in section 9.8. of RFC 7992, = but not >> >> for the text formatter. It would be much better to make the >> >> prepped xml >> > >> > ...because essentially nothing is specified for the text formatter -= >> > so I do not agree this is a valid argument. >> > >> > IMHO, the output of the text formatter should be equivalent to runni= ng >> > the HTML format through an HTML-to-text converter. >>=20 >> I can understand this viewpoint; I haven't actually tried this, so hav= e no >> particular viewpoint on how feasible that would be. >>=20 >> However, this is still an issue, even if we disregard the text vs. htm= l >> specification part. >> > >> >> explicitly show exactly what should be rendered, and not rely o= n >> >> formatters silently insert elements. >> >> >> >> Proposal: Update the schema to make it possible for >> >> to contain , and have the prepped = xml >> >> explicitly show both the encapsulating section= and the >> >> subsections. >> >> ... >> > >> > Not convinced, because: >> > >> > 1) It hasn't been an issue up until now, and >>=20 >> So the reason it has not been an issue up to now is because the format= ters have >> been doing 'magic'. The introduction of a normative xml format makes = that >> problematic. I believe that the output of the preptool should ideally= not leave it >> up to the formatters to do any magic at all; the content should fully = and >> completely specify what would go into a formatted output. This is the= >> underlying issue I see here; apologies if I haven't expressed it well.= >=20 > I am sympathetic to the idea that the XML file should have the same > structure as any resulting rendering and thus it makes sense to allow > for references to be a child of references. >=20 >>=20 >>> 2) allowing to contain creates a new >>> nesting issue. >=20 > I don't know that I see what the nesting problem that Julian is > talking about here. While it would be odd to have a three level deep > references tree I don't know that this makes a problem for tooling > purposes. I would expect that the current RPC would reject this as > not being of the correct form. I could easily enforce this in the preptool, if it is desired. I have no particular preferences on limiting the nesting depth or not. >> In that case, I think I'd be just as happy with having the >> contain a
                      that would hold the two . >=20 > I think this would be a problem as you could end up with a references > section in the middle of the set of appendixes. Ack. Good point. Henrik --Jd8c7IJs8luOXAWR9LWJLcb4MnbGLRiWI-- --qNtxbgkGDNgavcmux8tGHDFJH6L622Hv4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu7ki0ACgkQTptXS4+7 Fxr8yw//dINX7pDmPqLAOlC7HBAjfIYoBSZuZdLoDO53qEaZSyXjyy1hAYoNjg2V UC5NbLhFf7ZkH1UVsnpjjtiQe16+PHruQQmMYtBc0xC+oWH4W6i+4x7DI23JE7JM QRbxSveJlKbPg50ZXd+5r4s1ncUuGlphyRpg5VgD9eBDHqj8LHEDF4uI/4KhZZxa J9FJ0nFDivff6oldjPSw15j20J3D5IxTeGab23iTAj3tfap4nSg93taZuJEqA/T/ eb0t2+Dh2OWP9GHZhm2RZIuSeIxekBHKyybQ3Ls9T9et6JOkF8MfLyiUpR25ph1K OG2fM+Zu9+EPzoe6ZNm87szcyymObBWzV+ztf/kC5fMgs5CNqSp0o/AuWOcfX6iJ QZeN+pMpvfHYze/CDMx6JdiP80v87hJvNvss/6XmLW04QAyvpqPnyDj/1cEUHRaV YDI0VOj5/nOT7XuC8W8d9gJjWzsfxA4bElbt3lIT0ZR35NTuiVVceNBeyT49iiaX nkIODb6da25A9VXxJfNLy4fCjL54379duh+UjGccGB56Qy9RbBqIql/2DZQj9SN3 ldbWPaLRLV9Pqas+2GDfzZUrLiiFTZe4itMV+RQ8uXhMPe+bK/bpMKHM6S9yei+K NkNt/7uvz3U7/NZW741HJLZK4noBTPn/dV2aPqpF67nwbwcXTvQ= =To15 -----END PGP SIGNATURE----- --qNtxbgkGDNgavcmux8tGHDFJH6L622Hv4-- From nobody Mon Oct 8 10:27:21 2018 Return-Path: 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 2E65F130EA8 for ; Mon, 8 Oct 2018 10:27:19 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 w2sSqqZ9V_jF for ; Mon, 8 Oct 2018 10:27:17 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 514C8130F21 for ; Mon, 8 Oct 2018 10:23:20 -0700 (PDT) Received: from Jude (192.168.0.11) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 8 Oct 2018 10:18:37 -0700 From: Jim Schaad To: 'Julian Reschke' , , References: In-Reply-To: Date: Mon, 8 Oct 2018 10:23:12 -0700 Message-ID: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLAbTej30L1EUF5/gxtYUDerJ/dBAHYXIfkoy65VBA= Content-Language: en-us X-Originating-IP: [192.168.0.11] Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 17:27:20 -0000 > -----Original Message----- > From: xml2rfc-dev On Behalf Of Julian > Reschke > Sent: Monday, October 8, 2018 8:21 AM > To: henrik@levkowetz.com; xml2rfc-dev@ietf.org > Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In > Section 2.40.2, "quoteTitle" > > On 2018-10-08 16:47, henrik@levkowetz.com wrote: > > This captures an issue noted during implementation, also described in > > https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation# > > section-3.1.8 > > > > Specification: https://tools.ietf.org/html/rfc7991#section-2.40.2 > > > > --- > > In Section 2.40.2, "quoteTitle" > > > > The version two xml2rfc processors already support the attribute "quote- > > title". The attribute name change introduces an incompatibility. This > > in particular impacts existing bibxml reference files, which should work > > with both version 2 and 3 vocabulary documents. > > This is an interesting point which we really should discuss first and separately, > as it also affects "seriesInfo", which is a much bigger change. I am not sure that I see what is being said here. Can you give an example? Jim > > That said, this is not an incompatibility. It's awkward if you need to support > both, yes. That said, it's not in RFC 7791, so apparently it slipped into xml2rfc > between v2 and v3. > > I see it used in the XML sources of ca. 10 RFCs. > > FWIW, the reason why we switched to camel case was consistency with other > attributes. > > > ... > > Best regards, Julian > > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc-dev From nobody Mon Oct 8 11:00:22 2018 Return-Path: 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 57C1E130EBC for ; Mon, 8 Oct 2018 11:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 hJrjA-ewEunf for ; Mon, 8 Oct 2018 11:00:18 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AB77131235 for ; Mon, 8 Oct 2018 10:59:53 -0700 (PDT) Received: from [192.168.178.20] ([91.61.62.65]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MIQlv-1g7e890iUR-0047rZ; Mon, 08 Oct 2018 19:59:10 +0200 Received: from [192.168.178.20] ([91.61.62.65]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MIQlv-1g7e890iUR-0047rZ; Mon, 08 Oct 2018 19:59:10 +0200 To: Jim Schaad , henrik@levkowetz.com, xml2rfc-dev@ietf.org References: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> From: Julian Reschke Message-ID: <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> Date: Mon, 8 Oct 2018 19:59:09 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:dljiMq+hL70I4hWQr9bGBKC7Sk1Lv2NAT1UQmN/tSm9tkLPYNuZ uCsK9QFznmlcXTwHFBlZn+Tizd7o1LwAUSeoRqETnysTiwjj05H5wsHjgkJxuZiB7vCz6D3 D/BAUqLAsEobWKnl4fU7p05dxAfBS0EAryPdt93rXwOEoK6C8Ncm3PhxAPNqj8sDpN/931K YLfteAIM2YXMYrBSvtZ+g== X-UI-Out-Filterresults: notjunk:1;V01:K0:DkFWNJNIico=:v3JrJTzaQAlETRA/r7f6zz SJhDBjWxb7Nh6PO+lgtr0x4HBQCBrFpvQ7Ksk5N5RF9yOtCNx4BdeVXVKKJSqzcutho+czXiE ltgFg6etziyQKRt4vWcxyLfkWzhCtg1cmwIsvsdwmHaCL2nqu+OWC6H2OuUjgK6A2yK1kT6EH SEERiZtixICx6UcMoxGuLmI5DrJcXixu7qPLt+i+texBvnGcRrR0Tn/WxZ1C7wDi9R9AEk4b5 F90vX0PLrItLW0GqTP7TDodvIGwFcpHbiMIHMX3HNNYOo+1aMNTqbHYIgmNg4h2j9G9aTmEtW TK7Q+IEqH/v5cLIpZ35qnto/6VIDHddLaVHqJO4gzPl28SFq4ISSqfKLzkfrf+iU8EoDnJgFZ ohb+qmLTW8pZH/9m/o4vJg5lZJ+E1GzU+zhzMHiQf1pD1/II5xzUAFZjpMO7h4bK3pwFPG0LJ A7io0x5sr8P7VAxE72znrN+A6vQMsnLQ+Jtf1S4wVjCwxR4+IOS3V3WwX70WmoK2rq+s+V/NU CPX8ERy5WYVdz2HKAErj+U42QMlwZF03qWqtra8JTXTrYLSEYcfXuO0XLSCVKC/UupZgwFyCF nlsktCZMlrmBKBdCc/Wg2vq0f+BFpt/n3Q476kje/ZluEHmz/+NKu19DsgvfBPtAWA4QqARkk mHVyOgxvTboqKl5T/6IEkXGSYpdu/N+PAUFjLFhMg8U+aoeRKe/PVhPNRCCVCfhMD1Wknvc+v ONkks4JtFWXbzLBAqA2WX6p1elbzEstYK+3SX+Tug2dtfImbdStODPHqXFpngJC4m2t73v3lv krd8k9Sj+UQd3rxgvraWg2fqjgvlhh2cbhG4RmzS3718zKvwIM= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 18:00:21 -0000 On 2018-10-08 19:23, Jim Schaad wrote: > > >> -----Original Message----- >> From: xml2rfc-dev On Behalf Of Julian >> Reschke >> Sent: Monday, October 8, 2018 8:21 AM >> To: henrik@levkowetz.com; xml2rfc-dev@ietf.org >> Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In >> Section 2.40.2, "quoteTitle" >> >> On 2018-10-08 16:47, henrik@levkowetz.com wrote: >>> This captures an issue noted during implementation, also described in >>> https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation# >>> section-3.1.8 >>> >>> Specification: https://tools.ietf.org/html/rfc7991#section-2.40.2 >>> >>> --- >>> In Section 2.40.2, "quoteTitle" >>> >>> The version two xml2rfc processors already support the attribute > "quote- >>> title". The attribute name change introduces an incompatibility. > This >>> in particular impacts existing bibxml reference files, which should > work >>> with both version 2 and 3 vocabulary documents. >> >> This is an interesting point which we really should discuss first and > separately, >> as it also affects "seriesInfo", which is a much bigger change. > > I am not sure that I see what is being said here. Can you give an example? > ... I *believe* we have changes in seriesInfo that will cause references using the v3 vocabulary not to work properly with v2 processors - but it's a really long time ago that I looked into this, so my memory might trick me. Best regards, Julian From nobody Mon Oct 8 11:02:07 2018 Return-Path: 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 97C29129C6A for ; Mon, 8 Oct 2018 11:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 7atX5QnYIN5J for ; Mon, 8 Oct 2018 11:02:04 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33751130DDF for ; Mon, 8 Oct 2018 11:02:04 -0700 (PDT) Received: from [192.168.178.20] ([91.61.62.65]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MGnPx-1fw7Sw1Nej-00DXQT; Mon, 08 Oct 2018 20:01:51 +0200 Received: from [192.168.178.20] ([91.61.62.65]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MGnPx-1fw7Sw1Nej-00DXQT; Mon, 08 Oct 2018 20:01:51 +0200 To: Henrik Levkowetz , xml2rfc-dev@ietf.org References: <02650818-d90c-af91-27e4-d0a9ce18d1d3@levkowetz.com> From: Julian Reschke Message-ID: <844be504-0f86-26c5-5dc7-7211d2882b40@gmx.de> Date: Mon, 8 Oct 2018 20:01:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <02650818-d90c-af91-27e4-d0a9ce18d1d3@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:SlEoOuMdIemlcrpVQYRhaQ3788tf979STdfSwUFI30c1QOXaMGQ QysK/xJsziJEO7nCyTwaQGBQvzZfiOKebT/mUFo4AdvG6CbwX1AssbaTUN875c2379yqnZR p+XunNf9cppaJRGgPN8uIa1xN1dQaemerfWvO4BDoFbDsxOmS2ZDfYf7FYAOaS26/ux3Vvz SgUfbDFAoBuX9ejhK0frA== X-UI-Out-Filterresults: notjunk:1;V01:K0:ajm4PAWZpHE=:rLXzrIxR5UPkzx/IUkVdvk W6h/MpFEQXOVabcpTD6U6ZNYB+YpKEfT3pDtgNR2s5GSweBKzoJQdt5G4ygqmK/CQ1gKAM3+e +TRIGbb1AVLjHpZXNIsZkAhkren0gWLLr81rxreaao38eZAA6WECC+ByuKud6bcGWNjPEWtMm VvRY+PQtaUHK7t7Dgao3l9NzG31X3XDsiH1W34Df6n2CDphJIzIDHtys4OA28JaB0cBdLqgq4 9WrTXHLTq6aWn1sZ3uvjqMpKeopdmtQRLiFEQ1xXKFuegrw/T/oFv9H2v3SkeZL7Wf5SFZCYU NqGfbFpI+DJt2IZT2HX9hEjN95uYdy1lzRNeY5oAkNfGqUq5qLrO+JYcvCwxRnQeixj17Kjww s8rwvLae8Y69Reqhc5VlrHIanMGU3v8cw0K+YKV6WxFmd3im2zkA/JXhbJKex0wEr9f5Ouz+L f/yG4nQdR8e3jL2r1zIGDMcjUgKyuy9ASqgqjqQ44eeAY6PcIhHVdDYvkML8OR+sGrspLYKdg /xgUn6iyezEN/rF4Xjwxk6nCICv7X53m/13kwZMXckEMXwToBHo7O+pC1zDNtS+v38f0ap/tF WUnFQruWG/gJayc5cZjH9LHkJmQAdst0kx+ulT6feSsCuiQJdK5SBEYpAHLhDHuHAT6gAwspk FerCXcxay6O/qcbbE5ydaVCLcz61uhmmJ5EPHlOVmMYEtKcSjk6ABNEAnH24d4EFIVdEpFOoe 5c49/LJHXST3X57tDXNBGocvzMAx7PJsscYXHLo5Ya+XoVmSwFgdhPYkiC+FcgghvRpZCa4pA nuzzS2LzgojjyurJaX+NzbHVL9xOWBlTeKVmafthCfqP+g5/gg= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #45: Schema Issue, RFC 7991, In Section 2.29,
                    • , Unordered lists with arbitrary symbols 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 18:02:06 -0000 On 2018-10-08 17:44, Henrik Levkowetz wrote: > ... > Understood. Would you like to make a separate proposal (with a more > generic argument, I assume) for unordered lists with custom symbols? > ... I'd prefer not to, as this really is a presentation issue; and restricting the level of control of the presentation IMHO is a good thing. Best regards, Julian From nobody Mon Oct 8 11:03:28 2018 Return-Path: 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 68F87130DDF for ; Mon, 8 Oct 2018 11:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 lNz8KirPsGvl for ; Mon, 8 Oct 2018 11:03:23 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A5D2129C6A for ; Mon, 8 Oct 2018 11:03:23 -0700 (PDT) Received: from [192.168.178.20] ([91.61.62.65]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MPZuP-1g4su62xTl-004gk2; Mon, 08 Oct 2018 20:03:11 +0200 Received: from [192.168.178.20] ([91.61.62.65]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MPZuP-1g4su62xTl-004gk2; Mon, 08 Oct 2018 20:03:11 +0200 To: Henrik Levkowetz , xml2rfc-dev@ietf.org References: <68a4ded2-792b-e357-564a-69d69fbffb6b@gmx.de> <50bc63c1-c910-3e9c-2c3f-45fe7dc8af7d@levkowetz.com> From: Julian Reschke Message-ID: Date: Mon, 8 Oct 2018 20:03:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <50bc63c1-c910-3e9c-2c3f-45fe7dc8af7d@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:5coSMeRF/4To1lKox5+1uuRmpGnWutqfOTuSeg90p0I2O5ApHzI 1hrRwf22b/w5/3eISufCpUFr8LC/uweZpsoC9enDRBd7jXxWgJwg5o8YNXZkeOxWfxsnHRz 1cIpeo6BBlDC1yUlbAaXqHQptlQrBfFbRI1XYe9r4mCb1PMVJaA6u8+kTg9iBvs4Df733UY CYePF91ReSYNLRZXtrSwQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:0IM97wcs87A=:jF2HAJcmR4bhTntAoQONZH jvlI71HT9TqemgRSKSyMaxKJYmUpaunMUmVoWtjvrkTOpEMJDSijn3SkvOWepHjprltpjIk7I tcbZZRoEdd4ubvKjhDdZIoR7IFRpNVsxeYhBC63H2pasFdoV/vuXsErV7OvVlfqz9bG7p1hVZ PNRbl9pbyFq5Z+paSjH4JkK4s8CCeJDaLtrYhSZBHUPqwBsQq5UmH04w17UTkmhbl/G3WYD6T nKp251KdF6w6+DiywavNxqEc2B3hp93HlaOUQa8EvC56e+M+QS0c8ieLs7SYpkPl40sqh8Im3 oLSkNJiTKQm4OugQG6rJFNUnk0ihYRzhh29acuMk2zi1oHdrUYinXeny9ICG9x7wMMyqo65Vr aRvAvnRUFX28ELmywXXUe8cXKqvJHQGr6m/SFiN+Au3vc3l5K4hffXRfb3zMKNJoZFfbcnUo0 Ls622kqO7LdW1bjCV3ok4RMdeRU/2V0821XUpKsd+MD230x9GMEhTL3Ir66MzMZQFSL8d2NHE opDpQb8bXnrimn4YSvPJR/KlZWJ4EVQKLBKML80LubCt2GZaBEaoLY/H6s4GQxjOIqVKbbN+p aHKbgbEI6l8LrUH37YL2tTSz1bHSuwfdFJQabgqxWrxLfUTKMty/Uw4cizKW6EfWfosoIZTaJ 8d2UAaJhxo0ZZg0B0HXJUkumLTjV+oWLL2V0wonwRSZhHdP5iwiwdMTt1ftrznSimrhFun4Rp IJ7+/jnIVEykObp9uDNou0YH4uWp9ivDWtDeK8mGu9zfK0aAPIZ/fH4DoWy2kW0fLndHvUrRV 7HDvSRTay/JSGwuttwx4ZGowfmsczGEC/SCN86vm7q3UuxssW4= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #47: Schema Issue, RFC 7991, In Section 2.32, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 18:03:26 -0000 On 2018-10-08 17:52, Henrik Levkowetz wrote: > Hi Julian, > > On 2018-10-08 17:11, Julian Reschke wrote: >> On 2018-10-08 16:46, henrik@levkowetz.com wrote: >>> This captures an issue noted during implementation, also described in >>> https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation#section-3.1.7 >>> >>> Specification: https://tools.ietf.org/html/rfc7991#section-2.32 >>> >>> --- >>> In Section 2.32, >>> >>> So the element can contain text or , and can contain >>> other markup like and etc., but why cannot contain >>> etc. directly? >>> >>> Proposal: Change the element schema to permit all inline >>> elements that can contain, in addition to . >>> --- >> >> +1 in general (but we should double-check that none of the additional >> elements will cause weirdness in titles...) > > Would not that already be an issue if one of the elements that would be > used directly within with this change were used within within > with the earlier schema? > ... Yes. Best regards, Julian From nobody Mon Oct 8 11:05:34 2018 Return-Path: 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 98E56129C6A for ; Mon, 8 Oct 2018 11:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 sb6dFv9ONsp0 for ; Mon, 8 Oct 2018 11:05:30 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 812CA130E36 for ; Mon, 8 Oct 2018 11:05:29 -0700 (PDT) Received: from [192.168.178.20] ([91.61.62.65]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LvPgd-1fiK9m0PdD-010gvp; Mon, 08 Oct 2018 20:05:17 +0200 Received: from [192.168.178.20] ([91.61.62.65]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LvPgd-1fiK9m0PdD-010gvp; Mon, 08 Oct 2018 20:05:17 +0200 To: Henrik Levkowetz , xml2rfc-dev@ietf.org References: From: Julian Reschke Message-ID: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> Date: Mon, 8 Oct 2018 20:05:17 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:FdOUOdNZ2GVCj4uoVuSNQki8hRIcGxHXby1B5MO37Ag0Bx//ZvH 9iSOFvlvyV0JaNGC17YO06YdWjONLBibS2zM8qeK9b+emB52I5RWhVrLltlWmtgl74p0NWe k943h5RiPK9bIOFyzIJCjJexz4yMfU0ZzOy3r301b8var3aRklUj7MhUOYEP8fP9oxhXSSb /Mi8SbzFv2rZK/gyKeZeA== X-UI-Out-Filterresults: notjunk:1;V01:K0:+CSSrMgHPPc=:aO+0saS6C50UE03lyTsHb3 ZtebhHn6DeWPwVi+LyuEWuU3i0hWkSZvwwqroijF6BYx5/Mvp9GBHGTwH2ZE+EOPsfGGy+sRC 6RiCI7lFp/BXRK3KWkvmTIJSt80CF5F8QemviO5a/HdBjF4KmG2xo8/GFGZtx9EXja9eNylyP psndW5KIUcrxb23MEATY9+JWWnilVBwFMvD6w0zKRkIJBHeqycn86buhgIkIYsbua/LFEsp64 wy51ePI9abj5mEEDKKzFc8SByI56JVQua11GAlVhL9FEfIq1k6tPHdyxNiLRXexmTA+WEcTTQ VEXAA1LbMSIGPyN4y9Jq9q5ICTnVhnl6wuD48UKNpM36JujxPdvotBvQqMUXdpL4cqheW6CTl 5XpxfgAtpPiHScCFwckpqrwho7rTU2idlC14T2b07lBtOZoIJN1FqDnapNFO/gy32occCrIUh qpUva5aAQBHFpS2Z7heQBGV3Kj61ieDRBr/S+b0fzazpp0BN3OAi0DCI49GkNGtaUSzkrVjeO dovdS+15YEZNDxhJmM/o5smHYbySSI24HNJh7KYDrHAV6JHTgkxGbD+BxlrkxzZFsz410xZxV 9YHG/vrv9wLz/QIbO1yWqUzeQrshdh8VZgGZmbvmuANFTbK44sLzss0C3jlBvWZ6xrXWLiERL kruZubQdyCfRBl0csYuQYIWMiMoHt4HAO1sJ5MH4uSsmY6Z0mhYGww07augzwUpHpwwPYgv2O Xy67FfvbQoHVe08INvCbzTfaTUq8gNVtpSj+vAGRAIaKIXs4xtf68KHaDV1Sm7htq0Gc5BqW7 P9gM/C3IrMB4YUwATwskF4W19k5jD+7Aerr++i/lbUilRgPs+8= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 18:05:33 -0000 On 2018-10-08 18:01, Henrik Levkowetz wrote: > Hi Julian, > > On 2018-10-08 17:25, Julian Reschke wrote: >> On 2018-10-08 16:47, henrik@levkowetz.com wrote: >>> This captures an issue noted during implementation, also described in >>> https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation#section-3.1.9 >>> >>> Specification: https://tools.ietf.org/html/rfc7991#section-2.42 >>> >>> --- >>> In Section 2.42, >>> >>> The v3 schema cannot properly model multiple reference subsections >>> contained within one numbered section. The v2 formatter handled this by >>> silently inserting an enclosing section, but with the introduction of >>> the preptool, which in theory should produce a master file from which >>> various formatters would produce equivalent results, this becomes >>> troublesome, as the automatic insertion of a container section is >>> specified for the html formatter, in section 9.8. of RFC 7992, but not >>> for the text formatter. It would be much better to make the prepped xml >> >> ...because essentially nothing is specified for the text formatter - so >> I do not agree this is a valid argument. >> >> IMHO, the output of the text formatter should be equivalent to running >> the HTML format through an HTML-to-text converter. > > I can understand this viewpoint; I haven't actually tried this, so have > no particular viewpoint on how feasible that would be. > > However, this is still an issue, even if we disregard the text vs. html > specification part. >> >>> explicitly show exactly what should be rendered, and not rely on >>> formatters silently insert elements. >>> >>> Proposal: Update the schema to make it possible for >>> to contain , and have the prepped xml >>> explicitly show both the encapsulating section and the >>> subsections. >>> ... >> >> Not convinced, because: >> >> 1) It hasn't been an issue up until now, and > > So the reason it has not been an issue up to now is because the formatters > have been doing 'magic'. The introduction of a normative xml format makes > that problematic. I believe that the output of the preptool should ideally > not leave it up to the formatters to do any magic at all; the content should > fully and completely specify what would go into a formatted output. This is > the underlying issue I see here; apologies if I haven't expressed it well. > >> 2) allowing to contain creates a new nesting >> issue. > > In that case, I think I'd be just as happy with having the contain > a
                      that would hold the two . I thought about that as well, but then people might get the impression that they can control the placement of the references section. Again; I don't see anything broken here. Best regards, Julian From nobody Mon Oct 8 11:09:04 2018 Return-Path: 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 D3A43130DDF for ; Mon, 8 Oct 2018 11:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 WMPL_OIgBYko for ; Mon, 8 Oct 2018 11:09:01 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B9D6129C6A for ; Mon, 8 Oct 2018 11:09:00 -0700 (PDT) Received: from [192.168.178.20] ([91.61.62.65]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LwrS8-1fcWPR077g-016OiC; Mon, 08 Oct 2018 20:08:17 +0200 Received: from [192.168.178.20] ([91.61.62.65]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LwrS8-1fcWPR077g-016OiC; Mon, 08 Oct 2018 20:08:17 +0200 From: Julian Reschke To: Jim Schaad , henrik@levkowetz.com, xml2rfc-dev@ietf.org References: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> Message-ID: <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> Date: Mon, 8 Oct 2018 20:08:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:RyMuP+lWLpe6VWD+IlvsQvsBpr/c8mGMO6f5oJ3Uk0Ot/9B5xYU uf796tGE9xOtVrXYNJWGDnOnojiNjBEzoB8zc8a0QBhaM1a1rtpYfr39SaajELYnSQuOud9 FdLzReClD6q6C/Plwjz7TAkf+4epJKcWt/pWCodtVgpb7w8icKOhUtmMOaeycmxl1ku1meh ebW2dYsq0BNF8oGcMIOTg== X-UI-Out-Filterresults: notjunk:1;V01:K0:danmJP7FvuI=:MIquhJi9fBIly4DNho+KCn Xo7pLpBAWJchroGSPdgO5OyThUv6AlGoLSeWK9pH3r0V0dsHm1QC+rtnw7fKQ42Qmxpv/4MMg oF4hgnwy+QG8kvi+Rn31OW8Tit49dCxLG176ZO5tFTq7hBemBBibNPJ2d0Z/v5IBrB3OkRZYT 6CoWuTHZ6MW0rCfAc2NpTgL6CRsbM2+csCl3bDKrC5y+3M41I9TSupW+L5jmqQBNrlng+AaVC m291MBAwmFgpL5ho7Dc3Eutt6bKtgOVnp/rDB4i9ygJZf2s5bWxpHgKPBaOo5VpyMuHO8u5rT NHtqjbUptNetY+0WZjMG7/Kgyi9WhIkJYe9Ce3rxzIrOMnjRyIqCHN6YLKu+vYugjvKZVseHP QOpOFRGZCeQ+SPV/RruKrwk8judWWJn6DMIT4fXCZSga9hsaxfsBXsv63BvZCbHyIEDYAALfK DKGeCj48btRGaq0hGqQ+tHmsnQPAQb9Bo46dDBwINzWtfU75t289hE3SScCFuwNxI2QzFTB1h gfhjb2FgvPOUvCOssrsccerhIbff3YHzn2w2/ghAe1Jk3fhABuw9eWz0e+N0428H8QJNmK0cT rEu09zEsGz+ZU06hqSNjwlXyz4Ygll7uWd0Zmpbz1elK2hIwaD3I03aUI1goctx3Qryz50rBa dFnO06eIjCHpxS0AwBFGy6Z/JfX+4jGr4GruGugbsx4mkVuRw7qnZCvh5JyzzrSQDB8fkiL3m sBKMYek8Cym7iclGEvH016npln15v2CvZRS8tQ7d2Fr6xZ438X53K5s+25cS2U8DmeWl6j001 31gbEDy2+2BA0F9RkOyfh8rjmJanhM+lt2AFjUM7GYt8ykdkM0= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 18:09:03 -0000 On 2018-10-08 19:59, Julian Reschke wrote: > ... > I *believe* we have changes in seriesInfo that will cause references > using the v3 vocabulary not to work properly with v2 processors - but > it's a really long time ago that I looked into this, so my memory might > trick me. > > Best regards, Julian I didn't. We move into . Existing v2 files are already broken in that they use the deprecated format. Best regards, Julian From nobody Mon Oct 8 13:20:51 2018 Return-Path: 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 07427130FCF for ; Mon, 8 Oct 2018 13:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 BBmyUEFEdex7 for ; Mon, 8 Oct 2018 13:20:48 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3F75130F67 for ; Mon, 8 Oct 2018 13:20:48 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:52203 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g9c1H-0003dM-Hh; Mon, 08 Oct 2018 13:20:47 -0700 To: Julian Reschke , Jim Schaad , xml2rfc-dev@ietf.org References: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> From: Henrik Levkowetz Message-ID: Date: Mon, 8 Oct 2018 22:20:40 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="n1qcBFc0XPEe2wMXAqXTffJeKMLiHvFfv" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, ietf@augustcellars.com, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 20:20:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --n1qcBFc0XPEe2wMXAqXTffJeKMLiHvFfv Content-Type: multipart/mixed; boundary="EgGl5oN5SsiBX1l1xAogL2DrbdpecjWuQ"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , Jim Schaad , xml2rfc-dev@ietf.org Message-ID: Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" References: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> In-Reply-To: <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> --EgGl5oN5SsiBX1l1xAogL2DrbdpecjWuQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-10-08 20:08, Julian Reschke wrote: > On 2018-10-08 19:59, Julian Reschke wrote: >> ... >> I *believe* we have changes in seriesInfo that will cause references=20 >> using the v3 vocabulary not to work properly with v2 processors - but = >> it's a really long time ago that I looked into this, so my memory migh= t=20 >> trick me. >>=20 >> Best regards, Julian >=20 > I didn't. We move into . Existing v2 =20 > files are already broken in that they use the deprecated format. But the old placement is recognised, even if deprecated. The issue with "quote-title" is that it's not in the schema at all. FWIW, it was introduced in the xml2rfc v2 formatter on 2015-03-08. Best regards, Henrik --EgGl5oN5SsiBX1l1xAogL2DrbdpecjWuQ-- --n1qcBFc0XPEe2wMXAqXTffJeKMLiHvFfv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu7vBgACgkQTptXS4+7 FxpQKRAArDHLG6rCg4qG6agBcMmxlgeRvys7v6Ht+9kRHuOgBposvwBwq+UY1PeR WF+nK+WS7C7+63H3mQ6KdfENsjVos6XDknSeOjp/8VKK/Y8qRQeh2X3YqdJxRQ1F EOwQfhLVH+1qxDiqJiWvUoL3a9uRMavHuB6X9gbSF8TzDrVRqUxB2Tp34M+ME14P jOYHpYtD2GQngwcGG10PpCey1MfIyysbcEWBpGgv8jf5+NTluj7mpHUNomSEmrDP E9qtM4nmxobPKpOnKZP+VvFuqsh7Q119HHfqyimppXv7pEJ9WEhOP6WsJNuIR9ls s/2EhEOWI3wVfkDlyt2Mp/rbGotUuRV2QoFbEQX90/7I0UAuElrVMlx6pI2rZNFQ 6KRgToS20IPoeFt2bAdibfYJDZC3G5kuxTLrTYL6vdrP4Y8n88pqTSr+BCG3pWZz pzC8DH59LL7zxMVQef8R7rOw0iCgNYbmVyR7/ADfsOrTAyKKRecIq97kv2k26KDp XYsV89QKWPDwlIp/VJU9crs8N4wOKD4uhLaJaf5Ff5Qo8IMWvltkQHpT3UfTQUIg zrUGvifDsPDeqcJ3995l1ptNrMUEp3XNvdbKOuY6wIDw3Y2go8sWEuLTwLyYi8dd gReQvQWv98KxLrN3U9IN+n1lAM7ogiWfivj9f1d9sPgHxs58eVA= =j36k -----END PGP SIGNATURE----- --n1qcBFc0XPEe2wMXAqXTffJeKMLiHvFfv-- From nobody Mon Oct 8 13:38:30 2018 Return-Path: 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 E0FB613106A for ; Mon, 8 Oct 2018 13:38:28 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 2w2Z28duzwqC for ; Mon, 8 Oct 2018 13:38:26 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77063131065 for ; Mon, 8 Oct 2018 13:38:26 -0700 (PDT) Received: from Jude (50.252.25.182) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 8 Oct 2018 13:33:42 -0700 From: Jim Schaad To: 'Henrik Levkowetz' , 'Julian Reschke' , References: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> In-Reply-To: Date: Mon, 8 Oct 2018 13:38:16 -0700 Message-ID: <065401d45f46$d92c3710$8b84a530$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLAbTej30L1EUF5/gxtYUDerJ/dBAHYXIfkAiclg5oDoS022gFG0/brAggLbMmi5jZyEA== Content-Language: en-us X-Originating-IP: [50.252.25.182] Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 20:38:29 -0000 > -----Original Message----- > From: Henrik Levkowetz > Sent: Monday, October 8, 2018 1:21 PM > To: Julian Reschke ; Jim Schaad > ; xml2rfc-dev@ietf.org > Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, = In > Section 2.40.2, "quoteTitle" >=20 >=20 > On 2018-10-08 20:08, Julian Reschke wrote: > > On 2018-10-08 19:59, Julian Reschke wrote: > >> ... > >> I *believe* we have changes in seriesInfo that will cause = references > >> using the v3 vocabulary not to work properly with v2 processors - = but > >> it's a really long time ago that I looked into this, so my memory > >> might trick me. > >> > >> Best regards, Julian > > > > I didn't. We move into . Existing v2 > > files are already broken in that they use the deprecated format. >=20 > But the old placement is recognised, even if deprecated. Yes, but if the v2 processor does a DTD check it is still going to cause = problems with the ones in the new location. It may be that different = bibxml entries are going to be needed for v2 and v3 because of = validation of DTD/schema. Ji >=20 > The issue with "quote-title" is that it's not in the schema at all. >=20 > FWIW, it was introduced in the xml2rfc v2 formatter on 2015-03-08. >=20 >=20 > Best regards, >=20 > Henrik >=20 From nobody Mon Oct 8 14:41:45 2018 Return-Path: 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 86A3B131007 for ; Mon, 8 Oct 2018 14:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 8a6xRj0dKte3 for ; Mon, 8 Oct 2018 14:41:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB330131000 for ; Mon, 8 Oct 2018 14:41:42 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:52664 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g9dHZ-0005ws-NG; Mon, 08 Oct 2018 14:41:42 -0700 To: Jim Schaad , 'Julian Reschke' , xml2rfc-dev@ietf.org References: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> <065401d45f46$d92c3710$8b84a530$@augustcellars.com> From: Henrik Levkowetz Message-ID: <4308bb9a-14ef-ca1c-03b3-2d1d09bc95a5@levkowetz.com> Date: Mon, 8 Oct 2018 23:41:34 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <065401d45f46$d92c3710$8b84a530$@augustcellars.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ltBMEsJ30a3Tnsv7KjHQ3jEIjp1X0vtwq" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, julian.reschke@gmx.de, ietf@augustcellars.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 21:41:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ltBMEsJ30a3Tnsv7KjHQ3jEIjp1X0vtwq Content-Type: multipart/mixed; boundary="d9s3LLQU2WpKrpWSs8HXlGEKLi12bg3qf"; protected-headers="v1" From: Henrik Levkowetz To: Jim Schaad , 'Julian Reschke' , xml2rfc-dev@ietf.org Message-ID: <4308bb9a-14ef-ca1c-03b3-2d1d09bc95a5@levkowetz.com> Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" References: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> <065401d45f46$d92c3710$8b84a530$@augustcellars.com> In-Reply-To: <065401d45f46$d92c3710$8b84a530$@augustcellars.com> --d9s3LLQU2WpKrpWSs8HXlGEKLi12bg3qf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-10-08 22:38, Jim Schaad wrote: >> -----Original Message----- >> From: Henrik Levkowetz >> Sent: Monday, October 8, 2018 1:21 PM >> To: Julian Reschke ; Jim Schaad >> ; xml2rfc-dev@ietf.org >> Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991,= In >> Section 2.40.2, "quoteTitle" >>=20 >>=20 >> On 2018-10-08 20:08, Julian Reschke wrote: >> > On 2018-10-08 19:59, Julian Reschke wrote: >> >> ... >> >> I *believe* we have changes in seriesInfo that will cause reference= s >> >> using the v3 vocabulary not to work properly with v2 processors - b= ut >> >> it's a really long time ago that I looked into this, so my memory >> >> might trick me. >> >> >> >> Best regards, Julian >> > >> > I didn't. We move into . Existing v2 = >> > files are already broken in that they use the deprecated format. >>=20 >> But the old placement is recognised, even if deprecated. >=20 > Yes, but if the v2 processor does a DTD check it is still going to > cause problems with the ones in the new location. It may be that > different bibxml entries are going to be needed for v2 and v3 because > of validation of DTD/schema. Currently, reference files are only being created according to the v2 schema. If we begin to create them according to v3 (because of richer semantics) we may have to maintain separate, parallel bibxml repositories= , yes. Henrik >=20 > Ji >=20 >>=20 >> The issue with "quote-title" is that it's not in the schema at all. >>=20 >> FWIW, it was introduced in the xml2rfc v2 formatter on 2015-03-08. >>=20 >>=20 >> Best regards, >>=20 >> Henrik >>=20 >=20 >=20 >=20 --d9s3LLQU2WpKrpWSs8HXlGEKLi12bg3qf-- --ltBMEsJ30a3Tnsv7KjHQ3jEIjp1X0vtwq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu7zw4ACgkQTptXS4+7 Fxpg6Q/8DauPy8eblI0V25FKS/hoNgcglcjJErcIiRnZ89ZdNfNn3iM073fZ7AIc avPwwoJj1dVnN6V7rItVkTjC8rgZk0Ast1WY5xbXyGZWp11fEEyeOL8RdwurJ0jg BvvgyNJwuJ9MbhsjUaU5QAqLlxaSALlJYL35I3SdV+YF+CVofdCzd8PTfpT8SNxl sZJldgTXx+T19RLqCWWFV4/JzRxdN91QXP9+MQAakrlR8/h3NX77AwgxhPTnPjvZ Yq13rXlaMkuYfUYNVPubDTFxWhF8wZu8hOMI0TcWrWaTAgDGtN87lII2pdRTnRko ijWBhoLrAF65tpfV/4Y1v6naNWN4zh5/1OReJuzetPSuGCVLzATBwMKmOIS4fRMl PbbpkNV6EzhK+fIz/cg/xDFk+futVbb+S9YNixhje+bdSFTTRaY0oX1jy2j6fmd7 oissG4NNNGkrMMl8VKFX9uj9ObYKTU2iOtHRoZ1sTVt/H2K+BEaBCxxgQOh99kJv dtRZlx5EXyGyHCWxk448tdfewV9sMn2HMysj+RphIGahVwMQ9bKZU+6iXhRQJNFj F746d2r7XZxR2xnqR0tF9bp2Jsm+wQKNHvVZTw3qi8n3Qlcqjkj4Z30HrDLEREK6 kyJqgEm7fpEdm+ldziRihaHD7BZEs1eHWPs4V1WEVbkFEuFgQ0g= =w+XO -----END PGP SIGNATURE----- --ltBMEsJ30a3Tnsv7KjHQ3jEIjp1X0vtwq-- From nobody Mon Oct 8 21:52:09 2018 Return-Path: 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 97AE313110B for ; Mon, 8 Oct 2018 21:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Bq8MEW99Fqil for ; Mon, 8 Oct 2018 21:52:07 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76A6D13101B for ; Mon, 8 Oct 2018 21:52:06 -0700 (PDT) Received: from [192.168.178.20] ([91.61.61.6]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MIdYi-1g7Y8C2EBs-002HPY; Tue, 09 Oct 2018 06:51:16 +0200 Received: from [192.168.178.20] ([91.61.61.6]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MIdYi-1g7Y8C2EBs-002HPY; Tue, 09 Oct 2018 06:51:16 +0200 To: Henrik Levkowetz , Jim Schaad , xml2rfc-dev@ietf.org References: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> <065401d45f46$d92c3710$8b84a530$@augustcellars.com> <4308bb9a-14ef-ca1c-03b3-2d1d09bc95a5@levkowetz.com> From: Julian Reschke Message-ID: <4e4af1df-37b8-c180-93d8-14104fe2281c@gmx.de> Date: Tue, 9 Oct 2018 06:51:15 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <4308bb9a-14ef-ca1c-03b3-2d1d09bc95a5@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:almQpmzAALPsoQoqraER9tfS0KtpDYbCAcEQ2nXdMDA1f0mrZDT dkWnGqL8VSSx093FkhxyHXB9Y6jsGt4+9mq++rZsKZ6FEu4VpCVIqdi6sOQwyUvC9G0ryq2 +JAbympvvP5cRHmbk6d9M0gOhGTYloKMGo2ypxMpElwXIm0HqWVlsUb1L7OFIYgg7Hkjfvm VL+jcS4eeeKtfTcRZr//A== X-UI-Out-Filterresults: notjunk:1;V01:K0:ExvhFMiXD+k=:tu7i8Ole5r2AOi43J+XmGu bl1TgJYePU/MHyUMX7b4qVe8lWlmxt3Bk9F9tWjqBXqJXGOz5rIgrw9mPYglp40JBt1DT518J bDzlr9SxEQmKOphTLH+9pN9+PyiCkb7Pe9lY4BQyOZXm++o+E2PEygnJRQ5v8iFcARvRHhayL oEA+0zKjD+I3/QND2q/t6Ljl67t2OJCyRvJqBsKYSHZFwtUp9PqpzkTBIPqRsQmB7Xqhwf83r zV4ileE/twCFYi5eh5I7EJPj5HE1yF1KwnmvuhDoF3rR1Q8374M1MQIyu0fv02v16Nykb5q23 f4l3oHmtXvYR5ZAHgudTm9f797CK9WSWohGSiJgMKcYsrb7IKNrZTbM2LCF8g2sgJa0ZmEDcB JRMThPEn3gqtO0VDMGHAbvHHP4mNcou8Ur6msLgi0XpnBownVVP10eUa5J0fWNAWbjraBy48l v+9khtoO+4lqZh9rvmHLslLvyn412LEktZZjOsHW4XTuQE0m3Bl9QDwHi2YJK8LHIVzK7Ljlm AcvVrbx92OWutsLxIDaU28XaojE0VOJ3Cek0FyDK1HSXGZU6LfRxWNoyFj5+lRCACu1q+FD6u xgyEFPtijL/883TO28Yqw989iilWDbuSlA1PSK3ocnOpCuD2Y1kRH956FOFx5Iupw+jn8BxRm 9Zq3Lh9rDBbN0sAKGh9mRTfRiBj8u4xpVi+32yVWfLHaewxk9bBV6V42CpptWftrXNPlB+2et rj+CceZqYtJi323tdDO1hAfdB1KTNXMfF9t/jFr2NTCk2VpeoSZbJTBwsob3iwFDRg+JfX6qo AvG8cFaFY7LHhUQtlYXsvfsg79eYMTF2tufesZeqRPQJ17Rc5A= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 04:52:09 -0000 On 2018-10-08 23:41, Henrik Levkowetz wrote: > ... > Currently, reference files are only being created according to the v2 > schema. If we begin to create them according to v3 (because of richer > semantics) we may have to maintain separate, parallel bibxml repositories, > yes. > ... That wiil lead to friction. Maybe we should reconsider any change that makes those incompatible. Best regards, Julian From nobody Mon Oct 8 22:20:22 2018 Return-Path: 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 99D3F13114E for ; Mon, 8 Oct 2018 22:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 9qWsCBtafIRb for ; Mon, 8 Oct 2018 22:20:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FE1B131155 for ; Mon, 8 Oct 2018 22:20:16 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:55031 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g9kRL-0001Xy-0J; Mon, 08 Oct 2018 22:20:15 -0700 To: Julian Reschke , Jim Schaad , xml2rfc-dev@ietf.org References: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> <065401d45f46$d92c3710$8b84a530$@augustcellars.com> <4308bb9a-14ef-ca1c-03b3-2d1d09bc95a5@levkowetz.com> <4e4af1df-37b8-c180-93d8-14104fe2281c@gmx.de> From: Henrik Levkowetz Message-ID: Date: Tue, 9 Oct 2018 07:20:07 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <4e4af1df-37b8-c180-93d8-14104fe2281c@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="T7edtwEITVopaG6njRwUnhnsjJ51sWmFV" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, ietf@augustcellars.com, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 05:20:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --T7edtwEITVopaG6njRwUnhnsjJ51sWmFV Content-Type: multipart/mixed; boundary="Sm1i2XtwHQGWDhWJG7PxNe20Pv2dBMEcu"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , Jim Schaad , xml2rfc-dev@ietf.org Message-ID: Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" References: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> <065401d45f46$d92c3710$8b84a530$@augustcellars.com> <4308bb9a-14ef-ca1c-03b3-2d1d09bc95a5@levkowetz.com> <4e4af1df-37b8-c180-93d8-14104fe2281c@gmx.de> In-Reply-To: <4e4af1df-37b8-c180-93d8-14104fe2281c@gmx.de> --Sm1i2XtwHQGWDhWJG7PxNe20Pv2dBMEcu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-10-09 06:51, Julian Reschke wrote: > On 2018-10-08 23:41, Henrik Levkowetz wrote: >> ... >> Currently, reference files are only being created according to the v2 >> schema. If we begin to create them according to v3 (because of richer= >> semantics) we may have to maintain separate, parallel bibxml repositor= ies, >> yes. >> ... >=20 > That wiil lead to friction. >=20 > Maybe we should reconsider any change that makes those incompatible. Ack; looking at those again makes sense, in view of the possibility of having to maintain different reference repositories. Best regards, Henrik --Sm1i2XtwHQGWDhWJG7PxNe20Pv2dBMEcu-- --T7edtwEITVopaG6njRwUnhnsjJ51sWmFV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu8OocACgkQTptXS4+7 Fxpd1xAArYEefTrWpo6mip9ZQ9W7vPk1b66tw0OdrjMCUohDd2QweeFkHQHRjp39 RYnYeYW0z+SjmpL2v0z6oW+23l83L7/fQ9nBQ54hTfHzDFYXo2l0qLN5XYOyT7zy xOS1WqZd+ELeUrgYcO4AgE2igy2MybuOi3c8BpXUrqnG24TB+QBWu4WyKZAwoBmP udTeFHKgMM5txa/A7y6hBQbqCbr4QweKXHZtUWPqV7LcxIYXzCJqBL7FtHzYr/hV eUUqCl2bdUzrK1kkzuANkBjoNewBio37urgMJ1QBWGjtVD36C9+Wm4tG05tSkU0c v6GJjIweJi05KVn+0dAVgt64JK0LmOu5lwUHUqVpMiWmH27kPtxrEhSO1HFLzXZP fZYspUS71ORGYZiRtuYmDTbAdM97/wlenMCyeZ0/Qt0hIolM1wygB5Qm2/LvUE9q w+d8+4DRh3DpG68KocNNzP64BVu2TAf8ZhlDuNdTl/YbwCekpBH5C7j3u6r1KGI9 SOHzWbStsHMGVBjY4JaJVeN9+MSDZ9kI7UPiwtn/hPEkU3IYST3x8D8pYs1+8JSJ X8HPwgnmXKs7/T8v2BH5bJtateHU8bNo2cvEy4HbO05geb/LfLppVE2MJ4k4Kt2u UOApy52WEmBea6NmbxKULjnH3ypnZUxuxLZh68xMFKT7IpcKJDQ= =/7XV -----END PGP SIGNATURE----- --T7edtwEITVopaG6njRwUnhnsjJ51sWmFV-- From nobody Mon Oct 8 22:48:30 2018 Return-Path: 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 6BDE7131153 for ; Mon, 8 Oct 2018 22:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com 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 mm1lwtNS6PfU for ; Mon, 8 Oct 2018 22:48:25 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0094.outbound.protection.outlook.com [104.47.93.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B11313114E for ; Mon, 8 Oct 2018 22:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0z5lwTSCHAMXpIzhYCRzEoEJItimuWLu2MKO8/6P/ds=; b=xRKi5JWW/xqYvBUcyFb0j9gQxKrCbMqmPfrUVkcDGcVGXM3s8eS4AeHwjojg+aBNuKH5O1F75APg+GQWOQaPcBhyxvyP5gCDWGvNu4uUvs+ILMFrwm2ROzWPanCFJ7jFBiZjl9iTh0tRaL9mflRwbfK/xr9EH/tIs/TH3JOFpvc= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by OSBPR01MB1544.jpnprd01.prod.outlook.com (2603:1096:603:3::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.26; Tue, 9 Oct 2018 05:48:23 +0000 To: Henrik Levkowetz , Julian Reschke , xml2rfc-dev@ietf.org References: From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <1ec2a9dc-0a93-cb3b-0beb-775aee0c7594@it.aoyama.ac.jp> Date: Tue, 9 Oct 2018 14:48:21 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TYAPR01CA0022.jpnprd01.prod.outlook.com (2603:1096:404::34) To OSBPR01MB1544.jpnprd01.prod.outlook.com (2603:1096:603:3::19) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8a4655d8-4d3b-4fcb-cf13-08d62daad34c X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:OSBPR01MB1544; X-Microsoft-Exchange-Diagnostics: 1; OSBPR01MB1544; 3:Imscb6/UjWCZ0Ah4imzbE8L8SWYjaIU76jyM2dlZAulsI3bTJQtVh0pigXGW6qKa5G8dZAN8IZFR1j+aCilQDKIxfh2pM/3WmavrLxNpVzC7thLjN0kP/H6NlbpIzLWZT+GJLSMnf4S/KDV4LMP0O5hyhEvubLsfa95uDmjuJBcL3h+Ebcv3X45d+qSO1lBd/pHgcqArJWHCvBa/oQtc7omCvQQu4/vz2CmbQOaU5QjsqTK5arvx50HBevONTsOu; 25:bkq5vSzOgomd/0TYuX26fZ5A3hkoNeeWxBSpwe3Ivs1Bl5T58lSjCwyHUUyNGDLkPybXe9hlbUCVb/S3StVor9lrHzn5VUIUbFT4FwRUy+G5mjASHXROPklcGg+ZYna0C6cwSfy8lNLqgDw1cfdcn2RL0kyy1KugHo8SACej58Vkubjr11oIl+1c4VeLiltjC5ChWnX43fInC1+VKxDNy8pL+JrSNXd1RnXQNhAYufN8f1ps3NYvwCUSKa5mvLsv9NgNfnU4TdvL1RdFa+mfqj/eJg0mDd4kPJf36zNb3zvV7JuB/DoBjnZMW4dC1KtvfXiYI8spASAXXpWabUkxXQ==; 31:KcIEsXCx048jUPHQBbQtj92vRVfwdzz5z88pqko7MxhUZ1Z7yhaOURXN3kEb2Hj7FXeB3qzP/YbBVXZQkjP85/eHaY+l5gsls+iZf7jSgE/baD0I0QOmotzuDl4VOdvgOihZ8CG1FsYYQDa0pW99Mf0OmlhPCLLFh/YA6+xNFpnjtxgqCrv+TENCVLQiOqfqbtDcj4jecXBOG0A0/caw42ISPGWG3vX75UsjLWEtsPc= X-MS-TrafficTypeDiagnostic: OSBPR01MB1544: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(131327999870524); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231355)(944501410)(52105095)(3002001)(93006095)(93001095)(149066)(150057)(6041310)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201708071742011)(7699051); SRVR:OSBPR01MB1544; BCL:0; PCL:0; RULEID:; SRVR:OSBPR01MB1544; X-Microsoft-Exchange-Diagnostics: 1; OSBPR01MB1544; 4:QaMUGfa1TEimM3rdiyqKFbg5FP1SFXZpTC51/XvTE4AECpOL4EVHhnvhbiZRKGSOy4GWyPPQGbimvQFf3Z6byZCCA7M/3nPi5zn3q+P6owTk270ZrAeMisC5D85Dk7wnAkkn2fvHfxwbFeo96nUFrPm/iE+Q0WZHzCCCPYAHTU7ymI6YtlYGgl2YkQ1NV4NZg/11vMz1oPULYDGUZmilfIu1ODStPzlgdsj1t24Lz7q3/VQJyqcLOu+yFO6/Y8Rv2zZ/g4pDuPhKwELRCNTolqXHBfp1GzGxX9HYvGjF4z8sm1WXJdny0KdFJXfmQELj X-Forefront-PRVS: 08200063E9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(376002)(39840400004)(366004)(346002)(396003)(136003)(189003)(5383002)(199004)(65806001)(66066001)(67846002)(786003)(386003)(65956001)(105586002)(110136005)(47776003)(81156014)(53546011)(8936002)(5660300001)(81166006)(8676002)(26005)(49976009)(74482002)(31696002)(186003)(316002)(16576012)(86362001)(65826007)(6246003)(2906002)(16526019)(76176011)(31686004)(7736002)(446003)(561944003)(305945005)(2870700001)(64126003)(2486003)(6486002)(106356001)(36916002)(2616005)(50466002)(25786009)(58126008)(956004)(229853002)(486006)(53936002)(3846002)(476003)(23676004)(52116002)(6116002)(97736004)(52146003)(68736007)(11346002)(478600001)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OSBPR01MB1544; H:[133.2.210.64]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPU0JQUjAxTUIxNTQ0OzIzOitYVFN1QkRjakdQQ0VTRElqdzNyRWFidnJk?= =?utf-8?B?V2IvMlp5YW1sY21PTW5MdytiR1c3UXFMRWRpb1lSOUtKZko3OHhuZmhSL2tE?= =?utf-8?B?cmtkT1E5UDYvZlZqN3dUa3R1TEFCMWtNNk50SzhaUnBNZEJ2VEI3aWlvZ1dQ?= =?utf-8?B?KzZPM2VML051Q1ppd1FFa1NJeE52RmVhVlYxUG9hQndlZVRYczN5bkY0cnEy?= =?utf-8?B?RElOL3RUVmJZd3AzTFA2THRtMm11S3JqemF5Nkl0VlR6STRBT0VjZFJyalFP?= =?utf-8?B?Y0cyVzI3UTl4Q1NlYXlKeDFIRXVsN2xCL2lzZ2ZiNHREamdGU2t6UWI4S1VZ?= =?utf-8?B?azcrY0d3bVdEcXd6V25BeXpPYnR2NFNRUUY0KzYwYVUvd29WVDFqMlVJSldS?= =?utf-8?B?SmhWQkF0aXFzeko1bW5rQkg2NFRQK3J3cXpqZzFFQ3o0c2JWTGFNVUZ6OW53?= =?utf-8?B?V0FPWnF4YkRpeitDYktxNnpKSEVVNm4yL1BVRmJveW1qZWlpRXg3NXRDR21S?= =?utf-8?B?NU5rM05xV2xUd0xIdkpPZnl5VkJwU3F6MkxoOFFHVkdZUG1aMEpQZllZTWpV?= =?utf-8?B?bnR6cUYvMFdBUVpFbmRqREtnMGkvcG5Fa1ovamRrc0UyQWxLOTB1ZzcraEN6?= =?utf-8?B?QUZPSEhwVzlWc2NXbEtVOU50UlBZTlgrS2hoeGlnV21KNjc3UjRxTjZJTmgr?= =?utf-8?B?dlRHR203TjkrMjhESkw3SVRJUVZrNGxOTTdnRkpZRkgzZHNwQkt4cDhrYkQw?= =?utf-8?B?L2FhNzNDMHpjVVJpTHJGL3VkM1I4WUJEZFAvNlVKRVkyUjIveDBhNUtndzRI?= =?utf-8?B?MzZ4UEJ4bDVWUFprNXNqeDUwNW54OTZVS1FENFFUbXRhUWxabTVNYW5iaXUy?= =?utf-8?B?OE1EZ0E0SUM3aUUxeUNrZmZ1MWVtUGMwSnhMQXR4anBFeFl0eXFaNE5xazRw?= =?utf-8?B?c0F1TnFIVkUvcHcrZVA3RmdmcENkQkV0VDhyNFF0ZjVYVm9WdlVoc3orSno2?= =?utf-8?B?Rm9lc0NQUUJ6am50Z20wSkJUNWZrTWpRNFVCZTF2ZHZIL0hibnpjblQ3MkhD?= =?utf-8?B?eVFpY1NWaklTODVnTERVK21SVldVaWZzMXJpaTZtTUdRQ1R4TVBicmplQ3RO?= =?utf-8?B?RVk3N1hZSzlkdzA3TUd6Z1ZPQjEzUFFyMEJTanJHdkhJRk1TbVZaYW1kbnVK?= =?utf-8?B?ZHEvSHBLcmlEcTlpUWlkSjdISzdOQ0VKMGxpZzM1YVJQajc4REFVMUJRdDNR?= =?utf-8?B?Y3o1OHBIeEduUU9PWXI0QnZSS2J2Qy9MNjdoWWVlMTNlbnViU3hnZ3RQZEM0?= =?utf-8?B?WklEeGVNZ01KY0hlcW9MRVpCV1dVTCtHQ3hDQmY0czJkaC9aaGxJa1VVeC9J?= =?utf-8?B?K1pzSlVtT2ROWEs1MmNUdnVzOUV2K1M5Q2J1SzFXaHoyNWQySHZtWnpDUUFR?= =?utf-8?B?cUhkSkxsc0djMmxBVWJQV0NTTHZvalMwUHQzYk5Pb0E0Qzk0akV5OE9YWXBZ?= =?utf-8?B?ZDgvTXBRSEZPL1lXWlZuY0dZQWFlcHRKUHl1eEp2dmlRRjJ0SC9hRHllMTJa?= =?utf-8?B?UysvSWZFMS82bVRreEw5RThaanVkWndQSDYxclZqallKNXhBc2NEQ01yMEhG?= =?utf-8?B?NVh2WWtGUjBjWm5nWVZjWTU4TWUxQXkwSDRmV3lYdWlzR2NEWWJiSjltY1Fi?= =?utf-8?B?c1JZaEkxNEdadlpjR1RsZGhYLzZ4SDQwS2d0Z3pXZUpxdGwzQzVrMEo4WU1U?= =?utf-8?B?Y1Vnb1RqTjd3dmowWFZ1RktkYUxFR0xCNFNXQjBOaU5RcVJEMGkzZm1HTmF1?= =?utf-8?B?V3ZHR3Y5cTk1Y1dJRWUwTjFJaktoMWFlWVVIVDhrd2w1bUhzWEFnZkd3NE0w?= =?utf-8?B?bUx2anVUYWJJQXpCYzliOUdmK3c5ZEMvU0hSM3lXdTJpWmMwOFBGalpDd0xZ?= =?utf-8?B?cGE1VHY2bFFrVnFGd2p3NXJiWXZSS0U3R3dFdHNEdng3ME5obmVWRStlRmYy?= =?utf-8?B?Z2RhaEZ3d0dlMFJsNDNlcUMvNENUeVc5V2E5Zz09?= X-Microsoft-Antispam-Message-Info: ljTNVXfhxJOGArowwPuIcGBy34SWCpPInKTPUELg40OrsO1ZgLHgXqUWyyq6JsQC/bKMXZWk+6AKEDCN5G+pcS9nKJL9bxhdB7rNJ5xDZg900EYyLasbTgT2wSYk2RHSwFniybRXLp9ZMSV70tgX6Ufbl3eC6cIxi0mlvKxe6N6cJ0zwWjgv4PNRNQPUDph+3eXqsy4mO/PthEpmZUcxWFtpLbQM/FPi3xFOD5aNtF2mMt7vVIXuMFQpHXMeMlk5W0+m8Oq2XV3Qka8elnP6lzZ+jUUmtKnIFYAVSQfyXQXAM0vpVaQOXXkGtp9zx9JYAi6nwNrW5dPqNVl/AUt9XPPxumXRcfmnWoM0F6+ikIg= X-Microsoft-Exchange-Diagnostics: 1; OSBPR01MB1544; 6:uIz0ASFornXTlPhFD7YMpHvSJC/FdE5Uf3y3KkYs0/22QS3l57W9yhkVn+7P29ZrHJ+bA5ENTsIFIutqLKIMbsJXE+6UVsaN2wuhxnJnqrOH6I26IknY4fC01+5OevSV7Bhj3GKNvD4y59RL43JvWSn0TgfUNh+YIpu5WdtnaN1ybU+wy92L3HMl4pDFa3WOYA77UJV3guutgh0vTzpb6uZQAbiGerIofgfmpZ3h7QkkWxuluirjTrNoS1CvWTSY/Wk6pzCYzBkanMkynqPQ/H/7Kyu137QMTbIuzMkzTsCqOYRkHEdkuTZgZ5h7OgBJST7xp38z29E9VGSJh1qivU39thlAsHXHF7YKBHNDGcsfDicYByRzICn0CyfGHTXzwL4YpPEvdjDMblMzmUNFIHJcN3s3KnIqLhi81vMQfe+5AdAo/zXuZuf0IbrvQLe9JmExPYPokCIHq9DOAEtIwA==; 5:kbKa9Zf0F55MPFUfWnb4nCGvH2V83AUU+gzyQMgdg0FprBFedXVLCWF4JatYeOZAsX5mNFex1zrXgGVfs+8MMGf9YWht/zeZsHwBuf7j/a4i6hF12UNFwv7re24R6/NA85aXbn9Bhi+cA8IZ3BzclzF9EEzqKevicqmit2YYKa8=; 7:eVVGFCG++PJvI9TznPKfMOlwmOfdUwupcHE6wQDmyGK6Oq6+6w3hYMk2Yt8JpcZPaa/Y+32CP64lBcNeBHuRh5vfpK6MJp3zaYE8XAE92qLzLNfZ+ArdEZI0UZ8St/CeZVdHYrMuTSuEZH7azm+nNgF1+rJxo9Ak3JVEB5Dw51qM73gdZ+ZBgt4V+orq5CNbXDhMuSl9PkkeWUm4AxaGfx+Rz/VrXiJ9wcRqu5YyvTcujhRmnWUkYWBOpPtEp80v SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Oct 2018 05:48:23.0409 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8a4655d8-4d3b-4fcb-cf13-08d62daad34c X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB1544 Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #46: Schema Issue, RFC 7991, In Section 2.29,
                    • , Mixed Content Model 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 05:48:28 -0000 On 2018/10/09 00:46, Henrik Levkowetz wrote: > Hi Julian, > > On 2018-10-08 17:10, Julian Reschke wrote: >>> --- >>> Mixed Content Model >>> >>> The mixed content model for
                    • —- either text and inline elements like >>> sub, sup, bcp14, _or_ ,
                        ,
                        etc, is non-intuitive and may >>> be hard for users to keep straight. >>> >>> Proposal: Consider simplifying the schema by requiring that text >>> and inline elements always are placed within a >>> element. >>> ... >> >> The goal of the current design was to keep simple lists simple, but to >> *allow* more complex lists. >> >> Eliminating the simple form IMHO makes authoring harder,, not easier. > > Understood. I think a distinction could be that it's maybe easier to work, > with once understood, but also maybe harder to grasp. > > It would be good to hear thoughts on this from people who are users but were > not part of the design team, also. Having to add a element just to be able to put text into a list item always struck me as one of the weirdest things in xml2rfc. So please don't do that, thanks! Regards, Martin. From nobody Tue Oct 9 07:12:48 2018 Return-Path: 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 D548F131341 for ; Tue, 9 Oct 2018 07:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Jl537M8Fiawz for ; Tue, 9 Oct 2018 07:12:33 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43A91131374 for ; Tue, 9 Oct 2018 07:12:33 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:58754 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g9skQ-00064H-Na; Tue, 09 Oct 2018 07:12:31 -0700 To: Julian Reschke , xml2rfc-dev@ietf.org, RFC Editor References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> From: Henrik Levkowetz Message-ID: Date: Tue, 9 Oct 2018 16:12:22 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OM1WxxfuT5ug8cuGmM9AFfeuO18PfRQjS" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: rfc-editor@rfc-editor.org, xml2rfc-dev@ietf.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 14:12:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OM1WxxfuT5ug8cuGmM9AFfeuO18PfRQjS Content-Type: multipart/mixed; boundary="lN7ot2gRKqSFIXGEVjAxe1vTbQQoSdMct"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , xml2rfc-dev@ietf.org, RFC Editor Message-ID: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> In-Reply-To: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> --lN7ot2gRKqSFIXGEVjAxe1vTbQQoSdMct Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-10-08 20:05, Julian Reschke wrote: >> So the reason it has not been an issue up to now is because the format= ters >> have been doing 'magic'. The introduction of a normative xml format m= akes >> that problematic. I believe that the output of the preptool should id= eally >> not leave it up to the formatters to do any magic at all; the content = should >> fully and completely specify what would go into a formatted output. T= his is >> the underlying issue I see here; apologies if I haven't expressed it w= ell. >> >>> 2) allowing to contain creates a new nestin= g >>> issue. >> In that case, I think I'd be just as happy with having the cont= ain >> a
                        that would hold the two . > I thought about that as well, but then people might get the impression = > that they can control the placement of the references section. >=20 > Again; I don't see anything broken here. This is one of three issues that come down to one more basic question: Should the prepped format fully define the RFC content, or should it leav= e some things up to the formatters? The current specification results in a prepped XML file which does not contain fully specified renderable content for these 3 parts: * Table of Contents * References * Index For all of these, the specification requires that the formatter create some of the content on-the-fly when they render the XML content,=20 effectively adding derived content that was not present in the prepped XML. RFC 7998 says in Section 1, Introduction: " ... In order to ensure as much uniformity in text output as possible across formats (and with the canonical XML itself), there is a desire that the translation from XML into the other formats will be straightforward syntactic translation. To make that happen, a good amount of data will need to be in the XML format that is not there today. That data will be added by a program called the "prep tool", which will often run as a part of the xml2rfc process." Given this statement, it seemed to me that we should make the prepped format as complete as possible. The current preptool implemented in xml2rfc does this; it inserts a complete representation of ToC (if requested), an enclosing references section, and an Index (if requested).= Issue #49 is a result of implementing this, as providing the enclosing References section could not be done with the original schema specificati= on. If we don't provide a way to actually include fully specified ToC, References, and Index in the prepped output, we need to go back and look at what RFC 7998 says about this, and reconsider the goal of running the preptool. Best regards, Henrik --lN7ot2gRKqSFIXGEVjAxe1vTbQQoSdMct-- --OM1WxxfuT5ug8cuGmM9AFfeuO18PfRQjS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu8t0cACgkQTptXS4+7 FxpX4RAAwHZVeDZgje3Q5T77XO1tnANRyoGUI2mjQJRaQ7G2eGDAQDXu8oMpbxvZ dBFo9zTt2EdCORMcyD74pJPHGmjhmZVJu5EjwE49KwTYdL7sCBbJjuGNbl2qWEjR GP0fvjD/c+VZYTMMr4sSTQGlNVdVbU5Gj+ysawAgldpYjTz3RNdKvFs3WLX/n9eE 2KEeUZ4J5bjJDSgxC8Ywfjrqj02exnY5q/97LsVMlrUJnhBmkAFseQl0CR+qC0EG l0bzfxoAM4dVjC0UAnD6M69UdOA/RBVkVH7sggnFBhez0nVCFlPdsaepVt2dH2GT 56Gt4o/NdAdnO/fK/3bVyFsWlu4CG/B9W98QZE6EyEaQOIoLehNafQXNtMLovXdZ UcxthRVNUD5uWRHestrVo4+RezX9f0ckW1H8QKGd+bVxpSpuFkQjlA9E1ArXfURy ZLrl+02wrNpN1lsxp62UwKbg+/z+pAGLNgGPcfWErHm7EQoOcXKlkCds36YM8Wd/ KTgl8wJ0DVC/QAPuec2aBO/pQLMYMBnjgWDcBGygDNb1zsI8xX/dzWMjz2+zLvV0 GIhRCb+fIXpyLtgp+sK1RJs790mY08u1/WZHzrBpjjtAWu33oM0DD6wOAudpqFDp IBj/gvVssaQWpGgDZ3e+6yGqk80YfcncK9FPgkNbvn6e2uX8fsw= =goDj -----END PGP SIGNATURE----- --OM1WxxfuT5ug8cuGmM9AFfeuO18PfRQjS-- From nobody Tue Oct 9 08:05:25 2018 Return-Path: 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 B0C7713133B for ; Tue, 9 Oct 2018 08:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 LvTIJyeTcymo for ; Tue, 9 Oct 2018 08:05:21 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 479B5131338 for ; Tue, 9 Oct 2018 08:05:21 -0700 (PDT) Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MRocn-1gGk8X2tq5-00Suvf; Tue, 09 Oct 2018 17:05:04 +0200 Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MRocn-1gGk8X2tq5-00Suvf; Tue, 09 Oct 2018 17:05:04 +0200 To: Henrik Levkowetz , xml2rfc-dev@ietf.org, RFC Editor References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> From: Julian Reschke Message-ID: <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> Date: Tue, 9 Oct 2018 17:05:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:1I+q4k1fNKVY+EjWIw98wMdLpRgVGplVTN2wduPQStb0tyOg4Ns 7q5GpEQcTfw1NaTUO1dIN8cnDalboUg3YkqmzK8aJPODYpHJgjjUV2UPM9qJNfpWf2m+nVc jUkXGZgX0oTLrsWc99i2/k/HMOgtuEr4j3nGC0L/i6SRebos/GJ9fsA9zVd+GPfixYpOSy0 1oyICPmzVnAnEUzejYQ6g== X-UI-Out-Filterresults: notjunk:1;V01:K0:153vMsgMr58=:e3+2Et8kPeK2SeWuqE6Cg1 Lbn578NLqjuSZvZqUwnCto86MehmNhMoB15+6kTR4offFz16rMTSYpLonPcZUifaUe04meOWo IQUxkEllrXKsQ8aDi8dC6Q0ntqdQ0hQSP/lhJN3f+1F2Ui6DUDhiHvnLHO0Fsw3KJirnvEeTY lccfu39FHYxLqoA36DYwc4FymMOrNYUCOvDN2VdtxEnX+Zc1RcD+VXx3MHX40ZZdAnvyCDc/l UrixWDss+eiF0SqOi/gx+OE7++i4Q3iNnOR77F2q9wUllL5SCJohWqXWpeQVm7iG2Kc7asc/I 9NXH5Yy7cgXQ6Nav6YQor/MCQ6pNRbZTORIznYvddsr4zyXdDZq5whhAXAxUjL/SixU608KRX GGwh+kxylmaxsWECYORPlreRhG8z9gVanOeFQyC8rEtZfG3fikttHoJnDJ1ar21hC/CdiLoN5 KWA1qFL69lX/HOmUttl9F5aTOP0rcJr8MkWnsGjXoyJcD0jkjk2ynLeHSCkruwS8DFfZN5mz6 3qhj4vVkPsTpxIdld9JxwooBt0guFpb0bTyylVykUSNhWM2ALFHuCacko4aRDqBIN94zGOEu/ 5qJ1nNqr2O2ZGcXE2VcdpDz8OJ5tcaRooYN8n4R9Sb3aW1qQqrTIOQKVfKHdoFBXMNagW+4B6 acUUlPnsBy0nAuoZCRKLvJpTrfpj+3rH6RyN6TYAEBKOFXmaxlhElisTzAvAl8e7zNeLygrI9 ZiXfSJuhCZlqfGBoGXNj8ZjAIWJfFemXV69Bz1ZfVQJqIRydusdWK3aPU2mXJEK2zAbitfMoz aUuHc5oL2ZKNdfk3yB+kjvlZrSFxw7Q1z3hg1pVVjvMxX1N/+M= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 15:05:24 -0000 On 2018-10-09 16:12, Henrik Levkowetz wrote: > ... > This is one of three issues that come down to one more basic question: > > Should the prepped format fully define the RFC content, or should it leave > some things up to the formatters? > ... IMHO: it depends on how intrusive the change to the vocabulary is. > The current specification results in a prepped XML file which does not > contain fully specified renderable content for these 3 parts: > > * Table of Contents > * References > * Index > > For all of these, the specification requires that the formatter create > some of the content on-the-fly when they render the XML content, > effectively adding derived content that was not present in the prepped > XML. Yes. Note that of the three examples, two fall into the same category (index, ToC), and the other one (references) is very different. For index and ToC, the formatter output is essentially unspecified. I don't think this is a problem, *because* it's fully derived content that is only decorative. Whether it's there or not does not affect the actual meaning of the document; it's just to help navigation. For references, the situation is a slightly different; the output of the prep tool does not contain the container element if there are multiple references sections. We *did* discuss this, and we concluded that changing the vocabulary just so that the formatter doesn't need to derive it wasn't necessary. Reminder: as author of a processor you are free to augment the intermediate format with any information you want. But that doesn't mean it needs to surface in the author visible vocabulary. > RFC 7998 says in Section 1, Introduction: > > " ... In order to > ensure as much uniformity in text output as possible across formats > (and with the canonical XML itself), there is a desire that the > translation from XML into the other formats will be straightforward > syntactic translation. To make that happen, a good amount of data > will need to be in the XML format that is not there today. That data > will be added by a program called the "prep tool", which will often > run as a part of the xml2rfc process." > > Given this statement, it seemed to me that we should make the prepped > format as complete as possible. The current preptool implemented in > xml2rfc does this; it inserts a complete representation of ToC (if > requested), an enclosing references section, and an Index (if requested). It would be helpful if you could paste snippets for ToC and index - to keep a valid XML representation, they'd need to live in /
                        right? Is inserting these containers not a problem in itself? What happens if you re-run the preptool on the prepped XML? > ... Best regards, Julian From nobody Tue Oct 9 08:17:21 2018 Return-Path: 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 BDC79131340 for ; Tue, 9 Oct 2018 08:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 enYqEzsWbhKT for ; Tue, 9 Oct 2018 08:17:18 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19D39131338 for ; Tue, 9 Oct 2018 08:17:18 -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; Tue, 9 Oct 2018 08:17:16 -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; Tue, 9 Oct 2018 08:17:15 -0700 From: Paul Hoffman To: XML Developer List Thread-Topic: [Ext] [xml2rfc-dev] RFC 7991 issue #46: Schema Issue, RFC 7991, In Section 2.29,
                      • , Mixed Content Model Thread-Index: AQHUX+Mp/X7zdbGCNEWXXxL4IBfmWg== Date: Tue, 9 Oct 2018 15:17:15 +0000 Message-ID: References: <061301d45f25$a333d9e0$e99b8da0$@augustcellars.com> In-Reply-To: <061301d45f25$a333d9e0$e99b8da0$@augustcellars.com> 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=_315A3923-A609-49B7-A86D-AF80D7A925FF"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #46: Schema Issue, RFC 7991, In Section 2.29,
                      • , Mixed Content Model 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 15:17:20 -0000 --Apple-Mail=_315A3923-A609-49B7-A86D-AF80D7A925FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 8, 2018, at 9:40 AM, Jim Schaad wrote: > I am neutral on this one. I don't think that it really makes things = either easier or harder by having or not having the required = element. I would say keep things as they are until it is proven that = this is a problem. I agree with Jim (neutral, want to hear if it is an issue for others to = learn). I also agree with Henrik: it would be great to hear from other = folks who weren't on the design team about this. --Paul Hoffman= --Apple-Mail=_315A3923-A609-49B7-A86D-AF80D7A925FF Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAwOTE1MTcxNVowIwYJKoZIhvcNAQkEMRYEFOdMuew1VxOHeuCgjEe2D3WLm9EbMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQCpyaWMN0tPso+gpCzF8NreiPWxd7Mdufw/GN+4YaLkxirMGcXMyUylngjydHwaNxw7rtUN Pf/gaAHIAPFP041jjRQCvUb8TdqEHGRceBUF06e0O9f5aQPxugTFbIx+jiHS6szeLg8eVr2nkwGl IJICZBbjkhUnkc5KdbqerQ7Nzv3LSXKaDVswJ63NevLuaRa6QXeCnFM4NO6Iv/0bF0jKsV55kvP0 vYjbE3kmhTFphQOrnpfNCDt135jb4LSQ9woze2Zv3XvviZd1/6qpxuj4AHl7SAK1bf/fPEIr4116 J1bQ3y0CAgOgBtnEFYz4W4P5JuSnlgDpMMDFv92pvzdPAAAAAAAA --Apple-Mail=_315A3923-A609-49B7-A86D-AF80D7A925FF-- From nobody Tue Oct 9 08:24:29 2018 Return-Path: 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 46A10131340 for ; Tue, 9 Oct 2018 08:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 nS5R8ci8hfHE for ; Tue, 9 Oct 2018 08:24:21 -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 0DD01131343 for ; Tue, 9 Oct 2018 08:24:19 -0700 (PDT) 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 Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 9 Oct 2018 08:24:17 -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; Tue, 9 Oct 2018 08:24:17 -0700 From: Paul Hoffman To: XML Developer List Thread-Topic: [Ext] [xml2rfc-dev] RFC 7991 issue #45: Schema Issue, RFC 7991, In Section 2.29,
                      • , Unordered lists with arbitrary symbols Thread-Index: AQHUXxW3dbHnTORrsU+5vKxWCo2o4aUXf3UA Date: Tue, 9 Oct 2018 15:24:16 +0000 Message-ID: <2EF60FD6-22C7-455D-A07D-A6DADF340E13@icann.org> References: In-Reply-To: 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=_D487A4ED-391B-4A5C-BC80-22F97979237B"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #45: Schema Issue, RFC 7991, In Section 2.29,
                      • , Unordered lists with arbitrary symbols 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 15:24:23 -0000 --Apple-Mail=_D487A4ED-391B-4A5C-BC80-22F97979237B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 8, 2018, at 7:46 AM, henrik@levkowetz.com wrote: > --- > Unordered lists with arbitrary symbols >=20 > When
                      • is used with
                          , the rendering is under- > specified (the specification says 'no label will be shown", but = doesn't > say whether list indentation (leading white-space) should be = eliminated > or not. >=20 > If the intention is to make it possible to render unordered lists = with > arbitrary symbols, chosen on a per-list-item basis, the current > attributes of
                        • are insufficient to indent and line-wrap list = items > properly with
                            . >=20 > It is not possible, for instance, to use
                              lists to generate XML = for > a table of content, since if the width of the bullet (the section > number, in this case) is unknown, the proper indentation and line > wrapping cannot be determined. >=20 > Proposal: Add an explicit "bullet" attribute to support this = use > case. >=20 > Implementation: None in the current version of xml2rfc, but = internally > bullets are taken a configurable bullet list, so > accommodating such an attribute would be trivial. I am not in favor of this. "The labels on the items will be symbols = picked by the formatter" still seems correct. For the use case given here (the table of contents has a variable width = first element), the text in Section 6.6 of RFC 7992 still seems = adequate. --Paul Hoffman --Apple-Mail=_D487A4ED-391B-4A5C-BC80-22F97979237B Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAwOTE1MjQxN1owIwYJKoZIhvcNAQkEMRYEFHGl6FWsdhPnoQhF48Bz9GVYN+SGMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQChsoGiLKXeK9xa71GyxOCXzfNQtzsA++EaLsIoAKOB+/JREQpI3q5ROwnfRUM1F+wqZqBS lSRcqT+jNHxDlLh7rsff17OnKf3ybtCvqvSt7WYCzeCTtRS1dxmqrjm0oX68LvdqvY1lrMZKJEkS vqglY/sas0fgzVWeOzmS+9c22G38UTkdMVgVId38UQrHCEG9qdRPqYfH3iYJ4akXyxE2BMVee3hC OvVQQVPKtH/gJxhOnXjNC9KGnQO5zjn1PtxsmB96PlVOs4x+SnGF1X5vzynm1qCa/BGV6oxEc+2P ZqzimIGHMB9508vkg+5btv0lTJdVbRI9ZigojLI+oWa9AAAAAAAA --Apple-Mail=_D487A4ED-391B-4A5C-BC80-22F97979237B-- From nobody Tue Oct 9 08:56:56 2018 Return-Path: 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 0F4C013135F for ; Tue, 9 Oct 2018 08:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 X9NBrKS_dnWw for ; Tue, 9 Oct 2018 08:56:48 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E33131379 for ; Tue, 9 Oct 2018 08:56:48 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:59282 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g9uNL-0002nz-Bj; Tue, 09 Oct 2018 08:56:48 -0700 To: Julian Reschke , xml2rfc-dev@ietf.org, RFC Editor References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> From: Henrik Levkowetz Message-ID: Date: Tue, 9 Oct 2018 17:56:39 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6HXmnpEQnBvmDdCDQO5Q6dha4VerKGcBK" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: rfc-editor@rfc-editor.org, xml2rfc-dev@ietf.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 15:56:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6HXmnpEQnBvmDdCDQO5Q6dha4VerKGcBK Content-Type: multipart/mixed; boundary="o2qGLMclBcggWoStBlk4hWTOXkqsOgrm0"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , xml2rfc-dev@ietf.org, RFC Editor Message-ID: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> In-Reply-To: <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> --o2qGLMclBcggWoStBlk4hWTOXkqsOgrm0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-10-09 17:05, Julian Reschke wrote: > On 2018-10-09 16:12, Henrik Levkowetz wrote: >> ... >> This is one of three issues that come down to one more basic question:= >>=20 >> Should the prepped format fully define the RFC content, or should it l= eave >> some things up to the formatters? >> ... >=20 > IMHO: it depends on how intrusive the change to the vocabulary is. >=20 >> The current specification results in a prepped XML file which does not= >> contain fully specified renderable content for these 3 parts: >>=20 >> * Table of Contents >> * References >> * Index >>=20 >> For all of these, the specification requires that the formatter create= >> some of the content on-the-fly when they render the XML content, >> effectively adding derived content that was not present in the prepped= >> XML. >=20 > Yes. >=20 > Note that of the three examples, two fall into the same category (index= ,=20 > ToC), and the other one (references) is very different. >=20 > For index and ToC, the formatter output is essentially unspecified. I=20 > don't think this is a problem, *because* it's fully derived content tha= t=20 > is only decorative. Whether it's there or not does not affect the actua= l=20 > meaning of the document; it's just to help navigation. >=20 > For references, the situation is a slightly different; the output of th= e=20 > prep tool does not contain the container element if there are multiple = > references sections. We *did* discuss this, and we concluded that=20 > changing the vocabulary just so that the formatter doesn't need to=20 > derive it wasn't necessary. >=20 > Reminder: as author of a processor you are free to augment the=20 > intermediate format with any information you want. But that doesn't mea= n=20 > it needs to surface in the author visible vocabulary. Agreed. But that's a somewhat different issue. Here I'm concerned with the incompleteness of the published archival XML, in view of the RFC7998 statement below, rather than whatever bells processors may choose to add.= >=20 >=20 >> RFC 7998 says in Section 1, Introduction: >>=20 >> " ... In order = to >> ensure as much uniformity in text output as possible across format= s >> (and with the canonical XML itself), there is a desire that the >> translation from XML into the other formats will be straightforwar= d >> syntactic translation. To make that happen, a good amount of data= >> will need to be in the XML format that is not there today. That d= ata >> will be added by a program called the "prep tool", which will ofte= n >> run as a part of the xml2rfc process." >>=20 >> Given this statement, it seemed to me that we should make the prepped >> format as complete as possible. The current preptool implemented in >> xml2rfc does this; it inserts a complete representation of ToC (if >> requested), an enclosing references section, and an Index (if requeste= d). >=20 > It would be helpful if you could paste snippets for ToC and index - to = > keep a valid XML representation, they'd need to live in /=20 > right? Is inserting these containers not a problem in itself? What=20 > happens if you re-run the preptool on the prepped XML? For both the preptool and the v2v3 converter, I've tried to make them idempotent, so you should be able to run the output through the processor= again with no change. Here's a ToC snippet. I'm not claiming this is optimal; if we reach consensus on what 7998 requires, we can look at other implementations:
                              Table of Contents<= /name>
                              • . RFC 2119 key words
                              • . Unordered list with sub-elements
                              • . Ordered list with sub-elements
                              And here's the start of an index:
                              Index L T
                              • L
                                • list list list .... Best regards, Henrik --o2qGLMclBcggWoStBlk4hWTOXkqsOgrm0-- --6HXmnpEQnBvmDdCDQO5Q6dha4VerKGcBK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu8z7cACgkQTptXS4+7 FxquuBAA1znhMlVb4Qk66TXklSiZ8BhTkL6/4uilYZJxamU1U3krzkNsnrUdxL9L OP7xSc6mtjSQPBmce+VCBADOtM8UcjNuHiavCGUeLkF44w6kugyQahPL/4Yp35pP SSryEzuTt5B5gIfXpJS8atpibccMk1yFLMMMUul443KVN+Ka09JwmlFR2C11gBYp iZXUdlX3YnMclrUW1Z8gfeUrV2XiwD4/+h7dHcRxtN9yrRxaiqAMhhd2upn6Mxgr zNenclO/CApvC+qXBFO3J3GgFlsYqxPihjhfaQ/m5cyYfbUDs79KXFhneVRZNrsl 3XjPRWmYicUwKlAE1amBZ093+66bRkqd3AzTrn0/FuTHmINcsMnOecKeK4/n2weq my6e4pAd15YdJ1waBvXU9Te+YN3ol8tAtYhP6SVsrg93Bu8S25EijLAyACPulRFR mFK6gsbMKnRU/vYIeitOF9jpWBrgYJSywKcChUBRr9qdn+ebAK53tsPdqxp546Yg NxcpyLg+7rsAAZGmA5/hu8Slo05M+EtoSHLuL3dVk4hhh4oMn613vbMK8xg25W/U gAhOyFcgzcgKyvMA3S2R0g3lFVOJVzlLK5ogydgXNmJnHx2PCzCgXf3dM7E2+2SS ImFSVmTyPRpVQCR0x/LHlkJnO+fbDKqedD6YA1aKpu2r9vKEDEk= =51WR -----END PGP SIGNATURE----- --6HXmnpEQnBvmDdCDQO5Q6dha4VerKGcBK-- From nobody Tue Oct 9 09:01:17 2018 Return-Path: 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 17C7113135A for ; Tue, 9 Oct 2018 09:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 QdU5sJ4kb2kd for ; Tue, 9 Oct 2018 09:01:13 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EC6B13134F for ; Tue, 9 Oct 2018 09:01:13 -0700 (PDT) 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 Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 9 Oct 2018 09:01:11 -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; Tue, 9 Oct 2018 09:01:11 -0700 From: Paul Hoffman To: XML Developer List Thread-Topic: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, Thread-Index: AQHUX+lLsVSWdSZ61Uyh9oDK5qPd9w== Date: Tue, 9 Oct 2018 16:01:10 +0000 Message-ID: References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> In-Reply-To: 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=_6B3ED98E-F63D-4C94-9118-8ABAE9597904"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 16:01:15 -0000 --Apple-Mail=_6B3ED98E-F63D-4C94-9118-8ABAE9597904 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 9, 2018, at 8:56 AM, Henrik Levkowetz = wrote: > Agreed. But that's a somewhat different issue. Here I'm concerned = with > the incompleteness of the published archival XML, in view of the = RFC7998 > statement below, rather than whatever bells processors may choose to = add. That is indeed a different issue. Is the problem that you're trying to = solve here that an RFC that has a reference to BCP X or STD Y does not = say what are the contents of X or Y at the time of RFC publication? --Paul Hoffman= --Apple-Mail=_6B3ED98E-F63D-4C94-9118-8ABAE9597904 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAwOTE2MDExMFowIwYJKoZIhvcNAQkEMRYEFBp+trPb5AlQGuQ91k0CqBfYuftuMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQCQumc+EsjUB303x5whT1TItZnBS4EXGVEIZBJyNu/Do51mOU3HaDfQaMc0ujED539tcMz5 AB2y+Or1fU+12j+FDRHgINoCq17If7/VVzCc4DqnYlUraSY7bsmJ5gPXmDyNkdJhdUaRe8/6YwHQ DWOMStleViYN4vOWyEIODXkRYdF4v4talGSAB3JDutDosp+aliPORtw6eZ3jEuAA1AJEmg6a31bY YS5SBxdmapKLBxYWxFFKDAPXoZ11yZjngdSdy9bzbSWSsGoGiaR82iFDTbVXooq9gV3gKZaAl1dh uawVzCIOlrBMLRuJLJTojOynnf2yQbWVVNE0TlIm7TFJAAAAAAAA --Apple-Mail=_6B3ED98E-F63D-4C94-9118-8ABAE9597904-- From nobody Tue Oct 9 09:14:09 2018 Return-Path: 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 C9319131343 for ; Tue, 9 Oct 2018 09:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 tHYAzDQ71Ghs for ; Tue, 9 Oct 2018 09:14:07 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32F6C131364 for ; Tue, 9 Oct 2018 09:14:07 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:59354 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g9ue4-0006SJ-1h; Tue, 09 Oct 2018 09:14:05 -0700 To: Paul Hoffman , XML Developer List References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> From: Henrik Levkowetz Message-ID: <8726dc12-ebd3-67fe-00c8-7cc1c99b4a27@levkowetz.com> Date: Tue, 9 Oct 2018 18:13:55 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uhpMGOX5p7S0LcKVS0bwaHu0fgvbpk1Ut" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, paul.hoffman@icann.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 16:14:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uhpMGOX5p7S0LcKVS0bwaHu0fgvbpk1Ut Content-Type: multipart/mixed; boundary="ogwIjEX6gPkLpwAtf4JDclc4WGi90gSQO"; protected-headers="v1" From: Henrik Levkowetz To: Paul Hoffman , XML Developer List Message-ID: <8726dc12-ebd3-67fe-00c8-7cc1c99b4a27@levkowetz.com> Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> In-Reply-To: --ogwIjEX6gPkLpwAtf4JDclc4WGi90gSQO Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Paul, On 2018-10-09 18:01, Paul Hoffman wrote: > On Oct 9, 2018, at 8:56 AM, Henrik Levkowetz wro= te: >> Agreed. But that's a somewhat different issue. Here I'm concerned wi= th >> the incompleteness of the published archival XML, in view of the RFC79= 98 >> statement below, rather than whatever bells processors may choose to a= dd. >=20 > That is indeed a different issue. Is the problem that you're trying > to solve here that an RFC that has a reference to BCP X or STD Y does > not say what are the contents of X or Y at the time of RFC > publication? Not at all. The current schema does not permit the generation of a prepped XML that h= as the content and structure that a renderer is expected to render. You could say (see below) that the schema does not make it possible to produce a prepped XML that permit a "straightforward syntactic translatio= n" (RFC 7998). For this particular issue (#49), the XML of a document with multiple reference section cannot with the current schema capture the enclosing References section which a formatter is expected to show (and for that matter, which a ToC is expected to show, correctly numbered, with correct= ly numbered Normative and Informative sub-sections). This is one of three issues that come down to one more basic question: Should the prepped format fully define the RFC content, or should it leav= e some things up to the formatters? The current specification results in a prepped XML file which does not contain fully specified renderable content for these 3 parts: * Table of Contents * References * Index For all of these, the specification requires that the formatter create some of the content on-the-fly when they render the XML content,=20 effectively adding derived content that was not present in the prepped XML. RFC 7998 says in Section 1, Introduction: " ... In order to ensure as much uniformity in text output as possible across formats (and with the canonical XML itself), there is a desire that the translation from XML into the other formats will be straightforward syntactic translation. To make that happen, a good amount of data will need to be in the XML format that is not there today. That data will be added by a program called the "prep tool", which will often run as a part of the xml2rfc process." Given this statement, it seemed to me that we should make the prepped format as complete as possible. The current preptool implemented in xml2rfc does this; it inserts a complete representation of ToC (if requested), an enclosing references section, and an Index (if requested).= Issue #49 is a result of implementing this, as providing the enclosing References section could not be done with the original schema specificati= on. If we don't provide a way to actually include fully specified ToC, References, and Index in the prepped output, we need to go back and look at what RFC 7998 says about this, and reconsider the goal of running the preptool. --ogwIjEX6gPkLpwAtf4JDclc4WGi90gSQO-- --uhpMGOX5p7S0LcKVS0bwaHu0fgvbpk1Ut Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu808MACgkQTptXS4+7 FxqDfw/9FV+q+Mm/BGxlq9YFZHLlJXdKnv0A0LWRMCbtATuWKl6Dq0qDR7ZRl36k a0iX7DyoFqsVAvWWcdfrDmdijyoffm2F886O5PqUKlJl2r9QiIg6oXpaqx0xHC1M 6xQvbivZGQLqBYrd3w42KtT593dFpq24lvRh8eL4wlSGAXjpbcfX6/7RqjkOdZmw 9bMBp2sAcIBVct/kk0hLRIp1nOAXPTXj6+32HtIR/nd88CEC7kIi784bQKA30Cah 7pVVfYYVurpiNUiG43517243+OW1HTlkYawe5thxQMEMibE9qUI36qNGLXTFJKCA K/qq7PsZolFshbJi7ghAPR+zaB77BNNj8fTsnfsitD5uQcbrmKpu44GDE19NDTQ8 itrjKFGrZ1awgk3fEoTrODGcJfMCUB/epoGdl3pv3L5W3x2X/xIupKAWAMyIvRgN hi0P1IM2DZXlIk5GqV6VlSWjhxf/OOyxOEnSihw1uBVrHf2FFHpf9gMTA4gwzU7/ 3nc95CL4NtNIsUExGqMxC57nTte2pPtTCyDNs3097NhWakXsrZmahff5y5uTjUzu q/yy/Q8f1Ph9T+7vBaLYBwwlIPcHnpcHVt2vrIs2KrkNnPlWgYWdNgiqgvFLBb9F 0uq60LovdIc0OpqMtENRp4j+JEQg11ZGWkXAF10pxNOMeX/9Cq8= =JaCe -----END PGP SIGNATURE----- --uhpMGOX5p7S0LcKVS0bwaHu0fgvbpk1Ut-- From nobody Tue Oct 9 09:54:07 2018 Return-Path: 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 7CDB7131376 for ; Tue, 9 Oct 2018 09:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 1xDIGoQi1-qT for ; Tue, 9 Oct 2018 09:53:55 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47C01131398 for ; Tue, 9 Oct 2018 09:53:52 -0700 (PDT) Received: from Jude (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 9 Oct 2018 09:49:08 -0700 From: Jim Schaad To: 'Henrik Levkowetz' , 'Julian Reschke' , , 'RFC Editor' References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> In-Reply-To: Date: Tue, 9 Oct 2018 09:53:41 -0700 Message-ID: <072001d45ff0$a403cfd0$ec0b6f70$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKMgMAK0VYejNR5SBI3Ju6yzqYpwAJgfmWrAYJ4yUYC/7eaQwLlkh8fo1idHwA= Content-Language: en-us X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 16:54:07 -0000 > -----Original Message----- > From: xml2rfc-dev On Behalf Of Henrik > Levkowetz > Sent: Tuesday, October 9, 2018 7:12 AM > To: Julian Reschke ; xml2rfc-dev@ietf.org; RFC = Editor > > Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, = In > Section 2.42, >=20 > On 2018-10-08 20:05, Julian Reschke wrote: > >> So the reason it has not been an issue up to now is because the > >> formatters have been doing 'magic'. The introduction of a = normative > >> xml format makes that problematic. I believe that the output of = the > >> preptool should ideally not leave it up to the formatters to do any > >> magic at all; the content should fully and completely specify what > >> would go into a formatted output. This is the underlying issue I = see here; > apologies if I haven't expressed it well. > >> > >>> 2) allowing to contain creates a new > >>> nesting issue. > >> In that case, I think I'd be just as happy with having the > >> contain a
                                  that would hold the two . >=20 > > I thought about that as well, but then people might get the = impression > > that they can control the placement of the references section. > > > > Again; I don't see anything broken here. >=20 > This is one of three issues that come down to one more basic question: >=20 > Should the prepped format fully define the RFC content, or should it = leave some > things up to the formatters? >=20 > The current specification results in a prepped XML file which does not = contain > fully specified renderable content for these 3 parts: >=20 > * Table of Contents > * References > * Index >=20 > For all of these, the specification requires that the formatter create = some of > the content on-the-fly when they render the XML content, effectively = adding > derived content that was not present in the prepped XML. >=20 > RFC 7998 says in Section 1, Introduction: >=20 > " ... In order = to > ensure as much uniformity in text output as possible across formats > (and with the canonical XML itself), there is a desire that the > translation from XML into the other formats will be straightforward > syntactic translation. To make that happen, a good amount of data > will need to be in the XML format that is not there today. That = data > will be added by a program called the "prep tool", which will often > run as a part of the xml2rfc process." >=20 > Given this statement, it seemed to me that we should make the prepped = format > as complete as possible. The current preptool implemented in xml2rfc = does > this; it inserts a complete representation of ToC (if requested), an = enclosing > references section, and an Index (if requested). >=20 > Issue #49 is a result of implementing this, as providing the enclosing > References section could not be done with the original schema = specification. >=20 > If we don't provide a way to actually include fully specified ToC, = References, > and Index in the prepped output, we need to go back and look at what = RFC 7998 > says about this, and reconsider the goal of running the preptool. The problem is that I don't think that you can do a fully specified ToC = or Index as how these are going to be presented are going to be = extremely renderer specific. What is there for HTML vs a paged format = are completely different and for the paged format requires that the page = no be computed. Also, how indexing is presented for multiple levels = can be very different between renderers. I don't believe that References = suffers from the same problem. Jim >=20 >=20 > Best regards, >=20 > Henrik >=20 >=20 From nobody Tue Oct 9 10:02:41 2018 Return-Path: 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 3DB7513135D for ; Tue, 9 Oct 2018 10:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=miek-nl.20150623.gappssmtp.com 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 M5Xi6FjbE-Ee for ; Tue, 9 Oct 2018 10:02:37 -0700 (PDT) Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D64A131332 for ; Tue, 9 Oct 2018 10:02:37 -0700 (PDT) Received: by mail-yb1-xb30.google.com with SMTP id e190-v6so954649ybb.5 for ; Tue, 09 Oct 2018 10:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=miek-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o2VnqBP/04AF8Sl/mEOl7DOUAyfJKlPbKEOrzQfXZrw=; b=qFK1lY/IsMue6y/3rChLm6QgOaAI1yPKNEJbiru9t84qxzSc3Vz5NvA4oy8X4uBwPX NGHXOBst9M8G1fDw6sAjCOcwyJaEcJbhNcaxVmbkW9MUTfpUKzWhY6Im/wpfzyo5IwrL e46y8lB2APbhC9NpETrTSlUyf3+UDe8kNhA1UI1cRDnCGkuUDOPsR+ZpUeJ0BwMPgJ7L 6MMrzW7M3d9d1MhkmhaYmX4gACXcAnMm6MHEbYQrF1XE29ngCjigDa/N7YMI4o1/Qirz 1J2fyO99vB1i8S+l1COjreLuNkV0lV8SRXSXFBL3mPmRNZp9qWsqaA2dN4Fry8hGfzTU Rk0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o2VnqBP/04AF8Sl/mEOl7DOUAyfJKlPbKEOrzQfXZrw=; b=YLIp7MYIIBFjbRJ3EOlCDreP91NmfXJJYmTSfI1WFcLnO84VrO3DXpYETIMuY9tLf2 yflPMAGQgkCzI3g9Ejdp6n2QbN4hVx8a8L9dmS7ddVtdt6dmsmw0FOFxMbV/3ZbOL0+T Qp+2Q2GQvIY1xDOv1EkzmkJEiWKRwmXYxwMEb35qaD1tAwj8ETygdKjpiM5nfmm3s9wU hqa7r6j3y3QCPzVz7T3ssRXhPKIY7OJiEBgYWQ61f9ZVLwsDwJ0OB4lcOX9vmv9kUACE VhGkq7QOc9pv6ggDg94ua1sMCxlMkN4ktLFK3FWOhH1mYDuCMC5HljerMp4ZyEN9GeSt MULw== X-Gm-Message-State: ABuFfog+pHD1eWlsvcuWs+OU9jRy44fYmY5FS7rxEa3ucF3WIgn87622 G8ecLsyzrndenh1AnltFwhvI1Z5gF5j9A9Ec83U+j4XK X-Google-Smtp-Source: ACcGV63+v3WCGKdQDlzyQlfHJrGI4qkDdry0qchfUNMQStXorU21KWOpERyIMfdJMMAqFSyvCxDVR+jGbX2vU7bbXLE= X-Received: by 2002:a25:948:: with SMTP id u8-v6mr16110815ybm.301.1539104556541; Tue, 09 Oct 2018 10:02:36 -0700 (PDT) MIME-Version: 1.0 References: <061301d45f25$a333d9e0$e99b8da0$@augustcellars.com> In-Reply-To: From: Miek Gieben Date: Tue, 9 Oct 2018 17:57:37 +0100 Message-ID: To: Paul Hoffman Cc: XML Developer List Content-Type: multipart/alternative; boundary="0000000000005d7c630577ceb46b" Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #46: Schema Issue, RFC 7991, In Section 2.29,
                                • , Mixed Content Model 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 17:02:40 -0000 --0000000000005d7c630577ceb46b Content-Type: text/plain; charset="UTF-8" I agree with keeping the current semantics. It also not hard to compile markdown to it. On Tue, 9 Oct 2018, 16:17 Paul Hoffman, wrote: > On Oct 8, 2018, at 9:40 AM, Jim Schaad wrote: > > I am neutral on this one. I don't think that it really makes things > either easier or harder by having or not having the required element. > I would say keep things as they are until it is proven that this is a > problem. > > I agree with Jim (neutral, want to hear if it is an issue for others to > learn). I also agree with Henrik: it would be great to hear from other > folks who weren't on the design team about this. > > --Paul Hoffman_______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc-dev > --0000000000005d7c630577ceb46b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
                                  I agree with keeping the current semantics. It also not h= ard to compile markdown to it.

                                  On Tue, 9 Oct 2018, 16:17 Paul Hoffman, <paul.hoffman@icann.org> wrote:
                                  On Oct 8, 2018, at 9:40 AM, Jim Schaad <iet= f@augustcellars.com> wrote:
                                  > I am neutral on this one.=C2=A0 I don't think that it really makes= things either easier or harder by having or not having the required <t&= gt; element.=C2=A0 =C2=A0I would say keep things as they are until it is pr= oven that this is a problem.

                                  I agree with Jim (neutral, want to hear if it is an issue for others to lea= rn). I also agree with Henrik: it would be great to hear from other folks w= ho weren't on the design team about this.

                                  --Paul Hoffman_______________________________________________
                                  xml2rfc-dev mailing list
                                  xml2rfc-dev@ietf.org
                                  https://www.ietf.org/mailman/listinfo/xm= l2rfc-dev
                                  --0000000000005d7c630577ceb46b-- From nobody Tue Oct 9 10:23:16 2018 Return-Path: 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 AB298127332 for ; Tue, 9 Oct 2018 10:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 Lfl5dXp5GEGs for ; Tue, 9 Oct 2018 10:23:14 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9718126CB6 for ; Tue, 9 Oct 2018 10:23:13 -0700 (PDT) Received: from [192.168.178.20] ([91.61.61.6]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LZiQy-1fOTPO0dw4-00lYMn; Tue, 09 Oct 2018 19:22:46 +0200 Received: from [192.168.178.20] ([91.61.61.6]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LZiQy-1fOTPO0dw4-00lYMn; Tue, 09 Oct 2018 19:22:46 +0200 To: Paul Hoffman , XML Developer List References: <2EF60FD6-22C7-455D-A07D-A6DADF340E13@icann.org> From: Julian Reschke Message-ID: <64aaa1b9-f83c-21c2-037f-b51bee75b573@gmx.de> Date: Tue, 9 Oct 2018 19:22:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <2EF60FD6-22C7-455D-A07D-A6DADF340E13@icann.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:ygcLyCoxJUb7ZK8TaYddD+mdhu/pw9XuNpAYon/jtBZBnzEpIUY QEhFckNmcdfK3FbfBhL1TMEHtyXYhBvRIKusxHnL58I/MiV9f3ObajNnB5pvDe/1Pbe9H8L M+rkK0UOwNOrgY1H+OqhOQTfxw/zxsgtqD6RKQnpT8MlsdF6maBhPmqspZd0K3H9wrKmzRz EfddAsNaa3oYbpL/EsyUA== X-UI-Out-Filterresults: notjunk:1;V01:K0:Vr6/T8rM4eY=:NxeEH4vAZRz+bg+pNievcD mhsyFFbkX97vH8iH6c4XYyuwobibsGa/YH4DmKqLYkI0box3DIKAa8jTt85DVLWq4m4AhuwF5 P3zpBVjI/xa0J+U6c5dRA0UGxgm1gFvO/bxMVg9P51AUoQaQxhw4CXDLWY6UopZctBGlGyL1G dwdH2g9cbxtXQpolPzACn6JS3QmQa9AADt6XNkVzJiZdQ3YLivfiFeympCdLeXCyII0Gws4Re SpiEtoFvChItlAJO7Y2TDVThKGI7rUZVyE7I/SvljrkbJlJfInJao7Sx33HR/YHqMCgk7HwDC fogVpw5csQc3qXsodlR9aiKfbHs3TlkjBCf9IKr5A6jWpf4okXJTZNMy2RQf18JVQ4NzOHG5Q 1hdNysXdYtQJAmwb+UEOyhmnYEr9sqTNSnTnkeTf+U4yjAPhvMAfU9EOLkvb9Aww+7gjbpH/H PZxJCeJxe4ptMkaiPBibF21vSSu9k6+cQ4bl1T/LMp6GI9TESTMsiJedkNnPV+pulSyGBB4PE 6IuFlPTMpkQA9AkIv1H1BI0YPz/9pASn7nezk8mRPiUdF9IKsfjpDL/HV/AgR2+DpcLidPQL+ vtLarTln3JjwwRar4RATrJEhbvx3U4XDYhPi/09yxF31Aqn6PaLUMaMIS7SLpk5Sr6Tq2fIL6 4Hd9Kp+1hO+IN+kaV9Ase5xvO3f8ukp9MtwamoK+p0f3QonCUAS5TmXJ+odyZz4W7S7QXaGhK pOQvla7Lr3gnNWAqxBcVFteXR/oThr20uuDgZIk/OQGMU8MEZaSRQN0Zo0ie7lLsZQjt2nrzp nMDI2K3To517j19RL25Nwk5LmeXWaNFrr9W8FWmgfjWldlj8dA= Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #45: Schema Issue, RFC 7991, In Section 2.29,
                                • , Unordered lists with arbitrary symbols 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 17:23:16 -0000 On 2018-10-09 17:24, Paul Hoffman wrote: > On Oct 8, 2018, at 7:46 AM, henrik@levkowetz.com wrote: >> --- >> Unordered lists with arbitrary symbols >> >> When
                                • is used with
                                    , the rendering is under- >> specified (the specification says 'no label will be shown", but doesn't >> say whether list indentation (leading white-space) should be eliminated >> or not. >> >> If the intention is to make it possible to render unordered lists with >> arbitrary symbols, chosen on a per-list-item basis, the current >> attributes of
                                  • are insufficient to indent and line-wrap list items >> properly with
                                      . >> >> It is not possible, for instance, to use
                                        lists to generate XML for >> a table of content, since if the width of the bullet (the section >> number, in this case) is unknown, the proper indentation and line >> wrapping cannot be determined. >> >> Proposal: Add an explicit "bullet" attribute to support this use >> case. >> >> Implementation: None in the current version of xml2rfc, but internally >> bullets are taken a configurable bullet list, so >> accommodating such an attribute would be trivial. > > I am not in favor of this. "The labels on the items will be symbols picked by the formatter" still seems correct. > > For the use case given here (the table of contents has a variable width first element), the text in Section 6.6 of RFC 7992 still seems adequate. Well, there never was any intent to make the table of contents be rendered as unordered list using
                                          . (FWIW, it's an ordered list anyway). So we really need to discuss the underlying issue (should we able to represent the *contents* of the TOC as XML?). Best regards, Julian From nobody Tue Oct 9 10:29:07 2018 Return-Path: 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 69FDD128D68 for ; Tue, 9 Oct 2018 10:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 gkXQc5K8nuT3 for ; Tue, 9 Oct 2018 10:29:04 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA290128CFD for ; Tue, 9 Oct 2018 10:29:03 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:59821 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g9voc-00029y-Nw; Tue, 09 Oct 2018 10:29:03 -0700 To: Jim Schaad , 'Julian Reschke' , xml2rfc-dev@ietf.org, 'RFC Editor' References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <072001d45ff0$a403cfd0$ec0b6f70$@augustcellars.com> From: Henrik Levkowetz Message-ID: Date: Tue, 9 Oct 2018 19:28:54 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <072001d45ff0$a403cfd0$ec0b6f70$@augustcellars.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CALw3HuWIphBgLLdnHaWqfRvgSniU5n46" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: rfc-editor@rfc-editor.org, xml2rfc-dev@ietf.org, julian.reschke@gmx.de, ietf@augustcellars.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 17:29:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CALw3HuWIphBgLLdnHaWqfRvgSniU5n46 Content-Type: multipart/mixed; boundary="85l5OtxMWuOKxrfA5w1FC6tc3Ruc5vaVp"; protected-headers="v1" From: Henrik Levkowetz To: Jim Schaad , 'Julian Reschke' , xml2rfc-dev@ietf.org, 'RFC Editor' Message-ID: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <072001d45ff0$a403cfd0$ec0b6f70$@augustcellars.com> In-Reply-To: <072001d45ff0$a403cfd0$ec0b6f70$@augustcellars.com> --85l5OtxMWuOKxrfA5w1FC6tc3Ruc5vaVp Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jim, On 2018-10-09 18:53, Jim Schaad wrote: >=20 >=20 >> -----Original Message----- >> From: xml2rfc-dev On Behalf Of Henrik >> Levkowetz >> Sent: Tuesday, October 9, 2018 7:12 AM >> To: Julian Reschke ; xml2rfc-dev@ietf.org; RFC = Editor >> >> Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991,= In >> Section 2.42, >>=20 >> On 2018-10-08 20:05, Julian Reschke wrote: >> >> So the reason it has not been an issue up to now is because the >> >> formatters have been doing 'magic'. The introduction of a normativ= e >> >> xml format makes that problematic. I believe that the output of th= e >> >> preptool should ideally not leave it up to the formatters to do any= >> >> magic at all; the content should fully and completely specify what >> >> would go into a formatted output. This is the underlying issue I s= ee here; >> apologies if I haven't expressed it well. >> >> >> >>> 2) allowing to contain creates a new >> >>> nesting issue. >> >> In that case, I think I'd be just as happy with having the >> >> contain a
                                          that would hold the two . >>=20 >> > I thought about that as well, but then people might get the impressi= on >> > that they can control the placement of the references section. >> > >> > Again; I don't see anything broken here. >>=20 >> This is one of three issues that come down to one more basic question:= >>=20 >> Should the prepped format fully define the RFC content, or should it l= eave some >> things up to the formatters? >>=20 >> The current specification results in a prepped XML file which does not= contain >> fully specified renderable content for these 3 parts: >>=20 >> * Table of Contents >> * References >> * Index >>=20 >> For all of these, the specification requires that the formatter create= some of >> the content on-the-fly when they render the XML content, effectively a= dding >> derived content that was not present in the prepped XML. >>=20 >> RFC 7998 says in Section 1, Introduction: >>=20 >> " ... In order t= o >> ensure as much uniformity in text output as possible across formats= >> (and with the canonical XML itself), there is a desire that the >> translation from XML into the other formats will be straightforward= >> syntactic translation. To make that happen, a good amount of data >> will need to be in the XML format that is not there today. That da= ta >> will be added by a program called the "prep tool", which will often= >> run as a part of the xml2rfc process." >>=20 >> Given this statement, it seemed to me that we should make the prepped = format >> as complete as possible. The current preptool implemented in xml2rfc = does >> this; it inserts a complete representation of ToC (if requested), an e= nclosing >> references section, and an Index (if requested). >>=20 >> Issue #49 is a result of implementing this, as providing the enclosing= >> References section could not be done with the original schema specific= ation. >>=20 >> If we don't provide a way to actually include fully specified ToC, Ref= erences, >> and Index in the prepped output, we need to go back and look at what R= FC 7998 >> says about this, and reconsider the goal of running the preptool. >=20 > The problem is that I don't think that you can do a fully specified > ToC or Index as how these are going to be presented are going to be > extremely renderer specific. What is there for HTML vs a paged format > are completely different and for the paged format requires that the > page no be computed. Also, how indexing is presented for multiple > levels can be very different between renderers. I don't believe that > References suffers from the same problem. Yes, well, I expect I'll run headlong into this, and find out how big an issue it is, when I've now started to work on the v3 HTML renderer, as the current approach will be generating the html from the same XML ToC as= the v3 text renderer ,:-) Best regards, Henrik --85l5OtxMWuOKxrfA5w1FC6tc3Ruc5vaVp-- --CALw3HuWIphBgLLdnHaWqfRvgSniU5n46 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu85VYACgkQTptXS4+7 FxqUrhAAnhUbUhHmvkxoIeNskIAF+2pRLoLjNHV/fi25z6htXbj9R7oJZqpn29hO fvxrKKal9K6tcEu2J07VIvAQqf+TNcB9oQkFDFnlAFby8lkuRfXcGRbDpSGycjMR 0seope+Y8+QKFiNeMzScMlsGmA1onYw0ATMmaGn4jzf72glBLPejpROpNMk6O10U qOVL7CnR5w2Wm69LgVe3OyPbKbTcMiOnROfgi1H5mdp3tVu1zPNH0fQ0G/8bPsyg G2kPlLLB4SI+BFT+xF9yDGAnCXJOZdovsmRa1rG8WbhBdSeE/bZwrBZnAmxQNDLB uj7lo1vm7ouwaoOhaMkG9FJukSFi7PfVEEuPvQLJIoTGwaoJzRXmul7PjPK6xbb+ /eyV427wHdQPX8xcP7NuGblADh4+SveIUhmZvvzGkbA84RJDKwOapN7Q+VrZbEmU 8bZAMr/3dp1MX9N5LwIsaGDK50aZzmo96Xz4aqYumgwc42kNwmaqfUNfUsvYPzXV fs/Dtjk5RKKXuh/s0BH5zLKQSyUcu7tudQBSK3i3T1atwYeZtpiMuj4HouGmVxOx nmt0yhYfrk77ZDuWVL16tqnt88jQ3cfzYKc1Mb2Ly+/B7Fsseh8X8tS759dnLFPO 1Q2c4Kybf7JZH3iwR5NJUbOo246Oll9M8TDReZNy844aQPqD21g= =M7Np -----END PGP SIGNATURE----- --CALw3HuWIphBgLLdnHaWqfRvgSniU5n46-- From nobody Tue Oct 9 10:30:50 2018 Return-Path: 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 893E3130DDC for ; Tue, 9 Oct 2018 10:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 0OReFFBO9nW3 for ; Tue, 9 Oct 2018 10:30:41 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 429E6130DBE for ; Tue, 9 Oct 2018 10:30:40 -0700 (PDT) Received: from [192.168.178.20] ([91.61.61.6]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lhf3N-1fNeaF1xib-00mvkx; Tue, 09 Oct 2018 19:30:22 +0200 Received: from [192.168.178.20] ([91.61.61.6]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lhf3N-1fNeaF1xib-00mvkx; Tue, 09 Oct 2018 19:30:22 +0200 To: Henrik Levkowetz , xml2rfc-dev@ietf.org, RFC Editor References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> From: Julian Reschke Message-ID: <8b71a263-a280-270a-4fb4-7e0a4e2abb0a@gmx.de> Date: Tue, 9 Oct 2018 19:30:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:0bj/b7J2LbLsIS8uENsArnGr/kY/D9nAB8rgWebrsZhS48t3GvC KGcaa7ZbIOIoMOnEXpDxq8TvRpLGsTb1alpehsgAqHq02BdOaRm//C2xqD/fjbWnr8PWJGv bK9k3E2dAQvZhUc2xMY0M3gU2b0WuD77VvZZIr/DdCDPEkBzsimjtTQ99V9iWnO0Lu2bsdj RTfz7gXRO9in9AXafy5ZQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:bm7FdJxbiNY=:3pLVzz4YU8G2woiYd5zLC8 9Uwir9xjeKUxXvrLGp6jR/NDhzQd6D8VCs+fCerl+EOH9yX0izXllaFqD6iyaM9tMiwKyBv5b s3jNwmlPI+PoZDEPn7NaAyeUVeLumzAlrCSyQ8eDhttGfMBK6HBTv0Hh3PHEFQo/KYoPONFao BI1ENEdL0QEzPliHzI4xRVKGDTi52TxOQoYQVQ2uklF0SYmOOPB4aV+PXLqRJQiOhcT8w/zq7 ljJNBeHkiIp6wL2jlrst+TBqX92bX/xf5pgWeslXShiVbpUCuXNzwKGtXlBCJG5pPllZKtgpn 8WBgK8zS/1NO8joyecvQr9egP+rF1acpGNtS89BgnjKyTIsYkG9GX+O++PwwUJYq/g1+TiV9L 6IRcF0rora058NZ/88AcmAcfSwJs1pQOMhsZlyx7XXVpYUfObIUOWRytWd4RYZKxJXz7nNZWj /HjMYFsX+Jbjl7XXa96cTYetT/FNfzJzniDHSh2L/go+qV/gIXUlCSX+P1I6DICbF+ZI6oJGJ 3qjG734FTu72ddwf35f5WrJlT1DwCZYQdRTIkdkHYOMzeppXCqk8vPtEPZwboZqKt7mHJrV74 BgHUNvqHEuUoouUP6KDuBucDduqM0/dO8TIGwf8+04MclaK5qBYqceDCueZlLalk2/Zr/tTQj 40aCokZCwLFIx1RoWAw7BPJvKELAlUlRk+BwpWgG4faQcGtr7SCitKo8ydAJo5bHu8URsbqoT Jj3jQSHTMU+GgXzL+YgrSranhBSVO0TXX6BgRCY8RYmnnGhX7iFQWmYOP1QVHdQWH5SuLqCFD wpUkEBhEF60+XG8URLHWqSHJ6pe9k5RF/BVRDPr+cak1tI6UA4= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 17:30:43 -0000 On 2018-10-09 17:56, Henrik Levkowetz wrote: > ... >> Reminder: as author of a processor you are free to augment the >> intermediate format with any information you want. But that doesn't mean >> it needs to surface in the author visible vocabulary. > > Agreed. But that's a somewhat different issue. Here I'm concerned with > the incompleteness of the published archival XML, in view of the RFC7998 > statement below, rather than whatever bells processors may choose to add. And I don't think that the absence of ToC and Index are a problem. Not do I think that inserting the container for the references is a problem. > .. >> It would be helpful if you could paste snippets for ToC and index - to >> keep a valid XML representation, they'd need to live in /
                                          >> right? Is inserting these containers not a problem in itself? What >> happens if you re-run the preptool on the prepped XML? > > For both the preptool and the v2v3 converter, I've tried to make them > idempotent, so you should be able to run the output through the processor > again with no change. > > Here's a ToC snippet. I'm not claiming this is optimal; if we reach > consensus on what 7998 requires, we can look at other implementations: > > > >
                                          > Table of Contents >
                                            >
                                          • > > . RFC 2119 key words > >
                                            • >
                                          • > > . Unordered list with sub-elements > >
                                            • >
                                          • > > . Ordered list with sub-elements > >
                                            • > >
                                          >
                                          >                                           1) I then believe that we need to clarify what should contain. I never considered the ToC to be part of it. 2) How exactly does this content help in producing the ToC for HTML (which will require special CSS) or in paged formats (where one would expect page numbers)? > And here's the start of an index: > > > >
                                          > Index > > L > T > >
                                            >
                                          • > > L > >
                                              >
                                            • > list > > list > list > > .... > Now do you prevent additional index sections from being inserted when the preptool is run multiple times? Best regards, Julian From nobody Tue Oct 9 10:45:12 2018 Return-Path: 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 D2FA2130E2B for ; Tue, 9 Oct 2018 10:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 KsufRCpuq2pX for ; Tue, 9 Oct 2018 10:45:08 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87B6A12D7EA for ; Tue, 9 Oct 2018 10:45:08 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:59909 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g9w4A-00035j-HZ; Tue, 09 Oct 2018 10:45:07 -0700 To: Julian Reschke , xml2rfc-dev@ietf.org, RFC Editor References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> <8b71a263-a280-270a-4fb4-7e0a4e2abb0a@gmx.de> From: Henrik Levkowetz Message-ID: <926f11a0-3d4b-ffe0-d7b5-c7ec51f1083b@levkowetz.com> Date: Tue, 9 Oct 2018 19:44:58 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8b71a263-a280-270a-4fb4-7e0a4e2abb0a@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="U6k6Mp0OVEnGlEdrdS5Df9a9Ph6VNxHIX" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: rfc-editor@rfc-editor.org, xml2rfc-dev@ietf.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 17:45:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --U6k6Mp0OVEnGlEdrdS5Df9a9Ph6VNxHIX Content-Type: multipart/mixed; boundary="1GI85sgo7Puu65Uhi2uDevSknTMeODcOU"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , xml2rfc-dev@ietf.org, RFC Editor Message-ID: <926f11a0-3d4b-ffe0-d7b5-c7ec51f1083b@levkowetz.com> Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> <8b71a263-a280-270a-4fb4-7e0a4e2abb0a@gmx.de> In-Reply-To: <8b71a263-a280-270a-4fb4-7e0a4e2abb0a@gmx.de> --1GI85sgo7Puu65Uhi2uDevSknTMeODcOU Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-10-09 19:30, Julian Reschke wrote: > On 2018-10-09 17:56, Henrik Levkowetz wrote: >> ... >>> Reminder: as author of a processor you are free to augment the >>> intermediate format with any information you want. But that doesn't m= ean >>> it needs to surface in the author visible vocabulary. >>=20 >> Agreed. But that's a somewhat different issue. Here I'm concerned wi= th >> the incompleteness of the published archival XML, in view of the RFC79= 98 >> statement below, rather than whatever bells processors may choose to a= dd. >=20 > And I don't think that the absence of ToC and Index are a problem. Not = > do I think that inserting the container for the references is a problem= =2E Problem? Depends on what you expect from the prepped archival document. You could use v2 xml as archival XML, if you wanted; it would not be a 'problem', either. But what is really desired from the archival format? >> .. >>> It would be helpful if you could paste snippets for ToC and index - t= o >>> keep a valid XML representation, they'd need to live in / >>> right? Is inserting these containers not a problem in itself? What >>> happens if you re-run the preptool on the prepped XML? >>=20 >> For both the preptool and the v2v3 converter, I've tried to make them >> idempotent, so you should be able to run the output through the proces= sor >> again with no change. >>=20 >> Here's a ToC snippet. I'm not claiming this is optimal; if we reach >> consensus on what 7998 requires, we can look at other implementations:= >>=20 >> >> >>
                                              >> Table of Conte= nts >>
                                                >>
                                              • >> >> . RFC 2119 key words >> >>
                                                • >>
                                              • >> >> . Unordered list with sub-elements >> >>
                                                • >>
                                              • >> >> . Ordered list with sub-elements >> >>
                                                • >> >>
                                              >>
                                              >>                                               >=20 > 1) I then believe that we need to clarify what should=20 > contain. I never considered the ToC to be part of it. Yes. I'd be perfectly happy with building this in a or in some other fashion, if that would be cleaner. > 2) How exactly does this content help in producing the ToC for HTML=20 > (which will require special CSS) or in paged formats (where one would=20 > expect page numbers)? Of course the details of the rendering based on this will be specific to the individual renderers. You can look at the v3 text-renderer code now;= I can point at the html-renderer code when I've written it. The representation above is true to the document structure and provides the s needed for linkage, which is where any ToC rendering needs to start. >> And here's the start of an index: >>=20 >> >> >>
                                              >> Index >> >> L >> T >> >>
                                                >>
                                              • >> >> L >> >>
                                                  >>
                                                • >> list >> >> list >> list >> >> .... >>=20 >=20 > Now do you prevent additional index sections from being inserted when=20 > the preptool is run multiple times? There are two reasonable approaches, I think: skip new insertion if alrea= dy prepped, and replace wholly if already prepped. The current code does th= e first, but I don't have any particular preference in the matter. Best regards, Henrik --1GI85sgo7Puu65Uhi2uDevSknTMeODcOU-- --U6k6Mp0OVEnGlEdrdS5Df9a9Ph6VNxHIX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu86RsACgkQTptXS4+7 Fxq0DBAAgk2vyBTkVFWr0JE1i23maocwKSIwCf2PviKzcP5Rqkk2cebTrbaW5tsH jnIOwSKVE8/4l/mZGADEwKWWHX15D4UzS/Y1gWgqlrZuW9ZShZN0DzPlWJRyxgAr kXifY31he5UBKK434VObOcAyg/OIeP2+vGkWH4+kJ9m6W9tJZan4Jdk4A2e0UAdv u65eheIvqrzFNLiRQJo9BLL/onI+3EfVF4snkCiBXgT1yHnFyEbCzCTx5IyAm9k1 RJzuHv7LlVfIWMrRtPM7TbMKUiSJUs/SjgTkZMlct2fF6neMLemNODOH9qpb6WGY b5iDzYYriqO3cBkG62yk7HrLjBLUF8VQuXUMTi/nQrzeQ/T6Z5dc9pxIahWCRrdZ FIdyb49o/mL9uNSZqFQxZvzvBwSXllRHtEm/nxiyH1/95tPANbFiRsS0OOC8PBPC bubScqMY8xmv+4al9Ml0CoODOCDoMFk79fJ/+1QGLo3gzJN38NirqbPNAlIE979P K9t8Jc9Oc3xPQfmWa5fCVAdO1IaO3lhTPJ1P2cyWqoLg/6tAaKNsXXvTe7YnbRbe +JaHAJTCFQNC9k83TJBRnCIdFpjFYb5oxUfvBhFXMUlZah9HHvA1wWpnoHOhyxFB Jq8cCYHxdxO3TyTaAZuw5jkNE4Do9I050SS234S/vUwuRIqZijY= =FISw -----END PGP SIGNATURE----- --U6k6Mp0OVEnGlEdrdS5Df9a9Ph6VNxHIX-- From nobody Tue Oct 9 10:54:11 2018 Return-Path: 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 B7D20130EA7 for ; Tue, 9 Oct 2018 10:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 hmlwKU_u8Bea for ; Tue, 9 Oct 2018 10:54:07 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 017AB130E9B for ; Tue, 9 Oct 2018 10:54:06 -0700 (PDT) Received: from [192.168.178.20] ([91.61.61.6]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LosFD-1fUpkx316x-00glUr; Tue, 09 Oct 2018 19:53:52 +0200 Received: from [192.168.178.20] ([91.61.61.6]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LosFD-1fUpkx316x-00glUr; Tue, 09 Oct 2018 19:53:52 +0200 To: Henrik Levkowetz , xml2rfc-dev@ietf.org, RFC Editor References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> <8b71a263-a280-270a-4fb4-7e0a4e2abb0a@gmx.de> <926f11a0-3d4b-ffe0-d7b5-c7ec51f1083b@levkowetz.com> From: Julian Reschke Message-ID: Date: Tue, 9 Oct 2018 19:53:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <926f11a0-3d4b-ffe0-d7b5-c7ec51f1083b@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:H8nL8HxJDjwon35QAtEneYVl6ic5Qt7Wr3Z4TRnVVDORmCF2NEx Y/8VJq6fC8xRtckSGZ9ygaLP7qY3mSLwK+22i1ORAfl/0s9sjuixHY3HoxdXD551bVk83g5 dleiMsKqS29V66cAint0pvC85V5JLx0ejoQYnI7/UTWT+btuoKSEwamOZeTAFrqHF2KY33o 9akooLNN0LJ+BwtX1WXCA== X-UI-Out-Filterresults: notjunk:1;V01:K0:hqlFaHajCmE=:fe3gODeLZld9bsy7993kCV v9p9py2vp93rZIflsa3QLvEC5DkQuH8pm3cNOICAV4IBk8Qka1YDYYRaar/Cir9Gx401raMAv f+I9QcfM2DtHgQBCdfIWjNYG8iiccBO6jipVQOcidByaQXS7rAmzjwGfHuvAp+FcADPUR/OMj W6EqQFjIzk/rD/+903cSr/zY6sPyGUwpxh6Jve1xVIoBZj08O0tPmdr404uNGTf4QeBNiYeUg 5O9TlJkHnShZb/Sb2Cn/hMa1GrtT+Ea+YhGN/GgTKhfJ4V88jNzrrQoGO4SDd50g2dcmi7NAb wchYiF9g/1wbCJKKN3lnE3JY8bxLpVUUk9qIo+qptsQOCjpZPDXlxk1IZ3G71X6VHvwlABM16 waTjVb5i/XosmJC2IlS+q5b3Rvh+0wgDa//9qOX5TsvsqGyjpDDlp+4GgNC36cNxalJpRyK4K IQXtU2QfSWAII9s3mXY/tDNjD7skm7Ae2Yl8X3egOnuN+KStqCcfqwVKQZJhdP53Peyoi6fN8 KQkq2Zqkb7YZ1qbzDJsJVKn+atvubjtYp/UmPbcsANwZ8OvCMbyLZq1QECOQjU2C0t1I3moBH EEcKewh06oGjG5GImE1XZyzN4Cz4okMtrUO6VZGw+kbxKooBMijUHfRoqZAbPlvaEBg5kiLJN r1Q0LJxTzEgoMvI+7noDg6BHdrI51fv8HCp9cJSYjjtfh5pa/lTzqgJl8P+3lLtug9GX9MP/e DzzFAT0XdVjWZGxHNdOmTddz+Hw9VB2883pk2B7Kb3r9ky3gvBfWQrCi0u11Vm65yqg8xgvL3 bJJ0F3jaPve5hOgvKv3fwEFAqoGiPCqp7yKpdMCmHY4WMpKnmQ= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 17:54:10 -0000 On 2018-10-09 19:44, Henrik Levkowetz wrote: > > On 2018-10-09 19:30, Julian Reschke wrote: >> On 2018-10-09 17:56, Henrik Levkowetz wrote: >>> ... >>>> Reminder: as author of a processor you are free to augment the >>>> intermediate format with any information you want. But that doesn't mean >>>> it needs to surface in the author visible vocabulary. >>> >>> Agreed. But that's a somewhat different issue. Here I'm concerned with >>> the incompleteness of the published archival XML, in view of the RFC7998 >>> statement below, rather than whatever bells processors may choose to add. >> >> And I don't think that the absence of ToC and Index are a problem. Not >> do I think that inserting the container for the references is a problem. > > Problem? Depends on what you expect from the prepped archival document. > > You could use v2 xml as archival XML, if you wanted; it would not be a > 'problem', either. > > But what is really desired from the archival format? That's a good question. I already wasn't a fan of the "insert derived content", because, well, it can be derived. The difference here is that the information you are missing truly is insignificant for the meaning of the RFC. > ... >> 1) I then believe that we need to clarify what should >> contain. I never considered the ToC to be part of it. > > Yes. I'd be perfectly happy with building this in a or in some > other fashion, if that would be cleaner. > >> 2) How exactly does this content help in producing the ToC for HTML >> (which will require special CSS) or in paged formats (where one would >> expect page numbers)? > > Of course the details of the rendering based on this will be specific to > the individual renderers. You can look at the v3 text-renderer code now; > I can point at the html-renderer code when I've written it. The > representation above is true to the document structure and provides the > s needed for linkage, which is where any ToC rendering needs to > start. In a paged medium, I'd expect the inserted page number on the right hand side, with the line filled by dots (missing a more technical term). This really is different from a regular list. >>> And here's the start of an index: >>> >>> >>> >>>
                                                  >>> Index >>> >>> L >>> T >>> >>>
                                                    >>>
                                                  • >>> >>> L >>> >>>
                                                      >>>
                                                    • >>> list >>> >>> list >>> list >>> >>> .... >>> >> >> Now do you prevent additional index sections from being inserted when >> the preptool is run multiple times? > > There are two reasonable approaches, I think: skip new insertion if already > prepped, and replace wholly if already prepped. The current code does the > first, but I don't have any particular preference in the matter. The point was: on an input document, how do you detect that a
                                                      inside already contains an index? Best regards, Julian From nobody Tue Oct 9 11:00:17 2018 Return-Path: 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 95D891274D0 for ; Tue, 9 Oct 2018 11:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Ym35kZMNza57 for ; Tue, 9 Oct 2018 11:00:13 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BC40127AC2 for ; Tue, 9 Oct 2018 11:00:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id CA7671D06DD for ; Tue, 9 Oct 2018 10:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrQQjoBD3gHI for ; Tue, 9 Oct 2018 10:59:42 -0700 (PDT) Received: from Heathers-MacBook-Pro.local (unknown [IPv6:2603:3023:30a:e7e0:58ec:d4d5:9d0a:f1f3]) by c8a.amsl.com (Postfix) with ESMTPSA id 9CD241D06DB for ; Tue, 9 Oct 2018 10:59:42 -0700 (PDT) To: xml2rfc-dev@ietf.org From: Heather Flanagan Message-ID: Date: Tue, 9 Oct 2018 11:00:03 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [xml2rfc-dev] Summary of issues - week of 1 October 2018 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 18:00:16 -0000 Hola a todos, Here's what I took from last week's discussions. ---- Issue #34 - consensus to remove the restriction "It is an error to have both a "src" attribute and content in the element." Issue #35 - consensus reached. Allow blockquotes in
                                                    • Issue #36 - consensus reached. Leave "name" attribute as is. Issue #37 - decision made. Remove
                                                      from the v3 spec. Issue #38 - consensus reached. Change "hanging" to "newline" throughout. Issue #39 - consensus reached. Revise text to "indent" attribute. Issue #40 - consensus reached (also, duplicate of #9). Allow "align" for tables. From nobody Tue Oct 9 11:00:45 2018 Return-Path: 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 6D189124BE5 for ; Tue, 9 Oct 2018 11:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 zjBqyXWatqrk for ; Tue, 9 Oct 2018 11:00:43 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86814120072 for ; Tue, 9 Oct 2018 11:00:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id C8A521D06DE for ; Tue, 9 Oct 2018 11:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWi1qQvz5EvP for ; Tue, 9 Oct 2018 11:00:21 -0700 (PDT) Received: from Heathers-MacBook-Pro.local (unknown [IPv6:2603:3023:30a:e7e0:58ec:d4d5:9d0a:f1f3]) by c8a.amsl.com (Postfix) with ESMTPSA id 9C94A1D06DB for ; Tue, 9 Oct 2018 11:00:21 -0700 (PDT) To: xml2rfc-dev@ietf.org References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> <050c01d45d97$714e51b0$53eaf510$@augustcellars.com> <052b01d45daa$87e71980$97b54c80$@augustcellars.com> <656afb2e-3aa7-53c5-5e39-55050387aa20@levkowetz.com> From: Heather Flanagan Message-ID: <0bac2940-1abc-87e3-35e7-f6d621e83f1c@rfc-editor.org> Date: Tue, 9 Oct 2018 11:00:42 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <656afb2e-3aa7-53c5-5e39-55050387aa20@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, In Section 2.54,
    • 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 18:00:44 -0000 On 10/6/18 2:53 PM, Henrik Levkowetz wrote: > 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. >>> Till now, both have been centered. That can be changed. >>> >> 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. > I'm not entirely sure how this issue differs from the table alignment discussed in issues 40 and 9? -Heather From nobody Tue Oct 9 11:05:52 2018 Return-Path: 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 EC3D8120072 for ; Tue, 9 Oct 2018 11:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 DUewOj39yg3O for ; Tue, 9 Oct 2018 11:05:46 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0616612426A for ; Tue, 9 Oct 2018 11:05:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 4467F1D06DB for ; Tue, 9 Oct 2018 11:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcSv1tvX5Gi8 for ; Tue, 9 Oct 2018 11:05:23 -0700 (PDT) Received: from Heathers-MacBook-Pro.local (unknown [IPv6:2603:3023:30a:e7e0:58ec:d4d5:9d0a:f1f3]) by c8a.amsl.com (Postfix) with ESMTPSA id 1806A1CADD4 for ; Tue, 9 Oct 2018 11:05:23 -0700 (PDT) To: xml2rfc-dev@ietf.org References: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> <065401d45f46$d92c3710$8b84a530$@augustcellars.com> <4308bb9a-14ef-ca1c-03b3-2d1d09bc95a5@levkowetz.com> <4e4af1df-37b8-c180-93d8-14104fe2281c@gmx.de> From: Heather Flanagan Message-ID: Date: Tue, 9 Oct 2018 11:05:44 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 18:05:48 -0000 On 10/8/18 10:20 PM, Henrik Levkowetz wrote: > On 2018-10-09 06:51, Julian Reschke wrote: >> On 2018-10-08 23:41, Henrik Levkowetz wrote: >>> ... >>> Currently, reference files are only being created according to the v2 >>> schema. If we begin to create them according to v3 (because of richer >>> semantics) we may have to maintain separate, parallel bibxml repositories, >>> yes. >>> ... >> That wiil lead to friction. >> >> Maybe we should reconsider any change that makes those incompatible. > Ack; looking at those again makes sense, in view of the possibility of > having to maintain different reference repositories. > Hola a todos, Two questions: first, I'm not sure what this means for when we do switch over to v3 - there will be changes to the reference format, so does that mean we'll have to be ready with a 100% switchover to an alternate repository when we go live? Second, when you say "reconsider any change that makes those incompatible" are you proposing changes to the v3 vocabulary to avoid incompatible changes to v2? Thanks! Heather From nobody Tue Oct 9 11:12:04 2018 Return-Path: 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 B922D127AC2 for ; Tue, 9 Oct 2018 11:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 3GMiA9ohTaJn for ; Tue, 9 Oct 2018 11:12:01 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C7FE127333 for ; Tue, 9 Oct 2018 11:12:01 -0700 (PDT) Received: from [192.168.178.20] ([91.61.61.6]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LuwiT-1fjZrb10SX-0106oL; Tue, 09 Oct 2018 20:11:58 +0200 Received: from [192.168.178.20] ([91.61.61.6]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LuwiT-1fjZrb10SX-0106oL; Tue, 09 Oct 2018 20:11:58 +0200 To: Heather Flanagan , xml2rfc-dev@ietf.org References: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> <065401d45f46$d92c3710$8b84a530$@augustcellars.com> <4308bb9a-14ef-ca1c-03b3-2d1d09bc95a5@levkowetz.com> <4e4af1df-37b8-c180-93d8-14104fe2281c@gmx.de> From: Julian Reschke Message-ID: Date: Tue, 9 Oct 2018 20:11:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:SSPgz9/j3hsae1241bOsQierOxmSIXTLgnYdyN3Z1k8TXDjozfr AzBJ+sWyRJuYqXOPq/NyYWF2kWTrXsBr8b/6sZbRR7V3Ox4k59sbGUA6jkkgjJCeaCJ5HVK 0Dg+iqOfT2UOlC3Ep/iNnlHWpHp/XQtKkC93pNcIKta1cQlvLpYycNXG09ciuHTXh9bS8Ur ypjp757R7u5YeTPRqdN0g== X-UI-Out-Filterresults: notjunk:1;V01:K0:p+T2B97ux+I=:3IausVcEgjafYv4Zbs0NvV F0QAxVHxkHsd/9ewM7I59EmO0MAXsColC1dgNZoLZOTvrxZvNQi0PXFiMjDMi+YEdfA8n4KZG v8rhl7Co5WFagnRllo14L4uM0dneh/mEuKjfgs1S3JGllH0h35LR9OFvaSA2xWPWPD2AyszaG RcI4LNzXeGu1swIoeOLac4U0dXD1nkdLFQtxsq/t8r4ysKOtnZiWdHhB0poRgAopY2H0MIteG KjRHH4CxREYc6sFfpTh3H2GP+QrzrG+ZTlI0lYMLS93Q/yuIekPRvqkCtbgNM5aw8XOu6w/iG SWGdufeVMA+Dx/iGWMQh3XTLS1o9sggYamRPUMVxZcaBMO1qiZ6elX0qMbm1JgsZyJS3fbwnC aAyVEBFBaPfiZ6nMOoatb+4UjdKo++ZnxJgbhCHpDkYqfb8bSSbFOgJIkNNlTguQZ/IfFBqZz mgbW6jvc+6kZXiWGTAX6dCx46K4VgY5kqpqX9jg8T1QYhB6j8oLRFwkN/7MBWLFp57wDtBqN+ Vtv7stEuMzSZaVcmMqYPcjVtVdrXTTJehV/78jtXiVQidIVTOZIiLn1L5vQR8xWEJnDeHOnsI Gz4UxGOZ1zM8KeX9MMu3tC5nz2QzD9k5Nu9wmfQ1OWD8NW1SWbJAL6SDWGpsacTO0pcq0oe2K Msb1gRC4h+CjrDBbe/Lnn3dyoi7PtlyeOcFKXy7AaOyp4osrctGrsNcN3Q3JWw+37eNlFKGPd RLfE31ku/r8qAMMIPNnLBxuYnq5G5UAQyfN0zmASGGWQG3XrAFWsPMyd/j6aKacG4Vodg7bnb a9A5+3T9w2v7WFOgec77nakZfJqczz6eLU9XfL/VMXdHF4nSAU= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 18:12:03 -0000 On 2018-10-09 20:05, Heather Flanagan wrote: > > On 10/8/18 10:20 PM, Henrik Levkowetz wrote: >> On 2018-10-09 06:51, Julian Reschke wrote: >>> On 2018-10-08 23:41, Henrik Levkowetz wrote: >>>> ... >>>> Currently, reference files are only being created according to the v2 >>>> schema.  If we begin to create them according to v3 (because of richer >>>> semantics) we may have to maintain separate, parallel bibxml >>>> repositories, >>>> yes. >>>> ... >>> That wiil lead to friction. >>> >>> Maybe we should reconsider any change that makes those incompatible. >> Ack; looking at those again makes sense, in view of the possibility of >> having to maintain different reference repositories. >> > > Hola a todos, > > Two questions: first, I'm not sure what this means for when we do switch > over to v3 - there will be changes to the reference format, so does that > mean we'll have to be ready with a 100% switchover to an alternate > repository when we go live? Second, when you say "reconsider any change I guess it would be an additional repository. > that makes those incompatible" are you proposing changes to the v3 > vocabulary to avoid incompatible changes to v2? Yes. I believe we should undo the change to (moving under ), and just restore what we have in v2. Best regards, Julian From nobody Tue Oct 9 11:14:21 2018 Return-Path: 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 5656A1277D2 for ; Tue, 9 Oct 2018 11:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 w1Er5Z8PRc_5 for ; Tue, 9 Oct 2018 11:14:19 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F20C812426A for ; Tue, 9 Oct 2018 11:14:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 3BBA61D06DD for ; Tue, 9 Oct 2018 11:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1OTEHfTqYkX for ; Tue, 9 Oct 2018 11:13:57 -0700 (PDT) Received: from Heathers-MacBook-Pro.local (unknown [IPv6:2603:3023:30a:e7e0:58ec:d4d5:9d0a:f1f3]) by c8a.amsl.com (Postfix) with ESMTPSA id 029FA1D06DB for ; Tue, 9 Oct 2018 11:13:56 -0700 (PDT) To: xml2rfc-dev@ietf.org References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> <8b71a263-a280-270a-4fb4-7e0a4e2abb0a@gmx.de> <926f11a0-3d4b-ffe0-d7b5-c7ec51f1083b@levkowetz.com> From: Heather Flanagan Message-ID: <10b47376-f6a3-0df0-11c4-fe3a2a18f4a4@rfc-editor.org> Date: Tue, 9 Oct 2018 11:14:18 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <926f11a0-3d4b-ffe0-d7b5-c7ec51f1083b@levkowetz.com> Content-Type: multipart/alternative; boundary="------------4DC8A69289CE9880E95198F1" Content-Language: en-US Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 18:14:20 -0000 This is a multi-part message in MIME format. --------------4DC8A69289CE9880E95198F1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hola a todos, On 10/9/18 10:44 AM, Henrik Levkowetz wrote: > But what is really desired from the archival format? Complete content. I tried to capture this in RFC 7990, Section 6.1 "XML for RFCs" Key points regarding the XML format: o The canonical format for RFCs is XML using the xml2rfc version 3 (xml2rfc v3) vocabulary. The XML file must contain all information necessary to render a variety of formats; any question about what was intended in the publication will be answered from this format. o Authors may submit documents using the xml2rfc v2 vocabulary, but the final publication will be converted to use the xml2rfc v3 vocabulary. o SVG is supported and will be embedded in the final XML file. o There will be automatically generated identifiers for sections, paragraphs, figures, and tables in the final XML file. o The XML file will not contain any xml2rfc v3 vocabulary elements or attributes that have been marked deprecated. o A DTD will no longer be used. The grammar will be defined using RELAX NG [RNC]. o The final XML file will contain, verbatim, the appropriate boilerplate as applicable at time of publication specified by RFC 7841 [RFC7841] or its successors. o The final XML will be self-contained with all the information known at publication time. For instance, all features that reference externally defined input will be expanded. This includes all uses of xinclude, src attributes (such as in or elements), include-like processing instructions, and externally defined entities. o The final XML will not contain comments or processing instructions. o The final XML will not contain src attributes for or elements. Does this answer your question? Heather --------------4DC8A69289CE9880E95198F1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

    Hola a todos,

    On 10/9/18 10:44 AM, Henrik Levkowetz wrote:
    But what is really desired from the archival format?

    Complete content. I tried to capture this in RFC 7990, Section 6.1 "XML for RFCs"

    Key points regarding the XML format:

   o  The canonical format for RFCs is XML using the xml2rfc version 3
      (xml2rfc v3) vocabulary.  The XML file must contain all
      information necessary to render a variety of formats; any question
      about what was intended in the publication will be answered from
      this format.

   o  Authors may submit documents using the xml2rfc v2 vocabulary, but
      the final publication will be converted to use the xml2rfc v3
      vocabulary.

   o  SVG is supported and will be embedded in the final XML file.

   o  There will be automatically generated identifiers for sections,
      paragraphs, figures, and tables in the final XML file.

   o  The XML file will not contain any xml2rfc v3 vocabulary elements
      or attributes that have been marked deprecated.

   o  A DTD will no longer be used.  The grammar will be defined using
      RELAX NG [RNC].

   o  The final XML file will contain, verbatim, the appropriate
      boilerplate as applicable at time of publication specified by RFC
      7841 [RFC7841] or its successors.

   o  The final XML will be self-contained with all the information
      known at publication time.  For instance, all features that
      reference externally defined input will be expanded.  This
      includes all uses of xinclude, src attributes (such as in
      <artwork> or <sourcecode> elements), include-like processing
      instructions, and externally defined entities.

   o  The final XML will not contain comments or processing
      instructions.

   o  The final XML will not contain src attributes for <artwork> or
      <sourcecode> elements.


    Does this answer your question?

    Heather


    --------------4DC8A69289CE9880E95198F1-- From nobody Tue Oct 9 11:20:19 2018 Return-Path: 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 0B07512426A for ; Tue, 9 Oct 2018 11:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 8qFlzug-w4GI for ; Tue, 9 Oct 2018 11:20:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E183124C04 for ; Tue, 9 Oct 2018 11:20:16 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:60227 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g9wcA-0002DL-GO; Tue, 09 Oct 2018 11:20:15 -0700 To: Heather Flanagan , xml2rfc-dev@ietf.org References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> <050c01d45d97$714e51b0$53eaf510$@augustcellars.com> <052b01d45daa$87e71980$97b54c80$@augustcellars.com> <656afb2e-3aa7-53c5-5e39-55050387aa20@levkowetz.com> <0bac2940-1abc-87e3-35e7-f6d621e83f1c@rfc-editor.org> From: Henrik Levkowetz Message-ID: <09d7b55e-a5a7-aada-c5ff-890242203242@levkowetz.com> Date: Tue, 9 Oct 2018 20:20:07 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <0bac2940-1abc-87e3-35e7-f6d621e83f1c@rfc-editor.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="x1Mct7kA6wVEdLkUqM3Oiu5xJJL6jKGtl" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, rse@rfc-editor.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, In Section 2.54,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 18:20:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --x1Mct7kA6wVEdLkUqM3Oiu5xJJL6jKGtl Content-Type: multipart/mixed; boundary="aRGrosr6Lx0kSImtJWIUFSfaAvKh2gurC"; protected-headers="v1" From: Henrik Levkowetz To: Heather Flanagan , xml2rfc-dev@ietf.org Message-ID: <09d7b55e-a5a7-aada-c5ff-890242203242@levkowetz.com> Subject: Re: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, In Section 2.54,
    References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> <050c01d45d97$714e51b0$53eaf510$@augustcellars.com> <052b01d45daa$87e71980$97b54c80$@augustcellars.com> <656afb2e-3aa7-53c5-5e39-55050387aa20@levkowetz.com> <0bac2940-1abc-87e3-35e7-f6d621e83f1c@rfc-editor.org> In-Reply-To: <0bac2940-1abc-87e3-35e7-f6d621e83f1c@rfc-editor.org> --aRGrosr6Lx0kSImtJWIUFSfaAvKh2gurC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Heather, On 2018-10-09 20:00, Heather Flanagan wrote: >=20 > On 10/6/18 2:53 PM, Henrik Levkowetz wrote: >> 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. >>>> Till now, both have been centered. That can be changed. >>>> >>> 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. >> >=20 > I'm not entirely sure how this issue differs from the table alignment=20 > discussed in issues 40 and 9? In the previous release of xml2rfc, the table caption, e.g., "Table 1: Fo= o" 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 tab= le 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= =2E The discussion above concerned steps 2 and 3 above, while issues 40 and 9= concerned 4. Best regards, Henrik --aRGrosr6Lx0kSImtJWIUFSfaAvKh2gurC-- --x1Mct7kA6wVEdLkUqM3Oiu5xJJL6jKGtl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu88VcACgkQTptXS4+7 Fxqh5BAAlUG51TAZzi4xsd9C0hhRlfo1G7t6af8+kRQGPVjvQG4miKQuGL5rdUdC OtsrlOJ1bwRWcL75laFUMzmqH37vnCMh8tvIAWbfok++sWU52bdQ+HDcjnqn8mFv eNOD/cwF1EyA1fCkJLnoMxKDepDV4C0WsT3u+9lkzwDpJMtP1Z2NP2da9Kd9kSNZ E+8oCJgeY/8rf4rp+2ICVYScfilslhpj1KIlaCJzKkTulIFeOYR0qwvzT+jMc0fw zefrSOdXSz0+FRFJKcjH8yN+k+RdEWyH1gxylxpdkGJsKWt3k2kBV2WanNheB4fq a0OcvEkOiGRE15xWl1Ks+2mAwjgG8Zkw6th8EdyISylSbpPfnCzP67MLKhqDSQrI oQykboj1EuCfKx2kZ/mFaRCywzCaRUL36RtUmO7YeF/elDW775tSpNtV3b6KxZPQ JBU9YLr3TP2LyCIZbftYYWFXhczdNQNmNlAufHzpv40zk5OK8EKvCsM8rnQFLPS9 VS21lReQHD7BIxShq39vX+bn0aNptjtMe8Kq7+VMWzgajtyIXaSUmXHw7FKmsFx9 nmcPAgPR1BxHZit9dEyV6HNOcSGRgwbchn+b0LN1/i1zMNbFmDgh53bOTF7V4/n6 I/yQnDPLuzFkjRJFxbnrVQOodf63cHgKpmXy0ZebDTqwIwyGXfY= =J/oX -----END PGP SIGNATURE----- --x1Mct7kA6wVEdLkUqM3Oiu5xJJL6jKGtl-- From nobody Tue Oct 9 11:22:22 2018 Return-Path: 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 CB08E1277CC for ; Tue, 9 Oct 2018 11:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 e3F_LSXxskRF for ; Tue, 9 Oct 2018 11:22:18 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E68B5128CE4 for ; Tue, 9 Oct 2018 11:22:16 -0700 (PDT) Received: from Jude (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 9 Oct 2018 11:17:30 -0700 From: Jim Schaad To: 'Heather Flanagan' , References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> <050c01d45d97$714e51b0$53eaf510$@augustcellars.com> <052b01d45daa$87e71980$97b54c80$@augustcellars.com> <656afb2e-3aa7-53c5-5e39-55050387aa20@levkowetz.com> <0bac2940-1abc-87e3-35e7-f6d621e83f1c@rfc-editor.org> In-Reply-To: <0bac2940-1abc-87e3-35e7-f6d621e83f1c@rfc-editor.org> Date: Tue, 9 Oct 2018 11:22:03 -0700 Message-ID: <073e01d45ffc$fc161550$f4423ff0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKlc/I8qUpx6H6sTpIQv3vHmEIb5gGMQXb8AverSrcCvXax5QHGvedgAOtPwScCpgcF3ADkS5KAAqj1aRQB/yc3qAHvHWwdAnFKOwwCPeYpeAHzzxMrAbzXacsBRDvT8qKHSWug Content-Language: en-us X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, In Section 2.54,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 18:22:21 -0000 > -----Original Message----- > From: xml2rfc-dev On Behalf Of Heather > Flanagan > Sent: Tuesday, October 9, 2018 11:01 AM > To: xml2rfc-dev@ietf.org > Subject: Re: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, In > Section 2.54,
    > > > On 10/6/18 2:53 PM, Henrik Levkowetz wrote: > > 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. > >>> Till now, both have been centered. That can be changed. > >>> > >> 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. > > > > I'm not entirely sure how this issue differs from the table alignment 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 > > -Heather > > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc-dev From nobody Tue Oct 9 11:26:12 2018 Return-Path: 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 1D7FE128CB7 for ; Tue, 9 Oct 2018 11:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 T687Tlxq5LVg for ; Tue, 9 Oct 2018 11:26:09 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4602B1277CC for ; Tue, 9 Oct 2018 11:26:09 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:60260 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g9whs-0004ep-AO; Tue, 09 Oct 2018 11:26:08 -0700 To: Heather Flanagan , xml2rfc-dev@ietf.org References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> <8b71a263-a280-270a-4fb4-7e0a4e2abb0a@gmx.de> <926f11a0-3d4b-ffe0-d7b5-c7ec51f1083b@levkowetz.com> <10b47376-f6a3-0df0-11c4-fe3a2a18f4a4@rfc-editor.org> From: Henrik Levkowetz Message-ID: Date: Tue, 9 Oct 2018 20:26:00 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <10b47376-f6a3-0df0-11c4-fe3a2a18f4a4@rfc-editor.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UXU1E2LeWsaUBeLGLRjJ1FioTAq9JbKue" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, rse@rfc-editor.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 18:26:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UXU1E2LeWsaUBeLGLRjJ1FioTAq9JbKue Content-Type: multipart/mixed; boundary="mfBhWsdwjVJLPdOoLj77Bl5kw177C52oU"; protected-headers="v1" From: Henrik Levkowetz To: Heather Flanagan , xml2rfc-dev@ietf.org Message-ID: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> <8b71a263-a280-270a-4fb4-7e0a4e2abb0a@gmx.de> <926f11a0-3d4b-ffe0-d7b5-c7ec51f1083b@levkowetz.com> <10b47376-f6a3-0df0-11c4-fe3a2a18f4a4@rfc-editor.org> In-Reply-To: <10b47376-f6a3-0df0-11c4-fe3a2a18f4a4@rfc-editor.org> --mfBhWsdwjVJLPdOoLj77Bl5kw177C52oU Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Heather, On 2018-10-09 20:14, Heather Flanagan wrote: > Hola a todos, >=20 > On 10/9/18 10:44 AM, Henrik Levkowetz wrote: >> But what is really desired from the archival format? >=20 > Complete content. I tried to capture this in RFC 7990, Section 6.1 "XML= =20 > for RFCs" >=20 > Key points regarding the XML format: >=20 > o The canonical format for RFCs is XML using the xml2rfc version 3= > (xml2rfc v3) vocabulary. The XML file must contain all > information necessary to render a variety of formats; any questi= on > about what was intended in the publication will be answered from= > this format. >=20 > o Authors may submit documents using the xml2rfc v2 vocabulary, bu= t > the final publication will be converted to use the xml2rfc v3 > vocabulary. >=20 > o SVG is supported and will be embedded in the final XML file. >=20 > o There will be automatically generated identifiers for sections, > paragraphs, figures, and tables in the final XML file. >=20 > o The XML file will not contain any xml2rfc v3 vocabulary elements= > or attributes that have been marked deprecated. >=20 > o A DTD will no longer be used. The grammar will be defined using= > RELAX NG [RNC]. >=20 > o The final XML file will contain, verbatim, the appropriate > boilerplate as applicable at time of publication specified by RF= C > 7841 [RFC7841] or its successors. >=20 > o The final XML will be self-contained with all the information > known at publication time. For instance, all features that > reference externally defined input will be expanded. This > includes all uses of xinclude, src attributes (such as in > or elements), include-like processing > instructions, and externally defined entities. >=20 > o The final XML will not contain comments or processing > instructions. >=20 > o The final XML will not contain src attributes for or > elements. >=20 >=20 > Does this answer your question? For me, I guess it does; for me it means that ToC, enclosing References section, and Index should all be part of the canonical format. For me, RFC 7998 Section 1, Introduction, points in the same direction. Best regards, Henrik --mfBhWsdwjVJLPdOoLj77Bl5kw177C52oU-- --UXU1E2LeWsaUBeLGLRjJ1FioTAq9JbKue Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu88rgACgkQTptXS4+7 FxpO4BAAvGEVaVFkfAfBWfd05TS8We1tt3d7+4UNEFsJS/Asl51YjVcNxUWKjc9U XgVpjv8Vf/TNqt3zd3e/hmNP8HHhdJ9z2179pWxbH/DuWIGwPw7Pz7OE9YAfyxIu nb/+ZDogJFLgXnXmhf8IcFI2myxKqrSp2RJUy/RBv9/ZvoeobpXr27QMIShxGCOY At8jxVxPMITQWJpnkbq1gWEvl7A8+lMN3ZhJDLb0VNtHkuUs92wlKJcwRRU4g6Vi 0d+C71j/WQpRbRp5Yr7D9tcinlg+bll/1N0XYx/k/75YoL1B9EVVTTOswy8yyj60 2cifKoqctv123u1vC6rKTegvGkitEaWJgNIp3VnN7yKXjAL16wMJvWaoKo/AA/hu kaJd2klAxx9RnJV5tJNJ+C4llZta5pVm7tIpSPRiomv41j7L75QmXQLJ6EYCuOf0 DUTCiBvF1r2vtLzjO79zF3A03Qjbh7isvhS3u5bigfprl0//iVy9v1UDBOyAI2a+ aqxGPdNCcsg/LV9oc6QB9FD95dTBZfKMJbYkGOc0hRVIaWZf0mImWPtXflN9kc+1 zIugmiRQYnJRY4DmTHLUF04eAiexVsmWJ+1M6/w1Cvq0sOrnNXTvyfzWyWDUDsHA dIXXAtrekWXWc6sHcPH6TdALvPHbrayBzEN47iMRbcRc2IiIE3A= =qqZn -----END PGP SIGNATURE----- --UXU1E2LeWsaUBeLGLRjJ1FioTAq9JbKue-- From nobody Tue Oct 9 11:27:09 2018 Return-Path: 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 E001C128CF2 for ; Tue, 9 Oct 2018 11:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 FWCHbyxLaJcO for ; Tue, 9 Oct 2018 11:27:05 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41CA41277C8 for ; Tue, 9 Oct 2018 11:27:05 -0700 (PDT) Received: from Jude (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 9 Oct 2018 11:22:22 -0700 From: Jim Schaad To: 'Julian Reschke' , 'Henrik Levkowetz' , , 'RFC Editor' References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> <8b71a263-a280-270a-4fb4-7e0a4e2abb0a@gmx.de> <926f11a0-3d4b-ffe0-d7b5-c7ec51f1083b@levkowetz.com> In-Reply-To: Date: Tue, 9 Oct 2018 11:26:56 -0700 Message-ID: <073f01d45ffd$aa47e4f0$fed7aed0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKMgMAK0VYejNR5SBI3Ju6yzqYpwAJgfmWrAYJ4yUYC/7eaQwLlkh8fAyVeB0sB5WiLFwJwh7rqAZk1LJUCW7yAMKL9NK5g Content-Language: en-us X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 18:27:08 -0000 > -----Original Message----- > From: xml2rfc-dev On Behalf Of Julian > Reschke > Sent: Tuesday, October 9, 2018 10:54 AM > To: Henrik Levkowetz ; xml2rfc-dev@ietf.org; RFC > Editor > Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In > Section 2.42, > > On 2018-10-09 19:44, Henrik Levkowetz wrote: > > > > On 2018-10-09 19:30, Julian Reschke wrote: > >> On 2018-10-09 17:56, Henrik Levkowetz wrote: > >>> ... > >>>> Reminder: as author of a processor you are free to augment the > >>>> intermediate format with any information you want. But that doesn't > >>>> mean it needs to surface in the author visible vocabulary. > >>> > >>> Agreed. But that's a somewhat different issue. Here I'm concerned > >>> with the incompleteness of the published archival XML, in view of > >>> the RFC7998 statement below, rather than whatever bells processors may > choose to add. > >> > >> And I don't think that the absence of ToC and Index are a problem. > >> Not do I think that inserting the container for the references is a problem. > > > > Problem? Depends on what you expect from the prepped archival document. > > > > You could use v2 xml as archival XML, if you wanted; it would not be a > > 'problem', either. > > > > But what is really desired from the archival format? > > That's a good question. > > I already wasn't a fan of the "insert derived content", because, well, it can be > derived. > > The difference here is that the information you are missing truly is insignificant > for the meaning of the RFC. > > > ... > >> 1) I then believe that we need to clarify what should > >> contain. I never considered the ToC to be part of it. > > > > Yes. I'd be perfectly happy with building this in a or in some > > other fashion, if that would be cleaner. > > > >> 2) How exactly does this content help in producing the ToC for HTML > >> (which will require special CSS) or in paged formats (where one would > >> expect page numbers)? > > > > Of course the details of the rendering based on this will be specific > > to the individual renderers. You can look at the v3 text-renderer > > code now; I can point at the html-renderer code when I've written it. > > The representation above is true to the document structure and > > provides the s needed for linkage, which is where any ToC > > rendering needs to start. > > In a paged medium, I'd expect the inserted page number on the right hand > side, with the line filled by dots (missing a more technical term). > > This really is different from a regular list. Additionally, the rendering now needs to detect this both of these as special sections and not do the normal rendering on them. If they just do the derivation themselves they can treat it however they want. This would include things like depth of ToC, different formatting for different levels. I agree w/ Julian that this seems to be totally un-interesting from an archival point of view. > > >>> And here's the start of an index: > >>> > >>> > >>> > >>>
    pn="section-appendix.b"> > >>> Index > >>> > >>> target="rfc.index.L">L > >>> target="rfc.index.T">T > >>> > >>>
      > >>>
    • > >>> > >>> target="rfc.index.L">L > >>> > >>>
        > >>>
      • > >>> list > >>> > >>> list > >>> list > >>> > >>> .... > >>> > >> > >> Now do you prevent additional index sections from being inserted when > >> the preptool is run multiple times? > > > > There are two reasonable approaches, I think: skip new insertion if > > already prepped, and replace wholly if already prepped. The current > > code does the first, but I don't have any particular preference in the matter. > > The point was: on an input document, how do you detect that a
        inside > already contains an index? So you need to detect that there is an index or a ToC and change behavior based on if it is there or not? If it was there I think that replacing it with a newly computed one is far preferable. If I change things in the prep version, like insert a new index reference, then it should be picked up and rendered. Similarly if I change the ordering of sections this needs to be detected as dealt with as well. Jim > > Best regards, Julian > > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc-dev From nobody Tue Oct 9 11:27:14 2018 Return-Path: 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 D7FCF1277C8 for ; Tue, 9 Oct 2018 11:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 so3lcijLlomA for ; Tue, 9 Oct 2018 11:27:07 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E858128CE4 for ; Tue, 9 Oct 2018 11:27:07 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:60266 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g9wio-000310-9l; Tue, 09 Oct 2018 11:27:07 -0700 To: Jim Schaad , 'Heather Flanagan' , xml2rfc-dev@ietf.org References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> <050c01d45d97$714e51b0$53eaf510$@augustcellars.com> <052b01d45daa$87e71980$97b54c80$@augustcellars.com> <656afb2e-3aa7-53c5-5e39-55050387aa20@levkowetz.com> <0bac2940-1abc-87e3-35e7-f6d621e83f1c@rfc-editor.org> <073e01d45ffc$fc161550$f4423ff0$@augustcellars.com> From: Henrik Levkowetz Message-ID: Date: Tue, 9 Oct 2018 20:26:58 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <073e01d45ffc$fc161550$f4423ff0$@augustcellars.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dq6GFhsWntEju2ixOTepjmsVoKDhJO7cg" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, rse@rfc-editor.org, ietf@augustcellars.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, In Section 2.54,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 18:27:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dq6GFhsWntEju2ixOTepjmsVoKDhJO7cg Content-Type: multipart/mixed; boundary="BakCrbOBQLlkWKJaO3iu7w1ow1UFwJpSG"; protected-headers="v1" From: Henrik Levkowetz To: Jim Schaad , 'Heather Flanagan' , xml2rfc-dev@ietf.org Message-ID: Subject: Re: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, In Section 2.54,
    References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> <050c01d45d97$714e51b0$53eaf510$@augustcellars.com> <052b01d45daa$87e71980$97b54c80$@augustcellars.com> <656afb2e-3aa7-53c5-5e39-55050387aa20@levkowetz.com> <0bac2940-1abc-87e3-35e7-f6d621e83f1c@rfc-editor.org> <073e01d45ffc$fc161550$f4423ff0$@augustcellars.com> In-Reply-To: <073e01d45ffc$fc161550$f4423ff0$@augustcellars.com> --BakCrbOBQLlkWKJaO3iu7w1ow1UFwJpSG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-10-09 20:22, Jim Schaad wrote: >=20 >> -----Original Message----- >> From: xml2rfc-dev On Behalf Of Heather >> Flanagan >> Sent: Tuesday, October 9, 2018 11:01 AM >> To: xml2rfc-dev@ietf.org >> Subject: Re: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991,= In >> Section 2.54,
    >>=20 >>=20 >> On 10/6/18 2:53 PM, Henrik Levkowetz wrote: >> > 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 figure= s >> >>>> and tables. >> >>> Till now, both have been centered. That can be changed. >> >>> >> >> No, I would not change this. I would keep the centering for the >> >> caption. The next interesting question the caption is wider than t= he >> >> table should it be wrapped to the table width or run on past the ed= ge >> >> 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. >> > >>=20 >> I'm not entirely sure how this issue differs from the table alignment > discussed >> in issues 40 and 9? >=20 > The first was where do you place the table on the page. This one is ho= w do > you place the caption in the table. Much more succinct than my reply :-) Henrik --BakCrbOBQLlkWKJaO3iu7w1ow1UFwJpSG-- --dq6GFhsWntEju2ixOTepjmsVoKDhJO7cg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu88vIACgkQTptXS4+7 FxoH8RAApZztuOCVY8dTxyUx7KX1UqzqIrvzP+K3GSVI8MhYkV2OsnPncpeuRruc xaArSjcp6t2zhMJkXE9Dr2wEti0zWxnhGDSpbKUW9BDNLcCWZw7q0tOKGroASl57 BwFJAN0B8gms+uD8woORXYGEECFmPvmicRFD3v1/AcMoTIiGWyfohwVgApEl8NLe 1+EIQxU5LwxH+lvUnXk+h7WWb1AenBOBrSrK8iEKLh/iVq7o5yp5QxGKZPr8CHhI Baja+TIfDUz+iBQzc7mktx3FXya7zZOsopac9yaifwyOEk+4LUCcHFiZfjJtzH6F aaFK5sFhWYE7xOqqv4vIh3YcSQY/DKHGRFlpyBJl0BobhWyE46WUTF5RBMSJq94i 2rmRVoWSnD6L3KKvOKW74st4YL3EyxmI+VX3dcUaAXYoUUOdytzJYy699j3jUW2Y 4+zFI2IsgLLOMgKt9DgnPEDuR0+g5bATBOfuhYe2X7VARTDar2zRGpq38KQYCYJ2 GSGpkJ+TK1GxYuyqnr5gPGONT0oHXFjkOeRqJKEFsImA043vUx4Po3yXqQ8gn2q5 HdyoBkUNsP7mP0eq+Q+2TQW8OIHzpnSEL/1Og/pJRv6u4Hujun9BDrKiWaVX4Zuo b4g70Yb3tWAN0C89XeOhpeNbaRMovyU/zW8YfG5PuzmqUWtUwyY= =2ngr -----END PGP SIGNATURE----- --dq6GFhsWntEju2ixOTepjmsVoKDhJO7cg-- From nobody Tue Oct 9 12:33:48 2018 Return-Path: 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 BEA4E12F1A2 for ; Tue, 9 Oct 2018 12:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 GqIp7TvVwZrU for ; Tue, 9 Oct 2018 12:33:37 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10790130D7A for ; Tue, 9 Oct 2018 12:33:37 -0700 (PDT) Received: from Jude (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 9 Oct 2018 12:28:31 -0700 From: Jim Schaad To: 'Julian Reschke' , 'Heather Flanagan' , References: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> <065401d45f46$d92c3710$8b84a530$@augustcellars.com> <4308bb9a-14ef-ca1c-03b3-2d1d09bc95a5@levkowetz.com> <4e4af1df-37b8-c180-93d8-14104fe2281c@gmx.de> In-Reply-To: Date: Tue, 9 Oct 2018 12:33:05 -0700 Message-ID: <075301d46006$e88ef420$b9acdc60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLAbTej30L1EUF5/gxtYUDerJ/dBAHYXIfkAiclg5oDoS022gFG0/brAggLbMkA6QYHCgHMCXSOAprEorEBxe0UvgF6NAGlAkouxHSikOWX8A== Content-Language: en-us X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 19:33:47 -0000 > -----Original Message----- > From: xml2rfc-dev On Behalf Of Julian > Reschke > Sent: Tuesday, October 9, 2018 11:12 AM > To: Heather Flanagan ; xml2rfc-dev@ietf.org > Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, = In > Section 2.40.2, "quoteTitle" >=20 > On 2018-10-09 20:05, Heather Flanagan wrote: > > > > On 10/8/18 10:20 PM, Henrik Levkowetz wrote: > >> On 2018-10-09 06:51, Julian Reschke wrote: > >>> On 2018-10-08 23:41, Henrik Levkowetz wrote: > >>>> ... > >>>> Currently, reference files are only being created according to = the > >>>> v2 schema. If we begin to create them according to v3 (because = of > >>>> richer > >>>> semantics) we may have to maintain separate, parallel bibxml > >>>> repositories, yes. > >>>> ... > >>> That wiil lead to friction. > >>> > >>> Maybe we should reconsider any change that makes those = incompatible. > >> Ack; looking at those again makes sense, in view of the possibility > >> of having to maintain different reference repositories. > >> > > > > Hola a todos, > > > > Two questions: first, I'm not sure what this means for when we do > > switch over to v3 - there will be changes to the reference format, = so > > does that mean we'll have to be ready with a 100% switchover to an > > alternate repository when we go live? Second, when you say = "reconsider > > any change >=20 > I guess it would be an additional repository. >=20 > > that makes those incompatible" are you proposing changes to the v3 > > vocabulary to avoid incompatible changes to v2? >=20 > Yes. I believe we should undo the change to (moving under > ), and just restore what we have in v2. What about the seriesInfo that is in the front for identifying the = document? Are you going to move that to the same level as front, = middle, back? Jim >=20 > Best regards, Julian >=20 > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc-dev From nobody Tue Oct 9 12:36:30 2018 Return-Path: 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 73A54129619 for ; Tue, 9 Oct 2018 12:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 qGLQ8NxQsoUc for ; Tue, 9 Oct 2018 12:36:27 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54C851277C8 for ; Tue, 9 Oct 2018 12:36:27 -0700 (PDT) Received: from Jude (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 9 Oct 2018 12:31:44 -0700 From: Jim Schaad To: 'Henrik Levkowetz' , 'Heather Flanagan' , References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> <8b71a263-a280-270a-4fb4-7e0a4e2abb0a@gmx.de> <926f11a0-3d4b-ffe0-d7b5-c7ec51f1083b@levkowetz.com> <10b47376-f6a3-0df0-11c4-fe3a2a18f4a4@rfc-editor.org> In-Reply-To: Date: Tue, 9 Oct 2018 12:36:18 -0700 Message-ID: <075701d46007$5b52d620$11f88260$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKMgMAK0VYejNR5SBI3Ju6yzqYpwAJgfmWrAYJ4yUYC/7eaQwLlkh8fAyVeB0sB5WiLFwJwh7rqAZk1LJUBuyD16wKBMloQou5ENNA= Content-Language: en-us X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 19:36:29 -0000 > -----Original Message----- > From: xml2rfc-dev On Behalf Of Henrik > Levkowetz > Sent: Tuesday, October 9, 2018 11:26 AM > To: Heather Flanagan ; xml2rfc-dev@ietf.org > Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, = In > Section 2.42, >=20 > Hi Heather, >=20 > On 2018-10-09 20:14, Heather Flanagan wrote: > > Hola a todos, > > > > On 10/9/18 10:44 AM, Henrik Levkowetz wrote: > >> But what is really desired from the archival format? > > > > Complete content. I tried to capture this in RFC 7990, Section 6.1 > > "XML for RFCs" > > > > Key points regarding the XML format: > > > > o The canonical format for RFCs is XML using the xml2rfc = version 3 > > (xml2rfc v3) vocabulary. The XML file must contain all > > information necessary to render a variety of formats; any = question > > about what was intended in the publication will be answered = from > > this format. > > > > o Authors may submit documents using the xml2rfc v2 vocabulary, = but > > the final publication will be converted to use the xml2rfc v3 > > vocabulary. > > > > o SVG is supported and will be embedded in the final XML file. > > > > o There will be automatically generated identifiers for = sections, > > paragraphs, figures, and tables in the final XML file. > > > > o The XML file will not contain any xml2rfc v3 vocabulary = elements > > or attributes that have been marked deprecated. > > > > o A DTD will no longer be used. The grammar will be defined = using > > RELAX NG [RNC]. > > > > o The final XML file will contain, verbatim, the appropriate > > boilerplate as applicable at time of publication specified by = RFC > > 7841 [RFC7841] or its successors. > > > > o The final XML will be self-contained with all the information > > known at publication time. For instance, all features that > > reference externally defined input will be expanded. This > > includes all uses of xinclude, src attributes (such as in > > or elements), include-like processing > > instructions, and externally defined entities. > > > > o The final XML will not contain comments or processing > > instructions. > > > > o The final XML will not contain src attributes for = or > > elements. > > > > > > Does this answer your question? >=20 > For me, I guess it does; for me it means that ToC, enclosing = References section, > and Index should all be part of the canonical format. For me, RFC = 7998 Section > 1, Introduction, points in the same direction. I agree w/ the References. I don't agree w/ the ToC or index as this = information can be derived from the XML file in a deterministic fashion = and would not change. Jim >=20 >=20 > Best regards, >=20 > Henrik From nobody Tue Oct 9 21:45:03 2018 Return-Path: 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 9B5A2130E74 for ; Tue, 9 Oct 2018 21:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 VTdeGy6GjEqi for ; Tue, 9 Oct 2018 21:45:00 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83077130E73 for ; Tue, 9 Oct 2018 21:44:59 -0700 (PDT) Received: from [192.168.178.20] ([91.61.63.132]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M3eDF-1fs9pc2d0r-00rH2e; Wed, 10 Oct 2018 06:44:21 +0200 Received: from [192.168.178.20] ([91.61.63.132]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M3eDF-1fs9pc2d0r-00rH2e; Wed, 10 Oct 2018 06:44:21 +0200 To: Jim Schaad , 'Heather Flanagan' , xml2rfc-dev@ietf.org References: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> <065401d45f46$d92c3710$8b84a530$@augustcellars.com> <4308bb9a-14ef-ca1c-03b3-2d1d09bc95a5@levkowetz.com> <4e4af1df-37b8-c180-93d8-14104fe2281c@gmx.de> <075301d46006$e88ef420$b9acdc60$@augustcellars.com> From: Julian Reschke Message-ID: Date: Wed, 10 Oct 2018 06:44:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <075301d46006$e88ef420$b9acdc60$@augustcellars.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:DGf2aYlceuIIOoAUginVuaV9atvs8EY39e2lnLcUuhi+7C0PSUm H/+8cH/XGiggpkjaZhZT0xewE7e9pmfSRIFs4XLHDEKIgdILBPUzrjW94P8yDDKsqLm88W+ FxKHCd5BfLsggKRSMdft3C1x6oVHKL7TKR+Ycty1GC6u9iwjRpY7HeNeohn6K6YopDJ0Jln g4pijUc33ZEbLfvecc9KA== X-UI-Out-Filterresults: notjunk:1;V01:K0:OPiMfjM5WJA=:vyZN4F5pHNsz9qIYxZ7lUZ MH0bw05RqdB8S5D4zU6TsFb2V5urMBZ+wbsG6L4ww0fz7+0FDyb416ZHMAkHd1rFnPkIB+1yI 1ryT4SLb5zxmDW/h1MxuGmFG5Y2egD1sN7qzbjoptc/aQew/Rkn1q/kgfOizwzR+KQQRimI7T eKLgFJASJs7Oy0koi5nlzOJaaermgw90p5Mqw0qHc4kBj6o+ucPg5WXjSoTgYtW25NArc9T4b Hj518GBQr7YDdX8fPfIhKq/wKR6GW1Yh90gha3ja/aJEPjt6dcSFDNxEeiO+OsDnXsJ1Ohd83 PO7jmhW/wPLmr6+ob5KER1vbUIIsinwOirM9QhRakb2Dzhg8c9GRLiKAAec22gwc03BI9diUo gGcoxw9RQLyscndoXaeV/wHUpg4Xbt67W1rhzxUfPSumaGcEeayGj3yeerv/BJZ12ijHrOLLS iL/7mP213EcOq8ODu6kMCoMI3RmQhfiRVZ/oKmTYpj8medVaukZCoO51mhYchzcbeDdZ5JlW2 wxqwek38bJXaNS5YKuWGpASZWgl4HjPMtYxrC7zuvzbwElkD1lhdCgfvW1DDlkhi+uMW5qTOq jC88+8BpWKWM9XvKFMnCtMqpqJScDcNp5CqBq7dt3c/OeA/rWOLCdEfKXq2GFEGDVbES53HiA HU1zeyHZaw9Hr60JZVNru4yNo7dJUV7qC2/PkE37h60CBHlCbyKlQixeTPiXmNUfRNGFnfJcy IRSV/F/vtnx0IT7J5OVr3bxkHCxCdrSfbY0DAdkMl21fN9L2CWRLH62wbnebjWbDNnDQyr+m8 LcKub/3RCBNmi0G7MX7aaxwyHQpDYzGyIThDVzlAUQuwisytZA= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 04:45:02 -0000 On 2018-10-09 21:33, Jim Schaad wrote: > > >> -----Original Message----- >> From: xml2rfc-dev On Behalf Of Julian >> Reschke >> Sent: Tuesday, October 9, 2018 11:12 AM >> To: Heather Flanagan ; xml2rfc-dev@ietf.org >> Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In >> Section 2.40.2, "quoteTitle" >> >> On 2018-10-09 20:05, Heather Flanagan wrote: >>> >>> On 10/8/18 10:20 PM, Henrik Levkowetz wrote: >>>> On 2018-10-09 06:51, Julian Reschke wrote: >>>>> On 2018-10-08 23:41, Henrik Levkowetz wrote: >>>>>> ... >>>>>> Currently, reference files are only being created according to the >>>>>> v2 schema. If we begin to create them according to v3 (because of >>>>>> richer >>>>>> semantics) we may have to maintain separate, parallel bibxml >>>>>> repositories, yes. >>>>>> ... >>>>> That wiil lead to friction. >>>>> >>>>> Maybe we should reconsider any change that makes those incompatible. >>>> Ack; looking at those again makes sense, in view of the possibility >>>> of having to maintain different reference repositories. >>>> >>> >>> Hola a todos, >>> >>> Two questions: first, I'm not sure what this means for when we do >>> switch over to v3 - there will be changes to the reference format, so >>> does that mean we'll have to be ready with a 100% switchover to an >>> alternate repository when we go live? Second, when you say "reconsider >>> any change >> >> I guess it would be an additional repository. >> >>> that makes those incompatible" are you proposing changes to the v3 >>> vocabulary to avoid incompatible changes to v2? >> >> Yes. I believe we should undo the change to (moving under >> ), and just restore what we have in v2. > > What about the seriesInfo that is in the front for identifying the document? Are you going to move that to the same level as front, middle, back? No, my proposal would be to entirely back out the change, and to restore the attributes that we had on instead. Best regards, Julian From nobody Tue Oct 9 22:02:37 2018 Return-Path: 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 C8841130E79 for ; Tue, 9 Oct 2018 22:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 dofQs0yZBCHB for ; Tue, 9 Oct 2018 22:02:34 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A17F130E7E for ; Tue, 9 Oct 2018 22:02:33 -0700 (PDT) Received: from [192.168.178.20] ([91.61.63.132]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LhNwC-1fNce84Bdo-00mejH; Wed, 10 Oct 2018 07:01:45 +0200 Received: from [192.168.178.20] ([91.61.63.132]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LhNwC-1fNce84Bdo-00mejH; Wed, 10 Oct 2018 07:01:45 +0200 To: Jim Schaad , 'Henrik Levkowetz' , 'Heather Flanagan' , xml2rfc-dev@ietf.org References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> <8b71a263-a280-270a-4fb4-7e0a4e2abb0a@gmx.de> <926f11a0-3d4b-ffe0-d7b5-c7ec51f1083b@levkowetz.com> <10b47376-f6a3-0df0-11c4-fe3a2a18f4a4@rfc-editor.org> <075701d46007$5b52d620$11f88260$@augustcellars.com> From: Julian Reschke Message-ID: <369bdaa3-264b-57e0-c7ff-ec7f24f125c5@gmx.de> Date: Wed, 10 Oct 2018 07:01:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <075701d46007$5b52d620$11f88260$@augustcellars.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:UMeEcHOkwHEZkIO375lalhsf0y46VKBjzbP6g/XFW0s1LRkAx2C XqwdomoLRcWA9dR/tQbQXaz/k1q48GT8VZOevKj5tY6GcOwDvA5bGZKkypmqNFM+d6l/KVp ex9kMql9sZawCoZU8CZQXniLEN1b/9o4SLs/DQmYHJ8NQqud6Z/+ul8rIn4suxI+wligWMs KKrZxiK6S9/IQUgr002qQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:GXZU1Cu4qHg=:2VzhSZGE3WwIC0bS9dFykC fDa4KWMwlVBkpI+HHvaMSD3Jkh8zlo3nQXKTpsRrOJr3W3UuwY3ZpqquNqO51XWFISske7xu0 zI1G8EDK9o2GBtLWYFEL8xnKZM9w+uo5JWp0U2JpoH3DskdjO8x7qGixTZ4CeaCSuRHO20u1V u52lu5eJBAwx8dSVXSUaDTVZdtGefc1ZXlxnuUF9gzXEhJEAwvsYNOUonVLJgxw6H+4N6yf+a qVdgTf6D6DgPOKAOdSc9EDrVlmMmHo7FZSAVO46Z6EUPiNNvwYjUm2Wk9UUgVTzgkDuQV3JJm +n8pPyIaXEzklQwABj2CLQs+uKB1cYhp+kj4EWT0zcYlmUiSyHHH9ETxUJQwxb7c0dvIwcvdp CcsnYcLl6CuIycm4cSzZ2CfFztuYH4yTsv485gwaKlI+NBuF3eIYHpm0YcmMADLFsMagL0abP /DiM1Ylv3vK0tunaG8p/COv78OymMWLoArSk6TgDDiYX7ljxK7fuMtVdbRx8JS9+aaVNL//WD 4+f3GVaJxaMyC9GGQd94Tl57YBASNdubZdmy4fA754ql1rou7PCovdh5oQJYa4Fozcc1iQ6jn rpczeP7TP/6cj/XUYu5JVLrWS9rtY983GlWW0GyH5amWsKxW8BnWHJerz+XlJPvuGSrbCM9dM TAOOjWyxzlItLiEjHVuPbPMQez0wby2UXqxQ393NSrdf3ZqUSJH3+mrK05YQANxd8W2u41M8B bxykK4VwkO0AcM8BMMMwfBtC/kFftNwiLm6vEvpn6HvCqFaieLmenqNZYkUh38u9YvqlMV3es 6JLHN0hxgFF8O+aUA+DUcSolHsMGFx0L5yslkJ8C+TMahITBOA= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 05:02:36 -0000 On 2018-10-09 21:36, Jim Schaad wrote: > > >> -----Original Message----- >> From: xml2rfc-dev On Behalf Of Henrik >> Levkowetz >> Sent: Tuesday, October 9, 2018 11:26 AM >> To: Heather Flanagan ; xml2rfc-dev@ietf.org >> Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In >> Section 2.42, >> >> Hi Heather, >> >> On 2018-10-09 20:14, Heather Flanagan wrote: >>> Hola a todos, >>> >>> On 10/9/18 10:44 AM, Henrik Levkowetz wrote: >>>> But what is really desired from the archival format? >>> >>> Complete content. I tried to capture this in RFC 7990, Section 6.1 >>> "XML for RFCs" >>> >>> Key points regarding the XML format: >>> >>> o The canonical format for RFCs is XML using the xml2rfc version 3 >>> (xml2rfc v3) vocabulary. The XML file must contain all >>> information necessary to render a variety of formats; any question >>> about what was intended in the publication will be answered from >>> this format. >>> >>> o Authors may submit documents using the xml2rfc v2 vocabulary, but >>> the final publication will be converted to use the xml2rfc v3 >>> vocabulary. >>> >>> o SVG is supported and will be embedded in the final XML file. >>> >>> o There will be automatically generated identifiers for sections, >>> paragraphs, figures, and tables in the final XML file. >>> >>> o The XML file will not contain any xml2rfc v3 vocabulary elements >>> or attributes that have been marked deprecated. >>> >>> o A DTD will no longer be used. The grammar will be defined using >>> RELAX NG [RNC]. >>> >>> o The final XML file will contain, verbatim, the appropriate >>> boilerplate as applicable at time of publication specified by RFC >>> 7841 [RFC7841] or its successors. >>> >>> o The final XML will be self-contained with all the information >>> known at publication time. For instance, all features that >>> reference externally defined input will be expanded. This >>> includes all uses of xinclude, src attributes (such as in >>> or elements), include-like processing >>> instructions, and externally defined entities. >>> >>> o The final XML will not contain comments or processing >>> instructions. >>> >>> o The final XML will not contain src attributes for or >>> elements. >>> >>> >>> Does this answer your question? >> >> For me, I guess it does; for me it means that ToC, enclosing References section, >> and Index should all be part of the canonical format. For me, RFC 7998 Section >> 1, Introduction, points in the same direction. > > I agree w/ the References. I don't agree w/ the ToC or index as this information can be derived from the XML file in a deterministic fashion and would not change. The same is true for . We have proof of that because we've been doing it without problems for over 10 years. Best regards, Julian From nobody Wed Oct 10 04:27:27 2018 Return-Path: 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 E5009130ED9 for ; Wed, 10 Oct 2018 04:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 nFvDWSEQ3c_a for ; Wed, 10 Oct 2018 04:27:24 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A574130ED6 for ; Wed, 10 Oct 2018 04:27:24 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:51221 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1gACeB-0007hW-2v; Wed, 10 Oct 2018 04:27:23 -0700 To: Julian Reschke , Jim Schaad , 'Heather Flanagan' , xml2rfc-dev@ietf.org References: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> <065401d45f46$d92c3710$8b84a530$@augustcellars.com> <4308bb9a-14ef-ca1c-03b3-2d1d09bc95a5@levkowetz.com> <4e4af1df-37b8-c180-93d8-14104fe2281c@gmx.de> <075301d46006$e88ef420$b9acdc60$@augustcellars.com> From: Henrik Levkowetz Message-ID: <96e521a6-3534-c986-ac63-e03a12e64c94@levkowetz.com> Date: Wed, 10 Oct 2018 13:27:08 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4vO2Q9ps7agaMTKEbb3NQl8WcnNdu3cnP" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, rse@rfc-editor.org, ietf@augustcellars.com, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 11:27:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4vO2Q9ps7agaMTKEbb3NQl8WcnNdu3cnP Content-Type: multipart/mixed; boundary="HKDiHk8lvKBnjlDvPi0WDL7UVdxCR3fUX"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , Jim Schaad , 'Heather Flanagan' , xml2rfc-dev@ietf.org Message-ID: <96e521a6-3534-c986-ac63-e03a12e64c94@levkowetz.com> Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" References: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> <065401d45f46$d92c3710$8b84a530$@augustcellars.com> <4308bb9a-14ef-ca1c-03b3-2d1d09bc95a5@levkowetz.com> <4e4af1df-37b8-c180-93d8-14104fe2281c@gmx.de> <075301d46006$e88ef420$b9acdc60$@augustcellars.com> In-Reply-To: --HKDiHk8lvKBnjlDvPi0WDL7UVdxCR3fUX Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-10-10 06:44, Julian Reschke wrote: > On 2018-10-09 21:33, Jim Schaad wrote: >>=20 >>=20 >>> -----Original Message----- >>> From: xml2rfc-dev On Behalf Of Julian >>> Reschke >>> Sent: Tuesday, October 9, 2018 11:12 AM >>> To: Heather Flanagan ; xml2rfc-dev@ietf.org >>> Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991= , In >>> Section 2.40.2, "quoteTitle" >>> >>> On 2018-10-09 20:05, Heather Flanagan wrote: >>>> >>>> On 10/8/18 10:20 PM, Henrik Levkowetz wrote: >>>>> On 2018-10-09 06:51, Julian Reschke wrote: >>>>>> On 2018-10-08 23:41, Henrik Levkowetz wrote: >>>>>>> ... >>>>>>> Currently, reference files are only being created according to th= e >>>>>>> v2 schema. If we begin to create them according to v3 (because o= f >>>>>>> richer >>>>>>> semantics) we may have to maintain separate, parallel bibxml >>>>>>> repositories, yes. >>>>>>> ... >>>>>> That wiil lead to friction. >>>>>> >>>>>> Maybe we should reconsider any change that makes those incompatibl= e. >>>>> Ack; looking at those again makes sense, in view of the possibility= >>>>> of having to maintain different reference repositories. >>>>> >>>> >>>> Hola a todos, >>>> >>>> Two questions: first, I'm not sure what this means for when we do >>>> switch over to v3 - there will be changes to the reference format, s= o >>>> does that mean we'll have to be ready with a 100% switchover to an >>>> alternate repository when we go live? Second, when you say "reconsid= er >>>> any change >>> >>> I guess it would be an additional repository. >>> >>>> that makes those incompatible" are you proposing changes to the v3 >>>> vocabulary to avoid incompatible changes to v2? >>> >>> Yes. I believe we should undo the change to (moving unde= r >>> ), and just restore what we have in v2. >>=20 >> What about the seriesInfo that is in the front for identifying the doc= ument? Are you going to move that to the same level as front, middle, ba= ck? >=20 > No, my proposal would be to entirely back out the change, and to restor= e=20 > the attributes that we had on instead. I strongly support this. I mention a number of issues related to the changes to seriesInfo in draft-levkowetz-xml2rfc-v3-implementation-notes;= in Sections 3.1.10, 3.1.11, 3.1.12, 3.2.1, 4.1.5, 4.4.11, and 4.4.12. Best regards, Henrik --HKDiHk8lvKBnjlDvPi0WDL7UVdxCR3fUX-- --4vO2Q9ps7agaMTKEbb3NQl8WcnNdu3cnP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu94gwACgkQTptXS4+7 FxpQEBAAiLBdxY/gqGGRb8Tptllh2SIp0JyGUQLmENvCtBjfYhvEWwrtLXDjNBAX b2OHrihWRuFmW+PrHdIsO0oGm+wB6oZAfswZZUJOqfmD/ioxJw5ilveFFXYTXMsk keKM160GpqYPyELoBQ7Z4QR6QIplw1vGVRBQEY1vdBm9Ivnez6qJiD7bQAZXwwwm 7etwzsQ8Q3wQIgUXX5tU09ZuEsvQ1jGz5iPYpTnfZppcvZrxTyiwjifi3TYeXkyr rXxfIyocefbJGoWfbVlu0mWBzcT25TzaHDo2VCmOq5xxp2Y2WGfaUUzBta9gO/5F EgRTRfP0r9YcF1V+6rjRU+nJRJg2c8JOCgHk6Yppphe0e05zRNq3oJO1sjISoY3s ltrmz0CIbKX0s4z7WjebywUFca8YvByjkFBxdEKahz1recUPuz28CiaFg2u1JVCr yQ2RKXO7+UMenP5ps+Sfg1o7NzC7gLla+JSDjAILeBFXL3IHKED5lf+xB0hV1hQe XER9AjPOYM/yK0vJ6Av+sLQEToAyyOvm1iwTwetKsiqBwJMgqg8zg+AZ0QXL6VS8 +TNPiYHek1GRr98Ueu4H/YO372iyKfUvuJ1sMe0rPpZNoCr0jV6BKdbxjJP+oaCM SaPjR7ELcvWJD3AT1P8UXQrNArzkzS8QpyAqDK9ulNx/dCWUx78= =GLVq -----END PGP SIGNATURE----- --4vO2Q9ps7agaMTKEbb3NQl8WcnNdu3cnP-- From nobody Wed Oct 10 04:51:28 2018 Return-Path: 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 38679130EAC for ; Wed, 10 Oct 2018 04:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 SKDiexB_IeDU for ; Wed, 10 Oct 2018 04:51:25 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 629FF130EEC for ; Wed, 10 Oct 2018 04:51:25 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:51382 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1gAD1Q-0000Xx-G1; Wed, 10 Oct 2018 04:51:24 -0700 To: Heather Flanagan , xml2rfc-dev@ietf.org References: From: Henrik Levkowetz Message-ID: Date: Wed, 10 Oct 2018 13:51:17 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Nlu5NcrHAjc3t25jn8CKMdv5cb5np2rdH" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, rse@rfc-editor.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] Summary of issues - week of 1 October 2018 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 11:51:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Nlu5NcrHAjc3t25jn8CKMdv5cb5np2rdH Content-Type: multipart/mixed; boundary="bF6fWr6hKjiFO5wDMNs4hMFkPdCdkrvaV"; protected-headers="v1" From: Henrik Levkowetz To: Heather Flanagan , xml2rfc-dev@ietf.org Message-ID: Subject: Re: [xml2rfc-dev] Summary of issues - week of 1 October 2018 References: In-Reply-To: --bF6fWr6hKjiFO5wDMNs4hMFkPdCdkrvaV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thank you, Heather. Best regards, Henrik On 2018-10-09 20:00, Heather Flanagan wrote: > Hola a todos, >=20 > Here's what I took from last week's discussions. >=20 > ---- >=20 > Issue #34 - consensus to remove the restriction "It is an error to have= =20 > both a "src" attribute and content in the > element." >=20 > Issue #35 - consensus reached. Allow blockquotes in
  • >=20 > Issue #36 - consensus reached. Leave "name" attribute as is. >=20 > Issue #37 - decision made. Remove
    from the v3 spec. >=20 > Issue #38 - consensus reached. Change "hanging" to "newline" throughout= =2E >=20 > Issue #39 - consensus reached. Revise text to "indent" attribute. >=20 > Issue #40 - consensus reached (also, duplicate of #9). Allow "align" fo= r=20 > tables. >=20 > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc-dev >=20 --bF6fWr6hKjiFO5wDMNs4hMFkPdCdkrvaV-- --Nlu5NcrHAjc3t25jn8CKMdv5cb5np2rdH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu957UACgkQTptXS4+7 FxpQnxAAyJ9V751yByElYuZiGWAop/ROCEujssRVNgbsVHL7blhQQvLPzORztpGJ iwauHI2oS/XW7YFe3ENYX08qkkyBoixmNpYMXbcOLR658S3cyHz5Yfxa1UlXuV+i cRDHlS1ZhoHG7nOoA+W3ruY2vy3V+l66Q3OIT+eMym4Mugru9CGp4H39GERyQMbD T4mBWVdOSHeLp6Bz+jLB+4J8zS/983vPqv1IEzv0awU8PCwKO0PU6J+eS6XhTJ+A DO7LlqC9aRC2E6Q8mXNE3Yl9OLJ15Z6t04as/LOR6UpRWn0kGKu7w0rRUuR2U8YS e8a84SQ9j8yizXfgFxQpdaCS4LFk9Pt9HPzXCA5IVUZ5MRKhnbMyGm87zm14SyYi LzxaTNujCV+jHnoM4Enxc6VXx9i6h/bmVqmGi/hUv4q78ayjEhvz21RjKvRgAJ5o wzTJGlddMGy1z8U81d7L9LQ7kz5GeAHV6XctjR3FA0sZHo7sJqlShinXqx9JojSR PwVbdkC+gbaa69OnsbE2H4Kab+5RU0iLNpFVTb7GN+ZwHfViY23sDg2e7uCYL5IP HeHYqweJb8aQraMNnQIycW21QlPtHsqkM+QlZnhf6EtX21wua1I+5Eu3SZDBE28s fNQHF3UGtI92S4xpWaWs0errReN57cR1XDRreNRHWhPOvDLbrd8= =JZyf -----END PGP SIGNATURE----- --Nlu5NcrHAjc3t25jn8CKMdv5cb5np2rdH-- From nobody Thu Oct 11 08:31:01 2018 Return-Path: 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 6D42E130DE6; Thu, 11 Oct 2018 08:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 Y_sAB1iujPDu; Thu, 11 Oct 2018 08:30:52 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE504130E5F; Thu, 11 Oct 2018 08:30:50 -0700 (PDT) Received: from henrik by durif.tools.ietf.org with local (Exim 4.80) (envelope-from ) id 1gAcvK-0005b2-Ml; Thu, 11 Oct 2018 08:30:50 -0700 To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org Cc: rfc-markdown@ietf.org Message-Id: From: Henrik Levkowetz Date: Thu, 11 Oct 2018 08:30:50 -0700 X-SA-Exim-Connect-IP: X-SA-Exim-Rcpt-To: rfc-markdown@ietf.org, xml2rfc-dev@ietf.org, xml2rfc@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc-dev] New xml2rfc release: v2.11.1 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 15:30:55 -0000 Hi, This is an automatic notification about a new xml2rfc release, v2.11.1, generated when running the mkrelease script. Release notes: xml2rfc (2.11.1) ietf; urgency=medium * Changed linebreaking for URLs in boilerplate and references to the old behaviour (don't break), added stream abbreviations according to RFC5741, and changed EMail: to Email: in RFC mode. * Added the align attribute for element
    • to the schema. * Changed the v2v3 converter handling of the table align attribute, and fixed an issue with lost whitespace after . * Added STD to the seriesInfo sort order list. * Added an error message for month content that is neither a month name or a number. -- Henrik Levkowetz 11 Oct 2018 08:28:43 -0700 The preferred way to install xml2rfc is by doing 'pip install xml2rfc', and 'pip install --upgrade xml2rfc' to upgrade. If there are system- installed python modules which pip will not upgrade, you may have to use 'pip install --upgrade --no-deps xml2rfc' and install dependencies manually. The new version is also available through SVN checkout, with 'svn checkout http://svn.tools.ietf.org/svn/tools/xml2rfc/tags/cli/2.11.1' Regards, Henrik (via the mkrelease script) From nobody Thu Oct 11 09:51:41 2018 Return-Path: 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 D5FF2130E6B for ; Thu, 11 Oct 2018 09:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 qWKQUHy5nJPG for ; Thu, 11 Oct 2018 09:51:37 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18CD7130EBB for ; Thu, 11 Oct 2018 09:51:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 305681CAE56 for ; Thu, 11 Oct 2018 09:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCzie8BzmWi7 for ; Thu, 11 Oct 2018 09:51:12 -0700 (PDT) Received: from Heathers-MacBook-Pro.local (unknown [IPv6:2603:3023:30a:e7e0:9ce4:6e22:8985:3b36]) by c8a.amsl.com (Postfix) with ESMTPSA id 0131C1CADD4 for ; Thu, 11 Oct 2018 09:51:11 -0700 (PDT) To: xml2rfc-dev@ietf.org References: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> <065401d45f46$d92c3710$8b84a530$@augustcellars.com> <4308bb9a-14ef-ca1c-03b3-2d1d09bc95a5@levkowetz.com> <4e4af1df-37b8-c180-93d8-14104fe2281c@gmx.de> <075301d46006$e88ef420$b9acdc60$@augustcellars.com> <96e521a6-3534-c986-ac63-e03a12e64c94@levkowetz.com> From: Heather Flanagan Message-ID: <93ab666b-e787-5c83-7992-a048b531b8b0@rfc-editor.org> Date: Thu, 11 Oct 2018 09:51:36 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <96e521a6-3534-c986-ac63-e03a12e64c94@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 16:51:40 -0000 On 10/10/18 4:27 AM, Henrik Levkowetz wrote: > On 2018-10-10 06:44, Julian Reschke wrote: >> On 2018-10-09 21:33, Jim Schaad wrote: >>> >>>> -----Original Message----- >>>> From: xml2rfc-dev On Behalf Of Julian >>>> Reschke >>>> Sent: Tuesday, October 9, 2018 11:12 AM >>>> To: Heather Flanagan ; xml2rfc-dev@ietf.org >>>> Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In >>>> Section 2.40.2, "quoteTitle" >>>> >>>> On 2018-10-09 20:05, Heather Flanagan wrote: >>>>> On 10/8/18 10:20 PM, Henrik Levkowetz wrote: >>>>>> On 2018-10-09 06:51, Julian Reschke wrote: >>>>>>> On 2018-10-08 23:41, Henrik Levkowetz wrote: >>>>>>>> ... >>>>>>>> Currently, reference files are only being created according to the >>>>>>>> v2 schema. If we begin to create them according to v3 (because of >>>>>>>> richer >>>>>>>> semantics) we may have to maintain separate, parallel bibxml >>>>>>>> repositories, yes. >>>>>>>> ... >>>>>>> That wiil lead to friction. >>>>>>> >>>>>>> Maybe we should reconsider any change that makes those incompatible. >>>>>> Ack; looking at those again makes sense, in view of the possibility >>>>>> of having to maintain different reference repositories. >>>>>> >>>>> Hola a todos, >>>>> >>>>> Two questions: first, I'm not sure what this means for when we do >>>>> switch over to v3 - there will be changes to the reference format, so >>>>> does that mean we'll have to be ready with a 100% switchover to an >>>>> alternate repository when we go live? Second, when you say "reconsider >>>>> any change >>>> I guess it would be an additional repository. >>>> >>>>> that makes those incompatible" are you proposing changes to the v3 >>>>> vocabulary to avoid incompatible changes to v2? >>>> Yes. I believe we should undo the change to (moving under >>>> ), and just restore what we have in v2. >>> What about the seriesInfo that is in the front for identifying the document? Are you going to move that to the same level as front, middle, back? >> No, my proposal would be to entirely back out the change, and to restore >> the attributes that we had on instead. > I strongly support this. I mention a number of issues related to the > changes to seriesInfo in draft-levkowetz-xml2rfc-v3-implementation-notes; > in Sections 3.1.10, 3.1.11, 3.1.12, 3.2.1, 4.1.5, 4.4.11, and 4.4.12. > > Before we go down this path, it might be worth reviewing some of the earlier discussions around in Ye Olde Archive. See: https://www.rfc-editor.org/pipermail/rfc-interest/2014-December/008543.html Does this information change your recommendation? Thanks, Heather From nobody Thu Oct 11 09:52:55 2018 Return-Path: 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 C0481130E6B for ; Thu, 11 Oct 2018 09:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 HPiEgWnBEOsb for ; Thu, 11 Oct 2018 09:52:52 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C26C130EBB for ; Thu, 11 Oct 2018 09:52:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 339691D06DE for ; Thu, 11 Oct 2018 09:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8MLLl4PNDYS for ; Thu, 11 Oct 2018 09:52:27 -0700 (PDT) Received: from Heathers-MacBook-Pro.local (unknown [IPv6:2603:3023:30a:e7e0:9ce4:6e22:8985:3b36]) by c8a.amsl.com (Postfix) with ESMTPSA id 058501CAE56 for ; Thu, 11 Oct 2018 09:52:26 -0700 (PDT) To: xml2rfc-dev@ietf.org References: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> <065401d45f46$d92c3710$8b84a530$@augustcellars.com> <4308bb9a-14ef-ca1c-03b3-2d1d09bc95a5@levkowetz.com> <4e4af1df-37b8-c180-93d8-14104fe2281c@gmx.de> <075301d46006$e88ef420$b9acdc60$@augustcellars.com> <96e521a6-3534-c986-ac63-e03a12e64c94@levkowetz.com> <93ab666b-e787-5c83-7992-a048b531b8b0@rfc-editor.org> From: Heather Flanagan Message-ID: <2fe46b59-55bb-09be-533e-22ea7cfdcd76@rfc-editor.org> Date: Thu, 11 Oct 2018 09:52:51 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <93ab666b-e787-5c83-7992-a048b531b8b0@rfc-editor.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 16:52:54 -0000 > Before we go down this path, it might be worth reviewing some of the > earlier discussions around in Ye Olde Archive. See: > > https://www.rfc-editor.org/pipermail/rfc-interest/2014-December/008543.html > (To be clear, I don't expect anyone to have remembered that particular thread - this project has been going on for a very long time, and the original conversations are easily lost.) -hf > > Does this information change your recommendation? > > Thanks, > > Heather > > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc-dev > From nobody Thu Oct 11 10:20:39 2018 Return-Path: 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 303FE130EBD for ; Thu, 11 Oct 2018 10:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 Jvr-pnJY7maV for ; Thu, 11 Oct 2018 10:20:31 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D39D130EB9 for ; Thu, 11 Oct 2018 10:20:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id A317C1D06E6; Thu, 11 Oct 2018 10:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osfwFk9jhGjD; Thu, 11 Oct 2018 10:20:06 -0700 (PDT) Received: from Heathers-MacBook-Pro.local (unknown [IPv6:2603:3023:30a:e7e0:9ce4:6e22:8985:3b36]) by c8a.amsl.com (Postfix) with ESMTPSA id 5C5161D06DE; Thu, 11 Oct 2018 10:20:06 -0700 (PDT) To: Julian Reschke , Jim Schaad , 'Henrik Levkowetz' , xml2rfc-dev@ietf.org References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> <8b71a263-a280-270a-4fb4-7e0a4e2abb0a@gmx.de> <926f11a0-3d4b-ffe0-d7b5-c7ec51f1083b@levkowetz.com> <10b47376-f6a3-0df0-11c4-fe3a2a18f4a4@rfc-editor.org> <075701d46007$5b52d620$11f88260$@augustcellars.com> <369bdaa3-264b-57e0-c7ff-ec7f24f125c5@gmx.de> From: Heather Flanagan Message-ID: <4392e03c-f4a4-a9a0-c53a-a43f9cd0e99f@rfc-editor.org> Date: Thu, 11 Oct 2018 10:20:30 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <369bdaa3-264b-57e0-c7ff-ec7f24f125c5@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 17:20:37 -0000 On 10/9/18 10:01 PM, Julian Reschke wrote: > On 2018-10-09 21:36, Jim Schaad wrote: >> >> >>> -----Original Message----- >>> From: xml2rfc-dev On Behalf Of Henrik >>> Levkowetz >>> Sent: Tuesday, October 9, 2018 11:26 AM >>> To: Heather Flanagan ; xml2rfc-dev@ietf.org >>> Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC >>> 7991, In >>> Section 2.42, >>> >>> Hi Heather, >>> >>> On 2018-10-09 20:14, Heather Flanagan wrote: >>>> Hola a todos, >>>> >>>> On 10/9/18 10:44 AM, Henrik Levkowetz wrote: >>>>> But what is really desired from the archival format? >>>> >>>> Complete content. I tried to capture this in RFC 7990, Section 6.1 >>>> "XML for RFCs" >>>> >>>> Key points regarding the XML format: >>>> >>>>      o  The canonical format for RFCs is XML using the xml2rfc >>>> version 3 >>>>         (xml2rfc v3) vocabulary.  The XML file must contain all >>>>         information necessary to render a variety of formats; any >>>> question >>>>         about what was intended in the publication will be answered >>>> from >>>>         this format. >>>> >>>>      o  Authors may submit documents using the xml2rfc v2 >>>> vocabulary, but >>>>         the final publication will be converted to use the xml2rfc v3 >>>>         vocabulary. >>>> >>>>      o  SVG is supported and will be embedded in the final XML file. >>>> >>>>      o  There will be automatically generated identifiers for >>>> sections, >>>>         paragraphs, figures, and tables in the final XML file. >>>> >>>>      o  The XML file will not contain any xml2rfc v3 vocabulary >>>> elements >>>>         or attributes that have been marked deprecated. >>>> >>>>      o  A DTD will no longer be used.  The grammar will be defined >>>> using >>>>         RELAX NG [RNC]. >>>> >>>>      o  The final XML file will contain, verbatim, the appropriate >>>>         boilerplate as applicable at time of publication specified >>>> by RFC >>>>         7841 [RFC7841] or its successors. >>>> >>>>      o  The final XML will be self-contained with all the information >>>>         known at publication time.  For instance, all features that >>>>         reference externally defined input will be expanded.  This >>>>         includes all uses of xinclude, src attributes (such as in >>>>         or elements), include-like processing >>>>         instructions, and externally defined entities. >>>> >>>>      o  The final XML will not contain comments or processing >>>>         instructions. >>>> >>>>      o  The final XML will not contain src attributes for or >>>>         elements. >>>> >>>> >>>> Does this answer your question? >>> >>> For me, I guess it does; for me it means that ToC, enclosing >>> References section, >>> and Index should all be part of the canonical format.  For me, RFC >>> 7998 Section >>> 1, Introduction, points in the same direction. >> >> I agree w/ the References.  I don't agree w/ the ToC or index as this >> information can be derived from the XML file in a deterministic >> fashion and would not change. > > The same is true for . We have proof of that because we've > been doing it without problems for over 10 years. I am willing to agree re: ToC, but references must be expanded in the document. Anything that requires pulling in external information, e.g., from the bibxml library, must be incorporated in the final XML. -Heather > > Best regards, Julian > From nobody Thu Oct 11 10:33:43 2018 Return-Path: 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 87DC1130EA7 for ; Thu, 11 Oct 2018 10:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 V7q2BONMraYh for ; Thu, 11 Oct 2018 10:33:39 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C6D5130E4D for ; Thu, 11 Oct 2018 10:33:39 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:60749 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1gAeqA-0003X8-Lh; Thu, 11 Oct 2018 10:33:39 -0700 To: Heather Flanagan , xml2rfc-dev@ietf.org References: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> <065401d45f46$d92c3710$8b84a530$@augustcellars.com> <4308bb9a-14ef-ca1c-03b3-2d1d09bc95a5@levkowetz.com> <4e4af1df-37b8-c180-93d8-14104fe2281c@gmx.de> <075301d46006$e88ef420$b9acdc60$@augustcellars.com> <96e521a6-3534-c986-ac63-e03a12e64c94@levkowetz.com> <93ab666b-e787-5c83-7992-a048b531b8b0@rfc-editor.org> From: Henrik Levkowetz Message-ID: Date: Thu, 11 Oct 2018 19:33:31 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <93ab666b-e787-5c83-7992-a048b531b8b0@rfc-editor.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nOc76wpIqxajplG4UuITmoP76JPNdOsDt" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, rse@rfc-editor.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 17:33:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nOc76wpIqxajplG4UuITmoP76JPNdOsDt Content-Type: multipart/mixed; boundary="VepI5c3Tx6HIhHqe0UoxQtOhQNmmlTofi"; protected-headers="v1" From: Henrik Levkowetz To: Heather Flanagan , xml2rfc-dev@ietf.org Message-ID: Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" References: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> <065401d45f46$d92c3710$8b84a530$@augustcellars.com> <4308bb9a-14ef-ca1c-03b3-2d1d09bc95a5@levkowetz.com> <4e4af1df-37b8-c180-93d8-14104fe2281c@gmx.de> <075301d46006$e88ef420$b9acdc60$@augustcellars.com> <96e521a6-3534-c986-ac63-e03a12e64c94@levkowetz.com> <93ab666b-e787-5c83-7992-a048b531b8b0@rfc-editor.org> In-Reply-To: <93ab666b-e787-5c83-7992-a048b531b8b0@rfc-editor.org> --VepI5c3Tx6HIhHqe0UoxQtOhQNmmlTofi Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Heather, On 2018-10-11 18:51, Heather Flanagan wrote: >=20 > On 10/10/18 4:27 AM, Henrik Levkowetz wrote: >> On 2018-10-10 06:44, Julian Reschke wrote: >>> On 2018-10-09 21:33, Jim Schaad wrote: >>>> >>>>> -----Original Message----- >>>>> From: xml2rfc-dev On Behalf Of Julia= n >>>>> Reschke >>>>> Sent: Tuesday, October 9, 2018 11:12 AM >>>>> To: Heather Flanagan ; xml2rfc-dev@ietf.org >>>>> Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 79= 91, In >>>>> Section 2.40.2, "quoteTitle" >>>>> >>>>> On 2018-10-09 20:05, Heather Flanagan wrote: >>>>>> On 10/8/18 10:20 PM, Henrik Levkowetz wrote: >>>>>>> On 2018-10-09 06:51, Julian Reschke wrote: >>>>>>>> On 2018-10-08 23:41, Henrik Levkowetz wrote: >>>>>>>>> ... >>>>>>>>> Currently, reference files are only being created according to = the >>>>>>>>> v2 schema. If we begin to create them according to v3 (because= of >>>>>>>>> richer >>>>>>>>> semantics) we may have to maintain separate, parallel bibxml >>>>>>>>> repositories, yes. >>>>>>>>> ... >>>>>>>> That wiil lead to friction. >>>>>>>> >>>>>>>> Maybe we should reconsider any change that makes those incompati= ble. >>>>>>> Ack; looking at those again makes sense, in view of the possibili= ty >>>>>>> of having to maintain different reference repositories. >>>>>>> >>>>>> Hola a todos, >>>>>> >>>>>> Two questions: first, I'm not sure what this means for when we do >>>>>> switch over to v3 - there will be changes to the reference format,= so >>>>>> does that mean we'll have to be ready with a 100% switchover to an= >>>>>> alternate repository when we go live? Second, when you say "recons= ider >>>>>> any change >>>>> I guess it would be an additional repository. >>>>> >>>>>> that makes those incompatible" are you proposing changes to the v3= >>>>>> vocabulary to avoid incompatible changes to v2? >>>>> Yes. I believe we should undo the change to (moving un= der >>>>> ), and just restore what we have in v2. >>>> What about the seriesInfo that is in the front for identifying >>>> the document? Are you going to move that to the same level as >>>> front, middle, back? >>> No, my proposal would be to entirely back out the change, and to rest= ore >>> the attributes that we had on instead. >> I strongly support this. I mention a number of issues related to the >> changes to seriesInfo in draft-levkowetz-xml2rfc-v3-implementation-not= es; >> in Sections 3.1.10, 3.1.11, 3.1.12, 3.2.1, 4.1.5, 4.4.11, and 4.4.12. >> >> >=20 > Before we go down this path, it might be worth reviewing some of the=20 > earlier discussions around in Ye Olde Archive. See: >=20 > https://www.rfc-editor.org/pipermail/rfc-interest/2014-December/008543.= html >=20 > Does this information change your recommendation? Thank you. Reviewed and understood. Having thought about the points made in the thread, and the issues I've listed in the draft, it turns out that the premise of that thread: "The -14 draft has only one significant change: it makes a child of , and deprecated it as a child of . The purpose of this is to allow the information for RFCs to come from just one source instead of the disparate sources now." while laudable, does not turn out to work very well in practice. My draft gives more details on the individual issues, but the summary is: * This makes v3 reference files incompatible with the v2 processor, which drives us into having to maintain separate parallel reference repositories. (A point not made in the draft, but very relevant). * This makes use of the element to capture data which doesn't really fit into the concept, and makes the rules for the element really complicated. (A number of the issues I ran into during implementation is a consequence of this). * This moves some essential _processing_ information for the document as a whole out of a fairly natural place as xml root element attributes into a much less obvious place. (Also relevant to a number of the issues I ran into during implementation). I think an intermediate solution, where is permitted directly after also under , as within , and there holds only what is actual series information the way it's already used in v2, but not any of the additional attributes like RFC number and docName, would work too. That would make series information for the document itself map directly to series information as used in , without having any of the drawbacks mentioned above. Best regards, Henrik --VepI5c3Tx6HIhHqe0UoxQtOhQNmmlTofi-- --nOc76wpIqxajplG4UuITmoP76JPNdOsDt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu/iWsACgkQTptXS4+7 FxryZA/7BlGwlgmflRKeh8qWF1zjkERrxr4wHkhI3tMghwGbQwbwyQl0twLg5flU m5vlWTEwytG6Fh40KUYCj2+7D2V40BVwG16+c9bt2xBp95rmKwtamASYi5PTAIMj atlp6eaLVrxu5LQa6YmPLf1wdA9thXgCd5UbIrRk/ZfiN64o2N+Ms4oWeE5pcFSn y0U/jsHagFq3smBrb0ANYc6d41NizcWKsALLra7t2hE992HoVnr4LMWWI35X8tNS Z0w+U5y1oBJnXuC8iwS2TV5xEDKgojZN616DuxOzY433bYOFn4+c3vcBM9ZTXWOw MghERjUD27IdiGI5sgJKU/rU8PJhtYJ98PJLKZTY1fTBktyeeSlirO3dfUWrG6TD M1gxxxts9G0nwDMsDa04DaStohNPx4kMBF0REJRHsrurzTVd31MSX0fv9G63axei /ItbHPMrg20uMg4MMhh5byNI3k+J6jfMVRwUtSwqVG8yAZjtQmh7X0qNCvWJFWAc /IkJcF/BMCYlqZOTVK88tWDir3jPJOw/8oV9DSia1DZpP9puY2fWAupSlGdecj9o +qe5x022MD8Rkxevk740DM/YFp7hQAz8fvbmTJIRIBFJbn06EoxixUnDhHWAPdml wsw2nxBZwKnP4wiZFxHVZiaGqw/V3Mj3FcP/NhIQ1rhD6z72OiY= =NnfG -----END PGP SIGNATURE----- --nOc76wpIqxajplG4UuITmoP76JPNdOsDt-- From nobody Thu Oct 11 11:18:24 2018 Return-Path: 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 A175C130ECA for ; Thu, 11 Oct 2018 11:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 PWx3Sg-aRrY2 for ; Thu, 11 Oct 2018 11:18:20 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44A191200D7 for ; Thu, 11 Oct 2018 11:18:20 -0700 (PDT) Received: from Jude (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 11 Oct 2018 11:13:36 -0700 From: Jim Schaad To: 'Henrik Levkowetz' , 'Heather Flanagan' , References: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> <065401d45f46$d92c3710$8b84a530$@augustcellars.com> <4308bb9a-14ef-ca1c-03b3-2d1d09bc95a5@levkowetz.com> <4e4af1df-37b8-c180-93d8-14104fe2281c@gmx.de> <075301d46006$e88ef420$b9acdc60$@augustcellars.com> <96e521a6-3534-c986-ac63-e03a12e64c94@levkowetz.com> <93ab666b-e787-5c83-7992-a048b531b8b0@rfc-editor.org> In-Reply-To: Date: Thu, 11 Oct 2018 11:18:12 -0700 Message-ID: <00b701d4618e$c6a995c0$53fcc140$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLAbTej30L1EUF5/gxtYUDerJ/dBAHYXIfkAiclg5oDoS022gFG0/brAggLbMkA6QYHCgHMCXSOAprEorEBxe0UvgF6NAGlAkouxHQCECp+xAKhGwx4AOXFfUABQkAo7wI2CMRSokt6EoA= Content-Language: en-us X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 18:18:24 -0000 > -----Original Message----- > From: xml2rfc-dev On Behalf Of Henrik > Levkowetz > Sent: Thursday, October 11, 2018 10:34 AM > To: Heather Flanagan ; xml2rfc-dev@ietf.org > Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, = In > Section 2.40.2, "quoteTitle" >=20 > Hi Heather, >=20 > On 2018-10-11 18:51, Heather Flanagan wrote: > > > > On 10/10/18 4:27 AM, Henrik Levkowetz wrote: > >> On 2018-10-10 06:44, Julian Reschke wrote: > >>> On 2018-10-09 21:33, Jim Schaad wrote: > >>>> > >>>>> -----Original Message----- > >>>>> From: xml2rfc-dev On Behalf Of > >>>>> Julian Reschke > >>>>> Sent: Tuesday, October 9, 2018 11:12 AM > >>>>> To: Heather Flanagan ; xml2rfc-dev@ietf.org > >>>>> Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC > >>>>> 7991, In Section 2.40.2, "quoteTitle" > >>>>> > >>>>> On 2018-10-09 20:05, Heather Flanagan wrote: > >>>>>> On 10/8/18 10:20 PM, Henrik Levkowetz wrote: > >>>>>>> On 2018-10-09 06:51, Julian Reschke wrote: > >>>>>>>> On 2018-10-08 23:41, Henrik Levkowetz wrote: > >>>>>>>>> ... > >>>>>>>>> Currently, reference files are only being created according = to > >>>>>>>>> the > >>>>>>>>> v2 schema. If we begin to create them according to v3 > >>>>>>>>> (because of richer > >>>>>>>>> semantics) we may have to maintain separate, parallel bibxml > >>>>>>>>> repositories, yes. > >>>>>>>>> ... > >>>>>>>> That wiil lead to friction. > >>>>>>>> > >>>>>>>> Maybe we should reconsider any change that makes those > incompatible. > >>>>>>> Ack; looking at those again makes sense, in view of the > >>>>>>> possibility of having to maintain different reference = repositories. > >>>>>>> > >>>>>> Hola a todos, > >>>>>> > >>>>>> Two questions: first, I'm not sure what this means for when we = do > >>>>>> switch over to v3 - there will be changes to the reference > >>>>>> format, so does that mean we'll have to be ready with a 100% > >>>>>> switchover to an alternate repository when we go live? Second, > >>>>>> when you say "reconsider any change > >>>>> I guess it would be an additional repository. > >>>>> > >>>>>> that makes those incompatible" are you proposing changes to the > >>>>>> v3 vocabulary to avoid incompatible changes to v2? > >>>>> Yes. I believe we should undo the change to (moving > >>>>> under ), and just restore what we have in v2. > >>>> What about the seriesInfo that is in the front for identifying = the > >>>> document? Are you going to move that to the same level as front, > >>>> middle, back? > >>> No, my proposal would be to entirely back out the change, and to > >>> restore the attributes that we had on instead. > >> I strongly support this. I mention a number of issues related to = the > >> changes to seriesInfo in > >> draft-levkowetz-xml2rfc-v3-implementation-notes; > >> in Sections 3.1.10, 3.1.11, 3.1.12, 3.2.1, 4.1.5, 4.4.11, and = 4.4.12. > >> > >> > > > > Before we go down this path, it might be worth reviewing some of the > > earlier discussions around in Ye Olde Archive. See: > > > > = https://www.rfc-editor.org/pipermail/rfc-interest/2014-December/008543 > > .html > > > > Does this information change your recommendation? >=20 > Thank you. Reviewed and understood. >=20 > Having thought about the points made in the thread, and the issues = I've listed in > the draft, it turns out that the premise of that thread: >=20 > "The -14 draft has only one significant change: it makes = a child of > , and deprecated it as a child of . The purpose of = this is to > allow the information for RFCs to come from just one source instead of = the > disparate sources now." >=20 > while laudable, does not turn out to work very well in practice. My = draft gives > more details on the individual issues, but the summary is: >=20 > * This makes v3 reference files incompatible with the v2 processor, > which drives us into having to maintain separate parallel > reference repositories. (A point not made in the draft, but > very relevant). >=20 > * This makes use of the element to capture data which > doesn't really fit into the concept, and makes the > rules for the element really complicated. (A number > of the issues I ran into during implementation is a consequence > of this). Which ones made for the most problems? Are they things that might want = to be put in a reference anyway? >=20 > * This moves some essential _processing_ information for the document > as a whole out of a fairly natural place as xml root element > attributes into a much less obvious place. (Also relevant to a > number of the issues I ran into during implementation). >=20 > I think an intermediate solution, where is permitted = directly after > also under , as within , and there holds only = what is > actual series information the way it's already used in v2, but not any = of the > additional attributes like RFC number and docName, would work too. = That > would make series information for the document itself map directly to = series > information as used in , without having any of the = drawbacks > mentioned above. It might be more natural to have it between the links and the front = rather than after the front. It seems to be similar info to what is = there. Jiim >=20 >=20 > Best regards, >=20 > Henrik From nobody Thu Oct 11 11:18:31 2018 Return-Path: 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 3F7921200D7 for ; Thu, 11 Oct 2018 11:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ONe7a0nWQemD for ; Thu, 11 Oct 2018 11:18:21 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 250B1130EB9 for ; Thu, 11 Oct 2018 11:18:20 -0700 (PDT) Received: from [192.168.178.20] ([91.61.61.254]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MVN0w-1gBJc62Nwc-00Ygwu; Thu, 11 Oct 2018 20:17:52 +0200 Received: from [192.168.178.20] ([91.61.61.254]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MVN0w-1gBJc62Nwc-00Ygwu; Thu, 11 Oct 2018 20:17:52 +0200 To: Heather Flanagan , Jim Schaad , 'Henrik Levkowetz' , xml2rfc-dev@ietf.org References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> <8b71a263-a280-270a-4fb4-7e0a4e2abb0a@gmx.de> <926f11a0-3d4b-ffe0-d7b5-c7ec51f1083b@levkowetz.com> <10b47376-f6a3-0df0-11c4-fe3a2a18f4a4@rfc-editor.org> <075701d46007$5b52d620$11f88260$@augustcellars.com> <369bdaa3-264b-57e0-c7ff-ec7f24f125c5@gmx.de> <4392e03c-f4a4-a9a0-c53a-a43f9cd0e99f@rfc-editor.org> From: Julian Reschke Message-ID: Date: Thu, 11 Oct 2018 20:17:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <4392e03c-f4a4-a9a0-c53a-a43f9cd0e99f@rfc-editor.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:XiDRBisw5JY5Sj0tHy5skU5gNdSpclCKAlGZyHkOhDkeJ6iy8EA MHqFxtCLqdNibCOGt9AsvRqACNIrqIQ8O+YbGE1+D5yjILywzCQye9Dc/fXQ3sh4eDqowfv xtIHgXnrrGUxDttS2GUTJz2ZKm49/Sw5nGiC5om+uTnbcf4TnrHa3/vofV1PrNrjWqyuX4r qHtxSe9y+GNWuc+MordUw== X-UI-Out-Filterresults: notjunk:1;V01:K0:M8yTCGrU6fw=:qgaWMxTMGdvLbpBqH9+1Ew MEdUm3rZ/xQXl1r8rs/uu+wsPAwjDcuYotgUz2LJkRf/ms7RheOE/w0djXwa1oUc8kHQHC5Pd AcCdNPj6pZT5l0ZtnKfkC+01O6FricpgjKx+bvVhQ3/UBQLM/EJ7Fyg3J0lXRQ2QEYwRAthZ7 2UIKNzYew//zdFkAUhrgBXea8k0B9clkDaOk366VCzDSLaBVRt09KmCGHSI0Gc4MU/gEzkYUV S65ast8zlscUy9kVJEYZe5lpyDc0HbdJF1WmeEpmayglJa5kpJV8J9nCeGduo7OAUtFD8uSgV 6VSBwO6sqJ0TINv/mZxgRts2TZa/JuPmV30SJZlgUZ2Vp0LxXSIAGax8IcSYHRLJW7Ua7AiWs 2mGRflRVQSR2h21nLG0bgNuSscU2yB5aCYZBOpJQcRG1gcZgbtySDhpqAVbze9ei4fMLPUh6T WuJfYX5tlTjBwfK41YEDWy2cZ05df3NEeVi63bvzbpQHOiMPUkT5hnrR7rDFKcf8dSwGGVa9A saKE8eEu46ruiuaFpBwQJOYRexqb60yy0EqM8iIJkEirj4036/r8SQVxDnbjAy9b19E1GEdQ7 g1ZEVRt1egivOG6OiqVCx3AFBjRSzMqjnMeLb2uJeK4MKQHphseUjmYCKNJtI2kUy1iHBsFwV 4iWKCapfr49ZiRxrq7op9tIbKVtbtgFLqyloJhLakP1NBZyBPs0eTzyerV5LpINt7vgF+8Mb/ +iNageMBvzCadmF0CYzMI03px8Mw4OKId8Tsag3omrIj017Hfc8KNB5gGZqVVExZwfiXqlSY5 +ocD/d5bzggfGiXyNufCWCe7wFmf8iTvHeBGlUplx/GHS/YHGU= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 18:18:24 -0000 On 2018-10-11 19:20, Heather Flanagan wrote: > ... > I am willing to agree re: ToC, but references must be expanded in the > document. Anything that requires pulling in external information, e.g., > from the bibxml library, must be incorporated in the final XML. > > -Heather Yes, nobody argues with that. Henrik's issue is only about inserting a container when there is more than one references section. Best regards, Julian From nobody Thu Oct 11 12:15:53 2018 Return-Path: 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 A4DA4126DBF for ; Thu, 11 Oct 2018 12:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 rg9Z3M5btu2f for ; Thu, 11 Oct 2018 12:15:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC686130EDA for ; Thu, 11 Oct 2018 12:15:46 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:61097 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1gAgQz-0005Nl-VK; Thu, 11 Oct 2018 12:15:46 -0700 To: Jim Schaad , 'Heather Flanagan' , xml2rfc-dev@ietf.org References: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> <065401d45f46$d92c3710$8b84a530$@augustcellars.com> <4308bb9a-14ef-ca1c-03b3-2d1d09bc95a5@levkowetz.com> <4e4af1df-37b8-c180-93d8-14104fe2281c@gmx.de> <075301d46006$e88ef420$b9acdc60$@augustcellars.com> <96e521a6-3534-c986-ac63-e03a12e64c94@levkowetz.com> <93ab666b-e787-5c83-7992-a048b531b8b0@rfc-editor.org> <00b701d4618e$c6a995c0$53fcc140$@augustcellars.com> From: Henrik Levkowetz Message-ID: Date: Thu, 11 Oct 2018 21:15:38 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <00b701d4618e$c6a995c0$53fcc140$@augustcellars.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="S5edwieKGp2K5BdkIJN75VaFnM8KVXlvC" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, rse@rfc-editor.org, ietf@augustcellars.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 19:15:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --S5edwieKGp2K5BdkIJN75VaFnM8KVXlvC Content-Type: multipart/mixed; boundary="TLITTQcq7blX4GaG55jLkcHiNSDx8fTuw"; protected-headers="v1" From: Henrik Levkowetz To: Jim Schaad , 'Heather Flanagan' , xml2rfc-dev@ietf.org Message-ID: Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" References: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> <065401d45f46$d92c3710$8b84a530$@augustcellars.com> <4308bb9a-14ef-ca1c-03b3-2d1d09bc95a5@levkowetz.com> <4e4af1df-37b8-c180-93d8-14104fe2281c@gmx.de> <075301d46006$e88ef420$b9acdc60$@augustcellars.com> <96e521a6-3534-c986-ac63-e03a12e64c94@levkowetz.com> <93ab666b-e787-5c83-7992-a048b531b8b0@rfc-editor.org> <00b701d4618e$c6a995c0$53fcc140$@augustcellars.com> In-Reply-To: <00b701d4618e$c6a995c0$53fcc140$@augustcellars.com> --TLITTQcq7blX4GaG55jLkcHiNSDx8fTuw Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jim, On 2018-10-11 20:18, Jim Schaad wrote: >=20 >=20 >> -----Original Message----- >> From: xml2rfc-dev On Behalf Of Henrik >> Levkowetz >> Sent: Thursday, October 11, 2018 10:34 AM >> To: Heather Flanagan ; xml2rfc-dev@ietf.org >> Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991,= In >> Section 2.40.2, "quoteTitle" >>=20 >> Hi Heather, >>=20 >> On 2018-10-11 18:51, Heather Flanagan wrote: >> > >> > On 10/10/18 4:27 AM, Henrik Levkowetz wrote: >> >> On 2018-10-10 06:44, Julian Reschke wrote: >> >>> On 2018-10-09 21:33, Jim Schaad wrote: >> >>>> >> >>>>> -----Original Message----- >> >>>>> From: xml2rfc-dev On Behalf Of >> >>>>> Julian Reschke >> >>>>> Sent: Tuesday, October 9, 2018 11:12 AM >> >>>>> To: Heather Flanagan ; xml2rfc-dev@ietf.org >> >>>>> Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC= >> >>>>> 7991, In Section 2.40.2, "quoteTitle" >> >>>>> >> >>>>> On 2018-10-09 20:05, Heather Flanagan wrote: >> >>>>>> On 10/8/18 10:20 PM, Henrik Levkowetz wrote: >> >>>>>>> On 2018-10-09 06:51, Julian Reschke wrote: >> >>>>>>>> On 2018-10-08 23:41, Henrik Levkowetz wrote: >> >>>>>>>>> ... >> >>>>>>>>> Currently, reference files are only being created according = to >> >>>>>>>>> the >> >>>>>>>>> v2 schema. If we begin to create them according to v3 >> >>>>>>>>> (because of richer >> >>>>>>>>> semantics) we may have to maintain separate, parallel bibxml= >> >>>>>>>>> repositories, yes. >> >>>>>>>>> ... >> >>>>>>>> That wiil lead to friction. >> >>>>>>>> >> >>>>>>>> Maybe we should reconsider any change that makes those >> incompatible. >> >>>>>>> Ack; looking at those again makes sense, in view of the >> >>>>>>> possibility of having to maintain different reference reposito= ries. >> >>>>>>> >> >>>>>> Hola a todos, >> >>>>>> >> >>>>>> Two questions: first, I'm not sure what this means for when we = do >> >>>>>> switch over to v3 - there will be changes to the reference >> >>>>>> format, so does that mean we'll have to be ready with a 100% >> >>>>>> switchover to an alternate repository when we go live? Second, >> >>>>>> when you say "reconsider any change >> >>>>> I guess it would be an additional repository. >> >>>>> >> >>>>>> that makes those incompatible" are you proposing changes to the= >> >>>>>> v3 vocabulary to avoid incompatible changes to v2? >> >>>>> Yes. I believe we should undo the change to (moving= >> >>>>> under ), and just restore what we have in v2. >> >>>> What about the seriesInfo that is in the front for identifying th= e >> >>>> document? Are you going to move that to the same level as front, >> >>>> middle, back? >> >>> No, my proposal would be to entirely back out the change, and to >> >>> restore the attributes that we had on instead. >> >> I strongly support this. I mention a number of issues related to t= he >> >> changes to seriesInfo in >> >> draft-levkowetz-xml2rfc-v3-implementation-notes; >> >> in Sections 3.1.10, 3.1.11, 3.1.12, 3.2.1, 4.1.5, 4.4.11, and 4.4.1= 2. >> >> >> >> >> > >> > Before we go down this path, it might be worth reviewing some of the= >> > earlier discussions around in Ye Olde Archive. See: >> > >> > https://www.rfc-editor.org/pipermail/rfc-interest/2014-December/0085= 43 >> > .html >> > >> > Does this information change your recommendation? >>=20 >> Thank you. Reviewed and understood. >>=20 >> Having thought about the points made in the thread, and the issues I'v= e listed in >> the draft, it turns out that the premise of that thread: >>=20 >> "The -14 draft has only one significant change: it makes = a child of >> , and deprecated it as a child of . The purpose of t= his is to >> allow the information for RFCs to come from just one source instead of= the >> disparate sources now." >>=20 >> while laudable, does not turn out to work very well in practice. My d= raft gives >> more details on the individual issues, but the summary is: >>=20 >> * This makes v3 reference files incompatible with the v2 processor, >> which drives us into having to maintain separate parallel >> reference repositories. (A point not made in the draft, but >> very relevant). >>=20 >> * This makes use of the element to capture data which >> doesn't really fit into the concept, and makes the >> rules for the element really complicated. (A number >> of the issues I ran into during implementation is a consequence >> of this). >=20 > Which ones made for the most problems? Are they things that might > want to be put in a reference anyway? Of this kind, the attributes category, number, and docName, and I don't think they would be of interest in . >>=20 >> * This moves some essential _processing_ information for the document= >> as a whole out of a fairly natural place as xml root element >> attributes into a much less obvious place. (Also relevant to a >> number of the issues I ran into during implementation). >>=20 >> I think an intermediate solution, where is permitted dire= ctly after >> also under , as within , and there holds only = what is >> actual series information the way it's already used in v2, but not any= of the >> additional attributes like RFC number and docName, would work too. Th= at >> would make series information for the document itself map directly to = series >> information as used in , without having any of the drawback= s >> mentioned above. >=20 > It might be more natural to have it between the links and the front > rather than after the front. It seems to be similar info to what is > there. I have no strong opinion on this, except I'd note that has it after , and that's the reason I suggested the same location under . Makes things more regular, which might help generation of xml from markdown, for instance. Best regards, Henrik --TLITTQcq7blX4GaG55jLkcHiNSDx8fTuw-- --S5edwieKGp2K5BdkIJN75VaFnM8KVXlvC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlu/oVoACgkQTptXS4+7 Fxpl8w//Rw7U9YFQDrzqdkMjZvJ8RQV5XQQd6BXKEVRnuQOeSA13wi6Y1nmF76V5 uJdoPcn0oyNxVqiu1MUm8tinW35cpqnvtUGAO+tVI5PLDgWjSiviVuhSZPg6yO+H 97uJ/J9y0NTPtgvK8orJg19yJQHMbzQEKZcy5H4ctufJ0AI1eGgduF9xwVhVlkSx jIZZXiVLknXWaLyhTbbQihBAiVjRcO9hyCxqXCEly5m7ChPPa/Gd4FSMEE7zg5zE S96gfOREdR645lFT7K+CUM6lr02TJ8n7moG4vOgUU8tONRN4P93wozt4rObd7FIr W5WcJNmk2H3xnwCw8UjqPVXTt0cf/bzvuGOWfYPgLOXz8jfOsgEKYCp81e+KBws8 QEJ86bsyhcgPNy2IiFBXSkytrf7U0V2pi4djuKm2GP77ZE+xE0AIPXbd+yt532VU bWFQ0aQztgXvusmrJuRK831VLdjwr0zi+m6516sgJOOWr6PCwuJVDLcYXtjPX0pB /1kTtuB4/AIyuUZZRtx175VozXemMRGIs6s5WkU7v7vYnMMdj6sx11MEImKxd3Rj piL8tTmenubPZThB0rZFKOLEGtoqucVBv4jbcMNiaaXEJSVAP5VDiEeq8/7UY8YN GlxPvm5UPxFWj6Ga80NMzfy77qeOYKrJP7/Ocoq9C3rJH5l3ed4= =jStu -----END PGP SIGNATURE----- --S5edwieKGp2K5BdkIJN75VaFnM8KVXlvC-- From nobody Thu Oct 11 14:52:58 2018 Return-Path: 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 B64EE12785F for ; Thu, 11 Oct 2018 14:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 W99EOJ8X9Yvy for ; Thu, 11 Oct 2018 14:52:56 -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 4F0D71277BB for ; Thu, 11 Oct 2018 14:52:56 -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, 11 Oct 2018 14:52:54 -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, 11 Oct 2018 14:52:53 -0700 From: Paul Hoffman To: XML Developer List Thread-Topic: [Ext] [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, Thread-Index: AQHUYazCgrrHC4Yr2U2RjizTHqtCKg== Date: Thu, 11 Oct 2018 21:52:53 +0000 Message-ID: <901923CE-60C7-40AF-89A7-B904E64A59B3@icann.org> References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> <8b71a263-a280-270a-4fb4-7e0a4e2abb0a@gmx.de> <926f11a0-3d4b-ffe0-d7b5-c7ec51f1083b@levkowetz.com> <10b47376-f6a3-0df0-11c4-fe3a2a18f4a4@rfc-editor.org> <075701d46007$5b52d620$11f88260$@augustcellars.com> In-Reply-To: <075701d46007$5b52d620$11f88260$@augustcellars.com> 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.236] Content-Type: multipart/signed; boundary="Apple-Mail=_7F6E2DB3-DFD0-46C4-AB55-436FD4CD7F96"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 21:52:58 -0000 --Apple-Mail=_7F6E2DB3-DFD0-46C4-AB55-436FD4CD7F96 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 9, 2018, at 12:36 PM, Jim Schaad wrote: >>=20 >> For me, I guess it does; for me it means that ToC, enclosing = References section, >> and Index should all be part of the canonical format. For me, RFC = 7998 Section >> 1, Introduction, points in the same direction. >=20 > I agree w/ the References. I don't agree w/ the ToC or index as this = information can be derived from the XML file in a deterministic fashion = and would not change. +1 to Jim's formulation. --Paul Hoffman= --Apple-Mail=_7F6E2DB3-DFD0-46C4-AB55-436FD4CD7F96 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAxMTIxNTI1M1owIwYJKoZIhvcNAQkEMRYEFPIotbSfeCFrGoGkas+lZ1/BC+oeMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQCL9jycBwkX04OD8vaw1/eFqL+zgBeuLhJDGf/KVSIccnLUwDLgg6o6l4wKZ0EJ4ZRfp0Pe NdhYhT+Ptw0q3VdpdgWerqWPzLscopQbIX2Q1eXdPOxf7evnYJy+zYv36FEQvWF0hWLKC77IUVF3 DD0qrvEZtJok93GXEBHT6mSlBZn/AWCcET8Z4ZbZlKI/Cfi21p5Wlbc5nPT1uKAVpASntT0PUXup zhNpMjg8X3CXylWS67tz1tW5hSaZreLKd3I2khfyehrDt8kSOv8H98KkiMYT/sZF2CURC1dlJuaz /yf9K+UTz+vMEOIJUHVCGWgDwWtJ3zRbjIprCu7i3ivoAAAAAAAA --Apple-Mail=_7F6E2DB3-DFD0-46C4-AB55-436FD4CD7F96-- From nobody Thu Oct 11 21:00:14 2018 Return-Path: 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 DB6E3130DDD for ; Thu, 11 Oct 2018 21:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 MLMbTpgXa5FZ for ; Thu, 11 Oct 2018 21:00:10 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C808512F295 for ; Thu, 11 Oct 2018 21:00:09 -0700 (PDT) Received: from [192.168.178.20] ([91.61.63.77]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MYwyp-1g7KVw0M0R-00Vf71; Fri, 12 Oct 2018 05:59:35 +0200 Received: from [192.168.178.20] ([91.61.63.77]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MYwyp-1g7KVw0M0R-00Vf71; Fri, 12 Oct 2018 05:59:35 +0200 To: Paul Hoffman , XML Developer List References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> <8b71a263-a280-270a-4fb4-7e0a4e2abb0a@gmx.de> <926f11a0-3d4b-ffe0-d7b5-c7ec51f1083b@levkowetz.com> <10b47376-f6a3-0df0-11c4-fe3a2a18f4a4@rfc-editor.org> <075701d46007$5b52d620$11f88260$@augustcellars.com> <901923CE-60C7-40AF-89A7-B904E64A59B3@icann.org> From: Julian Reschke Message-ID: <1282e3d5-cf6b-3705-dcfb-a8c01d493f67@gmx.de> Date: Fri, 12 Oct 2018 05:59:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <901923CE-60C7-40AF-89A7-B904E64A59B3@icann.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:pNitHzuvEkMjAao4wM4VXaXQvidocOaUKY3SVWbEqJXwMnZsBNU kYlkzTwv1k6jyWd116EkvfgaAr+QUZE5D4bP2DzG0KExdpWxcGwRQ4Tk5KGJv1Y6CkYzUiT 4J8A+kKJk1G12q4w0jZfRu3yxDrjyA7rX13UVIeQGI6HiRt5Og54C/IM887cPWIb+4Ttfxr EbDZuotsCfEqbDHQq0AOw== X-UI-Out-Filterresults: notjunk:1;V01:K0:PBQDdV23gL4=:qO4nG6AXdr7UE1F6lLmAOz Prfa2pEGYNRUHqenUDWkBdqKcUZt5kjDVE+uK+ucznlHCDMHfOk2/7yDqlVAnUn6l80JdkgKB Z9Z38Gto9R6GLkxzNchExgwGHf/RZTZbVPOsnkfDonB4WMwkBbDO3kKem85QteGDpe5Vu6cad /8jUHSieE94oXiMWOr4qYs0wM65j3QUcOLjKrPqyq27YwPZvcn8rercWDdDDPQAF4klgq/Rng i+Sktz/ZZTN5IyHyWo2X3n18EkT7dyaRc7FcvVV6KX0c4m6R2XygXa2wKoIgh0n4S6XNSne9Y hsA6UUHc6CS7nXE9BHCa+ZrStsOhFInh4+HOiveadBOLiAY6kVUTSnrE/FNckagaxyy9h40Of MYDJk9ZltqZsprJN2S7DOKRnVvoB9cPYymv3DfEjXpmAD6UZkQdATm/xJYNAkJ/uJKC0yvUZH CfKBoB04MasiKzsnghBtomu3Yhh753YEQv1ersTuCdZrMqgPtHxV2Pvzs82BbHuBPdHaVV5rT 2+KInSYZ9fXTW9DByJW4yiWlTg/8A5rhTGbRQIwpFH1vxqhKUYBnUc11t/hYfIjju3AXhVi3+ eASdWL8/YGg6lTA1anpicVkQadcwGx3nGGuAwWcDG8LT44nXNGXs2rulQj9K1vhUCzXAMhSkM UTS264o8zni9YPrKwGL1VkEr7xU6D9bY9ATCydzxaLMlUvTWUY4jcRr844WA8c2nqsgPQpBbG AO5fC4lEYoruSktgeKNPaD4JIKIaR7d0ooTNhuoV8zQjv+EC71yyCNjbd7DFrIWCDoq0P05C6 eXb030WP7wi+tF+1r7MWf2sxIcJYvLNxcAPltvxawGzflhZDSI= Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 04:00:12 -0000 On 2018-10-11 23:52, Paul Hoffman wrote: > On Oct 9, 2018, at 12:36 PM, Jim Schaad wrote: >>> >>> For me, I guess it does; for me it means that ToC, enclosing References section, >>> and Index should all be part of the canonical format. For me, RFC 7998 Section >>> 1, Introduction, points in the same direction. >> >> I agree w/ the References. I don't agree w/ the ToC or index as this information can be derived from the XML file in a deterministic fashion and would not change. > > +1 to Jim's formulation. I keep disagreeing, because what Jim says for Toc and Index is trivially true for References as well. If you disagree, please explain why. Best regards, Julian From nobody Thu Oct 11 21:06:52 2018 Return-Path: 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 A32D8130DDD for ; Thu, 11 Oct 2018 21:06:50 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 dY4BjQoprksS for ; Thu, 11 Oct 2018 21:06:48 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D484130DE0 for ; Thu, 11 Oct 2018 21:06:48 -0700 (PDT) Received: from Jude (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 11 Oct 2018 21:02:03 -0700 From: Jim Schaad To: 'Julian Reschke' , 'Paul Hoffman' , 'XML Developer List' References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> <8b71a263-a280-270a-4fb4-7e0a4e2abb0a@gmx.de> <926f11a0-3d4b-ffe0-d7b5-c7ec51f1083b@levkowetz.com> <10b47376-f6a3-0df0-11c4-fe3a2a18f4a4@rfc-editor.org> <075701d46007$5b52d620$11f88260$@augustcellars.com> <901923CE-60C7-40AF-89A7-B904E64A59B3@icann.org> <1282e3d5-cf6b-3705-dcfb-a8c01d493f67@gmx.de> In-Reply-To: <1282e3d5-cf6b-3705-dcfb-a8c01d493f67@gmx.de> Date: Thu, 11 Oct 2018 21:06:38 -0700 Message-ID: <012c01d461e0$fb3bb5f0$f1b321d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKMgMAK0VYejNR5SBI3Ju6yzqYpwAJgfmWrAYJ4yUYC/7eaQwLlkh8fAyVeB0sB5WiLFwJwh7rqAZk1LJUBuyD16wKBMloQAiJI5eYBqirtXgIiJYCEosKCOLA= Content-Language: en-us X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 04:06:50 -0000 > -----Original Message----- > From: xml2rfc-dev On Behalf Of Julian > Reschke > Sent: Thursday, October 11, 2018 8:59 PM > To: Paul Hoffman ; XML Developer List dev@ietf.org> > Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #49: Schema Issue, RFC 7991, In > Section 2.42, > > On 2018-10-11 23:52, Paul Hoffman wrote: > > On Oct 9, 2018, at 12:36 PM, Jim Schaad wrote: > >>> > >>> For me, I guess it does; for me it means that ToC, enclosing > >>> References section, and Index should all be part of the canonical > >>> format. For me, RFC 7998 Section 1, Introduction, points in the same > direction. > >> > >> I agree w/ the References. I don't agree w/ the ToC or index as this > information can be derived from the XML file in a deterministic fashion and > would not change. > > > > +1 to Jim's formulation. > > I keep disagreeing, because what Jim says for Toc and Index is trivially true for > References as well. If you disagree, please explain why. If I build a third party tool that does things like extract the TOC from the section/reference markers, if the extra references is there then I don't need to special case anything. If it is not there then I need to special case things. This is one case where adding the extra reference element makes things easier for external tool writers. These people are not going to be doing the same thing for indexes because that would require doing a full rendering. Jim > > Best regards, Julian > > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc-dev From nobody Thu Oct 11 21:26:32 2018 Return-Path: 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 39C2D12F295 for ; Thu, 11 Oct 2018 21:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 50dn2nvvaWEn for ; Thu, 11 Oct 2018 21:26:28 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AB97129385 for ; Thu, 11 Oct 2018 21:26:28 -0700 (PDT) Received: from [192.168.178.20] ([91.61.63.77]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Ma1tv-1fxQdB17gF-00LqLV; Fri, 12 Oct 2018 06:25:24 +0200 Received: from [192.168.178.20] ([91.61.63.77]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Ma1tv-1fxQdB17gF-00LqLV; Fri, 12 Oct 2018 06:25:24 +0200 To: Jim Schaad , 'Paul Hoffman' , 'XML Developer List' References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> <8b71a263-a280-270a-4fb4-7e0a4e2abb0a@gmx.de> <926f11a0-3d4b-ffe0-d7b5-c7ec51f1083b@levkowetz.com> <10b47376-f6a3-0df0-11c4-fe3a2a18f4a4@rfc-editor.org> <075701d46007$5b52d620$11f88260$@augustcellars.com> <901923CE-60C7-40AF-89A7-B904E64A59B3@icann.org> <1282e3d5-cf6b-3705-dcfb-a8c01d493f67@gmx.de> <012c01d461e0$fb3bb5f0$f1b321d0$@augustcellars.com> From: Julian Reschke Message-ID: Date: Fri, 12 Oct 2018 06:25:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <012c01d461e0$fb3bb5f0$f1b321d0$@augustcellars.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:aeTwljgep1YBrdlYadx8up0sCORTluKRNroAfDbXvlUSEI8JvwC UUm0i87VypgsMBAbfUlNfe9zt6yvFommYSeEPVXcnTwr5Qz5GYszfMRWUJVfqVUmY5lwHyW A4eiQQ8vUedwbXZotILw3+CBA9NKRJDT+w5WqX/wo/njT7zDbFvIpFu0pmrLNRNHPYws2wT josu6r5Ri0tcxJEIwmCSA== X-UI-Out-Filterresults: notjunk:1;V01:K0:4UD8UWCNtZQ=:Sl4CuesEW6zRt+Evouv089 1nMtgGxEQSWG3cbez0Jmvmzx90aswIRJO5tPo8JDsVQesrGe2nc+/uxTQMawaxgPE6LdcB5Zu JmeJ++ZB8LCbvF3WWm53dyjAON7oHvMaMm9wVjHUWicgYYFwoc4wICYDWWSBbrzQUET3NPSnO rsxjzmEEXwukx25jrzJxwJiAOVQ3IcdK3TN0AAVSnT0oQOW08ceCOd6VUMT0FgsjQtEO+forS bFpnaYy+IFAMPHQGI0vm52uaOsqG0AKse72gY4Z2ueqvxhTwHKaoOOF88DsaxEZspPgpLsXB7 a/Bz4Whljj2hGWy0gntTHhwFXgsn+/s8e7arZpB1cjRlDxgsbkpAXBFHB5ildHClBpts4IvQi RzomkAb6RRqsFIoAP0KNZaMmM5Bba49XFVHk0G04ilehF5PkBUAIoiW0P95xBRmJNC+3b4Frp e674NrztI11l9pgiyRZVB6ODe8yqe41hLkMNqSENSzO6G7QVN9bIghgL8OHfTnTVDwEs+Qh1r BSjVuF8DQPA846R6LxM/jwIDswlbL4qDOthoCuE/nqXpLtYofcpRsFlMYWexwJdo3OXEztlz+ fFt0Cnd8qgVgqtq6mf2/A4h0zzEsbBLqiMzltMH3wZRkDaS0t04W5kodlmXoPP4MJ4k5G4LdH lPC68SMZpBe/okQCOySX3ww3SUqtE8dYxD37w19dexOlZEUigMlGLVDnT/wpA2GlduRClrLoJ fCp23/kLBS5Caomt+tX2YgLSvrKgWWTo0TcF47FYQgP23+IAW3LVGIeYXVMIR/ExdMHpxgABG dFo+G3BM7bx7z61gZzoMckcctwCVvqPGDia4tZrn/Axme9iX4w= Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 04:26:30 -0000 On 2018-10-12 06:06, Jim Schaad wrote: > > >> -----Original Message----- >> From: xml2rfc-dev On Behalf Of Julian >> Reschke >> Sent: Thursday, October 11, 2018 8:59 PM >> To: Paul Hoffman ; XML Developer List > dev@ietf.org> >> Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #49: Schema Issue, RFC > 7991, In >> Section 2.42, >> >> On 2018-10-11 23:52, Paul Hoffman wrote: >>> On Oct 9, 2018, at 12:36 PM, Jim Schaad wrote: >>>>> >>>>> For me, I guess it does; for me it means that ToC, enclosing >>>>> References section, and Index should all be part of the canonical >>>>> format. For me, RFC 7998 Section 1, Introduction, points in the same >> direction. >>>> >>>> I agree w/ the References. I don't agree w/ the ToC or index as this >> information can be derived from the XML file in a deterministic fashion > and >> would not change. >>> >>> +1 to Jim's formulation. >> >> I keep disagreeing, because what Jim says for Toc and Index is trivially > true for >> References as well. If you disagree, please explain why. > > If I build a third party tool that does things like extract the TOC from the > section/reference markers, if the extra references is there then I don't > need to special case anything. If it is not there then I need to special Yes. About two lines. > case things. This is one case where adding the extra reference element > makes things easier for external tool writers. These people are not going > to be doing the same thing for indexes because that would require doing a > full rendering. The question is whether better support for these tools justifies a change to the grammar which I believe is unnecessary and might cause more confusion (for instance, with respect to what can nested where). Best regards, Julian From nobody Thu Oct 11 23:49:30 2018 Return-Path: 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 D062A130DFD for ; Thu, 11 Oct 2018 23:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 bPX2tswM4wvN for ; Thu, 11 Oct 2018 23:49:26 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A702C130DE2 for ; Thu, 11 Oct 2018 23:49:25 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:64162 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1gArGG-0004gT-RZ; Thu, 11 Oct 2018 23:49:25 -0700 To: Heather Flanagan , xml2rfc-dev@ietf.org References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> <8b71a263-a280-270a-4fb4-7e0a4e2abb0a@gmx.de> <926f11a0-3d4b-ffe0-d7b5-c7ec51f1083b@levkowetz.com> <10b47376-f6a3-0df0-11c4-fe3a2a18f4a4@rfc-editor.org> <075701d46007$5b52d620$11f88260$@augustcellars.com> <369bdaa3-264b-57e0-c7ff-ec7f24f125c5@gmx.de> <4392e03c-f4a4-a9a0-c53a-a43f9cd0e99f@rfc-editor.org> From: Henrik Levkowetz Message-ID: <406808a6-a6b5-43f5-1a01-ce0c1c7c7371@levkowetz.com> Date: Fri, 12 Oct 2018 08:49:17 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bX4XSlNKk3IeESqm497TXvHlM3NaSdeMJ" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, rse@rfc-editor.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 06:49:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bX4XSlNKk3IeESqm497TXvHlM3NaSdeMJ Content-Type: multipart/mixed; boundary="Hs3wx8agwDt5t0LtnpML9j7j5c0OTjXxN"; protected-headers="v1" From: Henrik Levkowetz To: Heather Flanagan , xml2rfc-dev@ietf.org Message-ID: <406808a6-a6b5-43f5-1a01-ce0c1c7c7371@levkowetz.com> Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> <8b71a263-a280-270a-4fb4-7e0a4e2abb0a@gmx.de> <926f11a0-3d4b-ffe0-d7b5-c7ec51f1083b@levkowetz.com> <10b47376-f6a3-0df0-11c4-fe3a2a18f4a4@rfc-editor.org> <075701d46007$5b52d620$11f88260$@augustcellars.com> <369bdaa3-264b-57e0-c7ff-ec7f24f125c5@gmx.de> <4392e03c-f4a4-a9a0-c53a-a43f9cd0e99f@rfc-editor.org> In-Reply-To: --Hs3wx8agwDt5t0LtnpML9j7j5c0OTjXxN Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Heather, A bit more of an explanation and background information, below: On 2018-10-11 20:17, Julian Reschke wrote: > On 2018-10-11 19:20, Heather Flanagan wrote: >> ... >> I am willing to agree re: ToC, but references must be expanded in the = >> document. Anything that requires pulling in external information, e.g.= ,=20 >> from the bibxml library, must be incorporated in the final XML. >>=20 >> -Heather >=20 > Yes, nobody argues with that. >=20 > Henrik's issue is only about inserting a container when there is more=20 > than one references section. Yes. Up until ca. RFC 3500, references weren't split up into separate normative and informative references. Then some people starting to do so, and xml2rfc rendered those as 2 top-level numbered sections. Some people felt that there should just be one top level 'References' section, with the Normative and Informative parts as sub-sections. This was not implemented by updating the schema, but by doing 'magic' inside xml2rfc: If there was one element, it was rendered as a top-level section; if there were multiple , they were rendered as sub-sections inside a top-level section. I feel that it's time to update the schema so that the published XML reflects this, instead of having rendering tools continue to add magic. Instead of this: Normative References Informative References being rendered with a magically appearing top-level "References" section, we should have this in the prepped output and published XML: References Normative References Informative References I believe this conforms to this point from 7990, in that a renderer must otherwise know that it needs to do 'magic' to produce the top-level "References" section: o The canonical format for RFCs is XML using the xml2rfc version 3 (xml2rfc v3) vocabulary. The XML file must contain all information necessary to render a variety of formats; any question= about what was intended in the publication will be answered from this format. Best regards, Henrik --Hs3wx8agwDt5t0LtnpML9j7j5c0OTjXxN-- --bX4XSlNKk3IeESqm497TXvHlM3NaSdeMJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlvAQ+0ACgkQTptXS4+7 Fxr8ZhAAvTQiMfyIMRteKXztiZX4735olxiSSS6Z1EnNljVolbybHozV/vhRwm0e QAD17oUL9STozxxNfQs8Ys7hGZLUAu3p74bFC9XzZ8chULEGuV69akOGJgQNo2ZU ibRpr5lXRBlOiSpjA/Yzmd4OHpOamLp1JOAzUxK3oEDz2sO6SyfhhpQobYEK+Xv4 sF5Zcl/DM2X0NEUYyi+7xnDKWvoFEaWhQkJMJXV26Hozgzesv8dKRFEqQ56fs+pR WmYXBtKSZdZe1STL/9sbO1RYnA4iEj8W9CsBIBoRMRRrS7zC+uVB9/nkYPpgosPt znSIE4kLgGkMenb2b5qBKDZJwXDsi2HWZR95TrhFUACh0rmlIjhgi2IBcnqrbzjj 5s9ZcxMEoEJlARGHZ8CSqHMUxhs3QOOwBdsc0lIgODPKrGOM92OqEJadOBpZJycU MPpAEZEgdKYgl9mU+GSYRBjxG7110v1x1tLdXlSO5p5BC6qACFYxNkORlkldkXBq dkapqz2ru3JW5ttAGs1RzmeiO9aNCMXhfIjBlXnBfIY9yQBeE1GiU+OIIxjkGorz w2hI/0f2yFMzgMeykx2VKnaANQ1iXlrBNZ8NTIfE4/uqqQRqcz97ANh55DraJ2ho tmfXJyRYpSq53UMRQd4kOMQlsm4iDIomvyi8vcPkBqBSUmxjPK8= =pGIf -----END PGP SIGNATURE----- --bX4XSlNKk3IeESqm497TXvHlM3NaSdeMJ-- From nobody Fri Oct 12 00:09:57 2018 Return-Path: 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 CD1D7130E01 for ; Fri, 12 Oct 2018 00:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.923 X-Spam-Level: X-Spam-Status: No, score=-0.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com 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 U1TNoUZDcjZQ for ; Fri, 12 Oct 2018 00:09:52 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0121.outbound.protection.outlook.com [104.47.93.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1533130E00 for ; Fri, 12 Oct 2018 00:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2PG6Anz/OrOmFegAztpPBLCpPX+zNiICrmMRyFRAKso=; b=GUkfOiJdSGWP/XssfqI5+kBmdekG4JmT/SYRQTUCRHxnhCLyZTMmkJkm2bVw+odD+yXU/cSXWaa/tWaEGYZcYTSi4bor8Ep2FTUF1I3xikc/6zvqZhlwBIvKeLVouHtPKTNy7T1AuHcpW2lHJvK7dJnd3uZky6Jq21jto/yZ7Qw= Received: from TY1PR01MB1547.jpnprd01.prod.outlook.com (52.133.162.14) by TY1PR01MB1820.jpnprd01.prod.outlook.com (52.133.164.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.25; Fri, 12 Oct 2018 07:09:48 +0000 Received: from TY1PR01MB1547.jpnprd01.prod.outlook.com ([fe80::cd50:6ad9:448d:cbb8]) by TY1PR01MB1547.jpnprd01.prod.outlook.com ([fe80::cd50:6ad9:448d:cbb8%4]) with mapi id 15.20.1228.020; Fri, 12 Oct 2018 07:09:48 +0000 From: =?utf-8?B?TWFydGluIEouIETDvHJzdA==?= To: "xml2rfc-dev@ietf.org" Thread-Topic: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" Thread-Index: AQHUXxXamSEVspvsCkS/OZq3NvM9iaUVdt6AgAAiJACAAAoLgIAAAowAgAAk/gCAAATrAIAAEa8AgAB4DoCAAAgQgIAA1eoAgAABvQCAABaqgIAAmgIAgABwjQCAAez9AIAAC7aAgADkDwA= Date: Fri, 12 Oct 2018 07:09:48 +0000 Message-ID: References: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> <065401d45f46$d92c3710$8b84a530$@augustcellars.com> <4308bb9a-14ef-ca1c-03b3-2d1d09bc95a5@levkowetz.com> <4e4af1df-37b8-c180-93d8-14104fe2281c@gmx.de> <075301d46006$e88ef420$b9acdc60$@augustcellars.com> <96e521a6-3534-c986-ac63-e03a12e64c94@levkowetz.com> <93ab666b-e787-5c83-7992-a048b531b8b0@rfc-editor.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: TY2PR06CA0031.apcprd06.prod.outlook.com (2603:1096:404:2e::19) To TY1PR01MB1547.jpnprd01.prod.outlook.com (2603:1096:403:4::14) authentication-results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [133.2.210.64] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; TY1PR01MB1820; 6:dYl6PAbV9ltBka4Q7GOHQSuCkSZmKtky1k2up2WcYhvcg5520doHiA/fIRR77DX57J1BAv3UhAzKdbhMrXF/5Qjt8Ns0F8SF+XC65z13G1UE9wiN1VeAAdxJpkz7MYAvfsxZp2qg1n7JfVZkCDxMsPMj0xYPA/A8yCui9EVXEZplxJy9YOjK0rgj19lgyaHtjyzHcZMr8oqkxbJ6UnUyE3NkE7yOyQwCKEGb886Al8FD66LGkvcbDQiFDkPlusgVRkG1Dv1awdyj1Joq9mY97fn06nXIzpQs0B+E3jZP9M0P75O//h73ikak1ulN9MOUv1vlZmkHHIp6pQ1dRvyZzTD6VVCwksvl0oPZuquAwRl8uSJ5ay2GaXasGcjMi8aaI5viX2Kw9VE2wL96IWChi1Irl6qpNLGslmVZvkxHBeaUQ6HyEqLunn0vWwmpzmjtgoj6IWShsBPAiv8Zfy+XDQ==; 5:41m0rooR06t0TMQAXB09EscplmYikf9/NuQ0+M/xSxq4jvXR3ggpRJvMbnXUTs17d5AC9EU5WmFOkKaglYY3SvQ6522fzfxElgPfGTM4mM4swqYgQMVQXwNHVDoFxqs0BYPzRalYuck1XeqECGBWfYSTphPNsDrlUVWqhJFBHwE=; 7:X/MmvbrAE0zR3o/r4cO5fmXS7Umw1FS7DOUTqp4ayy2pmixTSCq3SZ+K0dU0YtEBdquV1KybYYOblm0hcoxNa/+KN2Ii54EKiYYFs9JieZi8x4HEbZtHGxdkss2zWc/SBeQT69F+dz6oRHCeBlNXRYNmU9I3jJ3yjOjKDB0CcMeWChvAo0LQkcwCHJcrKUWLOJFqdpBbYxWmEbR7Gmi6R11qqFlRyZ94fotYGkTWhfd4m3MIPj6Aghoep65kGOYZ x-ms-office365-filtering-correlation-id: 517e2387-b1d7-4b2f-1d81-08d63011b232 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:TY1PR01MB1820; x-ms-traffictypediagnostic: TY1PR01MB1820: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(10201501046)(3002001)(93006095)(93001095)(149066)(150057)(6041310)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(201708071742011)(7699051)(76991067); SRVR:TY1PR01MB1820; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB1820; x-forefront-prvs: 0823A5777B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39840400004)(136003)(366004)(376002)(346002)(5383002)(189003)(199004)(53754006)(2351001)(97736004)(93886005)(316002)(25786009)(4001150100001)(6512007)(2906002)(786003)(106356001)(2501003)(99286004)(85202003)(256004)(71190400001)(71200400001)(105586002)(53936002)(31696002)(5640700003)(6506007)(6436002)(5660300001)(53546011)(31686004)(52116002)(86362001)(386003)(966005)(6306002)(6246003)(14454004)(229853002)(76176011)(6486002)(6916009)(68736007)(26005)(186003)(74482002)(476003)(2616005)(478600001)(2900100001)(486006)(6116002)(102836004)(3846002)(85182001)(305945005)(7736002)(446003)(11346002)(66066001)(81166006)(8936002)(81156014)(8676002)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB1820; H:TY1PR01MB1547.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) x-microsoft-antispam-message-info: OVbnAJBpXkO53kZzDz+XXlPBJkcCL+0glvPvc6rsovSmi95Q98ZMVAZ5d6okWPT0sxY0NVFPauM8MwTbD/G2LbvETT9dZ9vzUjOHfXfrQ0ArnQucr3cHpFV6oNVVv66sWZVJVvsGRYLEAOZatygja7tfdeb32t5T02lNFMXBEAmpsjPzMsuOWenf77Tw/yICuuUS8HS7pJOWQeYoZzN2H6JhauFFQFA1dss7bh6pP+237KEp3013I23dWiUIQHQPw7Q9OP3qDevtX79Dv8bgikSTnfvNKzlyynCPWRKXO8vzS8mqKDR7mWSefD0tB9n2J/5YjugydKG1LJCSwYNI86DHDf1Hokqv+Rafuph1I3U= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <0B34E8FC7B92BC41B3CD911433A53ABD@jpnprd01.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 517e2387-b1d7-4b2f-1d81-08d63011b232 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2018 07:09:48.8144 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB1820 Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 07:09:56 -0000 SGVsbG8gZXZlcnlib2R5LA0KDQpPbiAyMDE4LzEwLzEyIDAyOjMzLCBIZW5yaWsgTGV2a293ZXR6 IHdyb3RlOg0KDQo+IE9uIDIwMTgtMTAtMTEgMTg6NTEsIEhlYXRoZXIgRmxhbmFnYW4gd3JvdGU6 DQoNCj4+IEJlZm9yZSB3ZSBnbyBkb3duIHRoaXMgcGF0aCwgaXQgbWlnaHQgYmUgd29ydGggcmV2 aWV3aW5nIHNvbWUgb2YgdGhlDQo+PiBlYXJsaWVyIGRpc2N1c3Npb25zIGFyb3VuZCA8c2VyaWVz SW5mbz4gaW4gWWUgT2xkZSBBcmNoaXZlLiBTZWU6DQo+Pg0KPj4gaHR0cHM6Ly93d3cucmZjLWVk aXRvci5vcmcvcGlwZXJtYWlsL3JmYy1pbnRlcmVzdC8yMDE0LURlY2VtYmVyLzAwODU0My5odG1s DQo+Pg0KPj4gRG9lcyB0aGlzIGluZm9ybWF0aW9uIGNoYW5nZSB5b3VyIHJlY29tbWVuZGF0aW9u Pw0KPiANCj4gVGhhbmsgeW91LiAgUmV2aWV3ZWQgYW5kIHVuZGVyc3Rvb2QuDQo+IA0KPiBIYXZp bmcgdGhvdWdodCBhYm91dCB0aGUgcG9pbnRzIG1hZGUgaW4gdGhlIHRocmVhZCwgYW5kIHRoZSBp c3N1ZXMNCj4gSSd2ZSBsaXN0ZWQgaW4gdGhlIGRyYWZ0LCBpdCB0dXJucyBvdXQgdGhhdCB0aGUg cHJlbWlzZSBvZiB0aGF0IHRocmVhZDoNCj4gDQo+ICJUaGUgLTE0IGRyYWZ0IGhhcyBvbmx5IG9u ZSBzaWduaWZpY2FudCBjaGFuZ2U6IGl0IG1ha2VzIDxzZXJpZXNJbmZvPg0KPiBhIGNoaWxkIG9m IDxmcm9udD4sIGFuZCBkZXByZWNhdGVkIGl0IGFzIGEgY2hpbGQgb2YgPHJlZmVyZW5jZT4uIFRo ZQ0KPiBwdXJwb3NlIG9mIHRoaXMgaXMgdG8gYWxsb3cgdGhlIGluZm9ybWF0aW9uIGZvciBSRkNz IHRvIGNvbWUgZnJvbSBqdXN0DQo+IG9uZSBzb3VyY2UgaW5zdGVhZCBvZiB0aGUgZGlzcGFyYXRl IHNvdXJjZXMgbm93LiINCj4gDQo+IHdoaWxlIGxhdWRhYmxlLCBkb2VzIG5vdCB0dXJuIG91dCB0 byB3b3JrIHZlcnkgd2VsbCBpbiBwcmFjdGljZS4gIE15DQo+IGRyYWZ0IGdpdmVzIG1vcmUgZGV0 YWlscyBvbiB0aGUgaW5kaXZpZHVhbCBpc3N1ZXMsIGJ1dCB0aGUgc3VtbWFyeSBpczoNCj4gDQo+ ICAgKiBUaGlzIG1ha2VzIHYzIHJlZmVyZW5jZSBmaWxlcyBpbmNvbXBhdGlibGUgd2l0aCB0aGUg djIgcHJvY2Vzc29yLA0KPiAgICAgd2hpY2ggZHJpdmVzIHVzIGludG8gaGF2aW5nIHRvIG1haW50 YWluIHNlcGFyYXRlIHBhcmFsbGVsDQo+ICAgICByZWZlcmVuY2UgcmVwb3NpdG9yaWVzLiAgKEEg cG9pbnQgbm90IG1hZGUgaW4gdGhlIGRyYWZ0LCBidXQNCj4gICAgIHZlcnkgcmVsZXZhbnQpLg0K DQpUaGlzIHBvaW50IGlzIGluZGVlZCBleHRyZW1lbHkgcmVsZXZhbnQuIE5lZWRpbmcgdHdvIHNl cGFyYXRlIA0KcmVwb3NpdG9yaWVzIGlzIGEgdmVyeSBiYWQgaWRlYSBmcm9tIGFuIGVuZ2luZWVy aW5nIHBlcnNwZWN0aXZlLg0KDQpCdXQgd2hpbGUgSSB3YXMgdGhpbmtpbmcgIndlIHJlYWxseSBu ZWVkIHRvIGRvIGV2ZXJ5dGhpbmcgd2UgY2FuIHRvIA0KYXZvaWQgdGhpcyIsIEkgcmVhbGl6ZWQg dGhhdCB0aGVyZSB3YXMgb25lIGFzcGVjdCB0aGF0IG1heSBtYWtlIGl0IA0KcmVhbGx5IGRpZmZp Y3VsdCBOT1QgdG8gaGF2ZSB0d28gc2VwYXJhdGUgcmVwb3NpdG9yaWVzOiBOb24tQVNDSUkgYXV0 aG9yIA0KbmFtZXMsLi4uIEFzIGZhciBhcyBJIHVuZGVyc3RhbmQsIHYyIGRvZXNuJ3QgYWxsb3cg dGhhdCwgYnV0IGl0J3Mgb25lIG9mIA0KdGhlIGdvYWxzIG9mIHYzLg0KDQpTcGVha2luZyBmcm9t IHBlcnNvbmFsIGV4cGVyaWVuY2UsIEknZCBzdHJvbmdseSBwcmVmZXIgb2xkIFJGQ3MgSSANCmNv LWF1dGhvcmVkIHRvIGJlIHJlZmVyZW5jZWQgZnJvbSBuZXdlciBSRkNzIHdpdGggbXkgInJlYWwi IA0KKG5vdC1BU0NJSS1vbmx5KSBuYW1lIHRoYW4gd2l0aCB0aGUgQVNDSUkgc2ltcGxpZmljYXRp b24uIEknbSBub3Qgc3VyZSANCnRoaXMgaXMgcG9zc2libGUgd2l0aCBhIHNpbmdsZSByZXBvc2l0 b3J5Lg0KDQpSZWdhcmRzLCAgIE1hcnRpbi4NCg== From nobody Fri Oct 12 00:14:33 2018 Return-Path: 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 48554130E00 for ; Fri, 12 Oct 2018 00:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 aKUxo7_4NdQG for ; Fri, 12 Oct 2018 00:14:30 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D161F130DFD for ; Fri, 12 Oct 2018 00:14:29 -0700 (PDT) Received: from [192.168.178.20] ([91.61.63.77]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MBnPX-1gLd1p2a6p-00Ajt5; Fri, 12 Oct 2018 09:14:10 +0200 Received: from [192.168.178.20] ([91.61.63.77]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MBnPX-1gLd1p2a6p-00Ajt5; Fri, 12 Oct 2018 09:14:10 +0200 To: Henrik Levkowetz , Heather Flanagan , xml2rfc-dev@ietf.org References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> <8b71a263-a280-270a-4fb4-7e0a4e2abb0a@gmx.de> <926f11a0-3d4b-ffe0-d7b5-c7ec51f1083b@levkowetz.com> <10b47376-f6a3-0df0-11c4-fe3a2a18f4a4@rfc-editor.org> <075701d46007$5b52d620$11f88260$@augustcellars.com> <369bdaa3-264b-57e0-c7ff-ec7f24f125c5@gmx.de> <4392e03c-f4a4-a9a0-c53a-a43f9cd0e99f@rfc-editor.org> <406808a6-a6b5-43f5-1a01-ce0c1c7c7371@levkowetz.com> From: Julian Reschke Message-ID: Date: Fri, 12 Oct 2018 09:14:09 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <406808a6-a6b5-43f5-1a01-ce0c1c7c7371@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:youTrHf54SBYxnTbQnnDkQmFwyQtq+xOb1ATYeE0jzMi8nOVeOV AQjmk7BicdV7oLkwOqz8YxLg90uymTXclFpzPhQvR+DS2rrshYzpVBmRPqDxyGUIpiUe6dh G8T1GFCrI+u/AY7L0KXjBkjASp9e3Nh5ynHbOYnpzUDC206eEByd2g+Er2uwpu7mg2TnurF QdMZJnszM3aw+4PiXxUJw== X-UI-Out-Filterresults: notjunk:1;V01:K0:ofiqgD9ut1s=:cgVE5gGs0QbPFKAwb1VsLA m/nxMfYR5YIBuj2OXG3QJ53Yu3vMAhHe8Jevh13AK1HMtlbq12RxRr+Wp6kCjwwvuLUHUFdje /ynrTQkAF99QjJG+Y/Cbzg2naVdnAVNXa59x2gxDZ8Z3TICxWMUwUrFsSOJoJrqAmmg10DMCR TxGmxMeOpC12ARCN6acJTmBnxowJzrrXAqj92hW5n+CsbL/A3kpVrYKxq6k7NPeI0f5991zBa lvPdEA2X+FRUggcJUu2qFGUL/98oF6IJMJSlHtgBwBoAYX7MviiY70kRZkQl9524L6SS0+KNm Qc7p+pmRRWvdaK32XHtFP4ahaVJuxKAtsK4VBZpHIpUUgvYDIrZnBy0gjelOkOuT1Jkmu1ax5 oPkpxzvebyqIQsvmkfkBcy5/yzODrFTRN9rpSlvp4e9U+7Zt68tVzUtj90NOcRUMYhX0TC2Cc WUJ6wSdutL6G8ZQdHHUYx+8Hglmh6UhaYFt1jf6djL5mCBpwF8dUO8OtjG8KmIaStdmrxj1SC dB4XIIpi7fRl0sHlwYAZhRHGUKOxx/cWEeHe1xJMpdkOFNMsmeoNFEBl08y79aSQh/SYGV29+ ImtN7qWu/LKPtYLaoKGxRf3tZK+/Hfk2wshk9AuWbfo+GpCom9weP8u+LB2OQnF5kWFXdtKux R0JWockZhzWl/eUROda86NItifFB/AywYxNybnKvT1R1qRWaiRpEQOwvLMj0Flm7n8ny/XShM 3G+GsUbPM25GF97qN7Orz/4oFlosvYBHCiO9VOrFVk43C5sR9RULTpYXTWuI9Xwq1bo2vOO8E dCBmIgLPaGHMm+CAsh2Q9jTqwQi1Gm/Ki8O58YzuYEDbiBZnCo= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 07:14:32 -0000 On 2018-10-12 08:49, Henrik Levkowetz wrote: > Hi Heather, > > A bit more of an explanation and background information, below: > > On 2018-10-11 20:17, Julian Reschke wrote: >> On 2018-10-11 19:20, Heather Flanagan wrote: >>> ... >>> I am willing to agree re: ToC, but references must be expanded in the >>> document. Anything that requires pulling in external information, e.g., >>> from the bibxml library, must be incorporated in the final XML. >>> >>> -Heather >> >> Yes, nobody argues with that. >> >> Henrik's issue is only about inserting a container when there is more >> than one references section. > > Yes. > > Up until ca. RFC 3500, references weren't split up into separate > normative and informative references. Then some people starting > to do so, and xml2rfc rendered those as 2 top-level numbered sections. > > Some people felt that there should just be one top level 'References' > section, with the Normative and Informative parts as sub-sections. > > This was not implemented by updating the schema, but by doing 'magic' > inside xml2rfc: If there was one element, it was rendered > as a top-level section; if there were multiple , they > were rendered as sub-sections inside a top-level section. > > I feel that it's time to update the schema so that the published > XML reflects this, instead of having rendering tools continue to add > magic. Instead of this: > > > Normative References > > > > > Informative References > > > > being rendered with a magically appearing top-level "References" > section, we should have this in the prepped output and published > XML: > > > References > > > Normative References > > > > > Informative References > > > > > ... Henrik, thanks for adding more explanations so everybody knows what we're talking about :-) (And FWIW, I sort of agree that the current behavior was a hack just in order to avoid touching the vocabulary). That said: 1. The insertion of the container really truly is trivial. 2. *If* we change the vocabulary, we'll need to make sure that we don't make things more confusing. For instance, would be allowed as sibling of ? And what if you had multiple instances of inside ? Would that still be allowed, and how would it be rendered? Best regards, Julian From nobody Fri Oct 12 00:20:13 2018 Return-Path: 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 883A2130E4B for ; Fri, 12 Oct 2018 00:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 phxjSa2ETF7a for ; Fri, 12 Oct 2018 00:19:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BC3D130E54 for ; Fri, 12 Oct 2018 00:19:47 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:64491 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1gArjc-0001EL-KU; Fri, 12 Oct 2018 00:19:45 -0700 To: =?UTF-8?Q?Martin_J._D=c3=bcrst?= , "xml2rfc-dev@ietf.org" References: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> <065401d45f46$d92c3710$8b84a530$@augustcellars.com> <4308bb9a-14ef-ca1c-03b3-2d1d09bc95a5@levkowetz.com> <4e4af1df-37b8-c180-93d8-14104fe2281c@gmx.de> <075301d46006$e88ef420$b9acdc60$@augustcellars.com> <96e521a6-3534-c986-ac63-e03a12e64c94@levkowetz.com> <93ab666b-e787-5c83-7992-a048b531b8b0@rfc-editor.org> From: Henrik Levkowetz Message-ID: Date: Fri, 12 Oct 2018 09:19:36 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3vWU51JfqnJhe8L888THR8sEoWKevmKRF" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, duerst@it.aoyama.ac.jp X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 07:20:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3vWU51JfqnJhe8L888THR8sEoWKevmKRF Content-Type: multipart/mixed; boundary="F8fdJb7A8bTowcow1OgjbW9HbhsW3926r"; protected-headers="v1" From: Henrik Levkowetz To: =?UTF-8?Q?Martin_J._D=c3=bcrst?= , "xml2rfc-dev@ietf.org" Message-ID: Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" References: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> <065401d45f46$d92c3710$8b84a530$@augustcellars.com> <4308bb9a-14ef-ca1c-03b3-2d1d09bc95a5@levkowetz.com> <4e4af1df-37b8-c180-93d8-14104fe2281c@gmx.de> <075301d46006$e88ef420$b9acdc60$@augustcellars.com> <96e521a6-3534-c986-ac63-e03a12e64c94@levkowetz.com> <93ab666b-e787-5c83-7992-a048b531b8b0@rfc-editor.org> In-Reply-To: --F8fdJb7A8bTowcow1OgjbW9HbhsW3926r Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Martin, On 2018-10-12 09:09, Martin J. D=C3=BCrst wrote: > Hello everybody, >=20 > On 2018/10/12 02:33, Henrik Levkowetz wrote: >=20 >> On 2018-10-11 18:51, Heather Flanagan wrote: >=20 >>> Before we go down this path, it might be worth reviewing some of the >>> earlier discussions around in Ye Olde Archive. See: >>> >>> https://www.rfc-editor.org/pipermail/rfc-interest/2014-December/00854= 3.html >>> >>> Does this information change your recommendation? >>=20 >> Thank you. Reviewed and understood. >>=20 >> Having thought about the points made in the thread, and the issues >> I've listed in the draft, it turns out that the premise of that thread= : >>=20 >> "The -14 draft has only one significant change: it makes >> a child of , and deprecated it as a child of . The >> purpose of this is to allow the information for RFCs to come from just= >> one source instead of the disparate sources now." >>=20 >> while laudable, does not turn out to work very well in practice. My >> draft gives more details on the individual issues, but the summary is:= >>=20 >> * This makes v3 reference files incompatible with the v2 processor, >> which drives us into having to maintain separate parallel >> reference repositories. (A point not made in the draft, but >> very relevant). >=20 > This point is indeed extremely relevant. Needing two separate=20 > repositories is a very bad idea from an engineering perspective. >=20 > But while I was thinking "we really need to do everything we can to=20 > avoid this", I realized that there was one aspect that may make it=20 > really difficult NOT to have two separate repositories: Non-ASCII autho= r=20 > names,... As far as I understand, v2 doesn't allow that, but it's one o= f=20 > the goals of v3. Actually, xml2rfc has has had a --utf8 switch for quite some time, so even if you're not running the latest version, it should be possible to use reference files containing non-ascii. That has not been particularly useful until recently, but when the IESG approved a change in draft submission policy last week, to allow non-ascii characters in draft submission, it becomes more relevant. I think it may be possible to change the default for the --utf8 switch to be default on, going forward. > Speaking from personal experience, I'd strongly prefer old RFCs I=20 > co-authored to be referenced from newer RFCs with my "real"=20 > (not-ASCII-only) name than with the ASCII simplification. I'm not sure = > this is possible with a single repository. Hmm. _That_ is a slightly more complex issue, because it also requires those references to be manually corrected, rather than (as now) automatically generated from the published information. Best regards, Henrik --F8fdJb7A8bTowcow1OgjbW9HbhsW3926r-- --3vWU51JfqnJhe8L888THR8sEoWKevmKRF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlvASwgACgkQTptXS4+7 Fxp6XxAAgnsyUxdSBL5rTXuOLpNAViLJtI2SZsrRDezGqYReNS56dodUbyfNdJiP 7MFfO50cMg3EO0hqc/5xsfjsJoIWe8CLGcVt8m7UweAQZl1LgHrkziGlVzmzU4Rx FldX5z8Yzsnpebc9kQPwyASIiIGxYSzL5LzzXy258J8BXeBINWSpxjJLxcOGwtxi 0icXXyQlIZVU4B5cRHZELEg4ISvyHpeVWd2VcmbiXwKBfNXJxJvVOnXtp1oeBMTh yZUEau5ULQM9kXpQDHeR7nijMjZvCRUHrwmqV2smp00c9JePWDSfoLGUHQ9wjQA4 6c7nQjPMcKVWEyj1PnI8LdeLCCpntMZ54QjQRQvNIZL9IKsuuZchDeG8TGFsHkax jKp1GmcGa8gtUpr1dozrZ6jm2klgQw5fMAM9JqxPQyq3HGxGZFukctGunJsBG6tR V5OXfuDGb/PqP/pRvC5Nmz87v0ojeGM/RJIGEr13jn6UHLhFLWUr2/ngn711On0O FQf2RDaWpHkVdJUvjLz5P5Zg4MCGsDdbZTzpcuRZ2YSFfLHdkiEc5LgaKTQZP+HP oAxbjvnqJD/Kow+qsTLzam/QdnUrNpv1WD9PGRUckA9w+DAjy22+uzuAwbpqPgFR HE7+h2H6jmVfuiOLO2IgB+VB2lk58x8erg9MQqfTUpb8/L/79x8= =Ud10 -----END PGP SIGNATURE----- --3vWU51JfqnJhe8L888THR8sEoWKevmKRF-- From nobody Fri Oct 12 00:29:18 2018 Return-Path: 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 AF0AB130E01 for ; Fri, 12 Oct 2018 00:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 rtyPZt03dNsk for ; Fri, 12 Oct 2018 00:29:15 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82B67130DFB for ; Fri, 12 Oct 2018 00:29:15 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:64528 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1gArso-00086Y-Cz; Fri, 12 Oct 2018 00:29:14 -0700 To: Julian Reschke , Heather Flanagan , xml2rfc-dev@ietf.org References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> <8b71a263-a280-270a-4fb4-7e0a4e2abb0a@gmx.de> <926f11a0-3d4b-ffe0-d7b5-c7ec51f1083b@levkowetz.com> <10b47376-f6a3-0df0-11c4-fe3a2a18f4a4@rfc-editor.org> <075701d46007$5b52d620$11f88260$@augustcellars.com> <369bdaa3-264b-57e0-c7ff-ec7f24f125c5@gmx.de> <4392e03c-f4a4-a9a0-c53a-a43f9cd0e99f@rfc-editor.org> <406808a6-a6b5-43f5-1a01-ce0c1c7c7371@levkowetz.com> From: Henrik Levkowetz Message-ID: <926f3f73-7c90-2a51-6849-3f6e8dcdbe8d@levkowetz.com> Date: Fri, 12 Oct 2018 09:29:06 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rrLKVM1RF004BjncD8qBtMDXSRIgkxO2n" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, rse@rfc-editor.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 07:29:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rrLKVM1RF004BjncD8qBtMDXSRIgkxO2n Content-Type: multipart/mixed; boundary="hcotSiCptlnfHMD4KrksF1HrxnkFUFnkx"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , Heather Flanagan , xml2rfc-dev@ietf.org Message-ID: <926f3f73-7c90-2a51-6849-3f6e8dcdbe8d@levkowetz.com> Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> <8b71a263-a280-270a-4fb4-7e0a4e2abb0a@gmx.de> <926f11a0-3d4b-ffe0-d7b5-c7ec51f1083b@levkowetz.com> <10b47376-f6a3-0df0-11c4-fe3a2a18f4a4@rfc-editor.org> <075701d46007$5b52d620$11f88260$@augustcellars.com> <369bdaa3-264b-57e0-c7ff-ec7f24f125c5@gmx.de> <4392e03c-f4a4-a9a0-c53a-a43f9cd0e99f@rfc-editor.org> <406808a6-a6b5-43f5-1a01-ce0c1c7c7371@levkowetz.com> In-Reply-To: --hcotSiCptlnfHMD4KrksF1HrxnkFUFnkx Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Julian, Snipping some, in order to talk about the particular points you raised: On 2018-10-12 09:14, Julian Reschke wrote: > On 2018-10-12 08:49, Henrik Levkowetz wrote: =2E.. >> I feel that it's time to update the schema so that the published >> XML reflects this, instead of having rendering tools continue to add >> magic. Instead of this: >>=20 >> >> Normative References >> >> >>=20 >> >> Informative References >> >> >>=20 >> being rendered with a magically appearing top-level "References" >> section, we should have this in the prepped output and published >> XML: >>=20 >> >> References >>=20 >> >> Normative References >> >> >>=20 >> >> Informative References >> >> >>=20 >> >> ... >=20 > Henrik, >=20 > thanks for adding more explanations so everybody knows what we're=20 > talking about :-) >=20 > (And FWIW, I sort of agree that the current behavior was a hack just in= =20 > order to avoid touching the vocabulary). >=20 > That said: >=20 > 1. The insertion of the container really truly is trivial. >=20 > 2. *If* we change the vocabulary, we'll need to make sure that we don't= =20 > make things more confusing. For instance, would be allowed = > as sibling of ? I'd say no for . And should have siblings only within an outer enclosing element. > And what if you had multiple instances of=20 > inside ? Would that still be allowed, and how would = > it be rendered? I'd say to disallow this in v3, and let the v2v3 converter transform it to a v3-compliant form when found in v2. How would you prefer to do it? Best regards, Henrik --hcotSiCptlnfHMD4KrksF1HrxnkFUFnkx-- --rrLKVM1RF004BjncD8qBtMDXSRIgkxO2n Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlvATUIACgkQTptXS4+7 Fxq0BBAAkP+YVVvds1sQDDdcPEUkpgoFZU3DDBeF4uqdcYUSeL3pfJgZpuiO3TZH TQKufDOP+zGxCYDRgV18nKNaXl8frmf7amq3He+7/23xH8np3dLUl5UTeHcoCAT3 n/OSr2uul7ftJypGX/zCoBTMxjvP1Ykn16u5kxZtI0mN8LR4YLD4o38QzXbBkH7g c+6c9NLDLkU3+Dx1Qe4tZ2TT0aVuvJz7F+Pb4jo1wb8/6/ShhSZCzXVr5wAaflCT rjp87M1IEORYWCaiZ2acz0EcT5Q5Cpi/HtNIV1bdXe5boD8KchrbxMYxzcUNyZx3 I1jSXom7mjfxPo6bBSyk2T9ktnLH/qpSLz9R+se0VMYDYRM8BGd3uWBx5aW4xQDy RzzW1jiUd6E6lMQqayh8ac7UmNQ2HWSOEY7W1HWy8hW6rEGhW4PHv4qyV+ZxsiNI ABEuaPbyo1g1fUnJbEXsUuFz0i4+e2h4N7DcHLUnbN/uB26lV3hdcGo+jwtONWSK lQV1yHmDlzJ1EAUTVKzWGjokDZvKjIMg/MaGWUIbFKoebwxhecfFrL4tid1gdHtc FVPtf/gZ8dr3d6q8GK2pSRLftQcDu91qzEvPlxLbGdhRxZU6NKIuuwOgv3vUCvrn A6SaQELKfAFR3TrqM2b/NqVdBG3QfLvxpMxvtT6iLjMZh4E5sGk= =9Jvo -----END PGP SIGNATURE----- --rrLKVM1RF004BjncD8qBtMDXSRIgkxO2n-- From nobody Fri Oct 12 00:36:25 2018 Return-Path: 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 C0B66130E01 for ; Fri, 12 Oct 2018 00:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 X3S32xzyUfrQ for ; Fri, 12 Oct 2018 00:36:21 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53D17130DFB for ; Fri, 12 Oct 2018 00:36:20 -0700 (PDT) Received: from [192.168.178.20] ([91.61.63.77]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MTvUT-1g2JNv4Akr-00Qm7A; Fri, 12 Oct 2018 09:36:07 +0200 Received: from [192.168.178.20] ([91.61.63.77]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MTvUT-1g2JNv4Akr-00Qm7A; Fri, 12 Oct 2018 09:36:07 +0200 To: Henrik Levkowetz , Heather Flanagan , xml2rfc-dev@ietf.org References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> <8b71a263-a280-270a-4fb4-7e0a4e2abb0a@gmx.de> <926f11a0-3d4b-ffe0-d7b5-c7ec51f1083b@levkowetz.com> <10b47376-f6a3-0df0-11c4-fe3a2a18f4a4@rfc-editor.org> <075701d46007$5b52d620$11f88260$@augustcellars.com> <369bdaa3-264b-57e0-c7ff-ec7f24f125c5@gmx.de> <4392e03c-f4a4-a9a0-c53a-a43f9cd0e99f@rfc-editor.org> <406808a6-a6b5-43f5-1a01-ce0c1c7c7371@levkowetz.com> <926f3f73-7c90-2a51-6849-3f6e8dcdbe8d@levkowetz.com> From: Julian Reschke Message-ID: <99b1775d-eeca-6945-37d2-097651b1fd60@gmx.de> Date: Fri, 12 Oct 2018 09:36:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <926f3f73-7c90-2a51-6849-3f6e8dcdbe8d@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:ZR+FKye5a2QM2+p5zPH8GimOeF3WfSJoK5fBEitBz6OWJ9M2sMW 0Nm1b8T/TdIY6QP5nt9nJpaTNCznXMj6j+4RVzHk7vf3in6QU+/vS9IGuG1htZQUyxNwkdq zTuvZR3ordm5LkEbh+T79PIAMmXjAs4Lg8pBSSZWxqmsZSTPnP1M2tugfvfwCJ0dl8X9qFg KayCFJAarUgIurHE+alyA== X-UI-Out-Filterresults: notjunk:1;V01:K0:H0V27Ym23co=:s4L+QqdYJAv14psk7fLqxU b1dicp0EyRdquByd8Z9HoKbpFzWRWQHJI2q8BM5Tc5QC61q8mIoPw/XK69XnsiCYv8kIIxopf Aoo6WZclnnAc1OHFbDKyO0L89tqJuEFzSyZTRjBBmnYBG2DBBNunHIbQSxsV9vtv8d8dMygHU 8gGoHLtA+6a7UIeppB0Kziqwx/AulTXMd8kN5F8KgnzSw7upWZBjXAOwWCiThCmHYZN4qIPTf W4QxQpm6pQiVrY/WHU6oIo2KyINzTpEHJGUqGf1r0XXLtqBeOCiTzaFMdG9kfjJy41pY0ct0a 9RPGEJfjFRm62EPbu39VjnBoi4n2HA3Ffr3jNELhJ/L4a4GuQPKOJ+GTC5j7fBaW3EKibp/rs KNhJfBG/pe+zzf0z/chw8qbr8BoQOkp1hgZCT2cfunlzUIOJ0iqQ0xuzqYYK37TvZShWDU5Sq fk+Mr2syhVFXP5OM+xuBvbh0e5Z+T7CkLEqTrdeSeXWpOEBG/mNHt1PgKVCKPrnHf4rpXC0cU s/vCpKdnIaUpfuNkRMvW7kqotnjaX2X1Ywj5RLGtRLqknP0qDky+iGWk6Rm2R/PtgesqkT0j7 f01VOS0I80sS8ByaZ/ZjC/aTrGtrmpOq9BB5SAva3DtI37WaAjwa6hnvGpdSlQ4YX+LcYkC2z k0OCV8f5kPlSNg8lh+B6sGvLrINAMe6O5gaZsaKJHxcCZIASduWV/q0XlghgyJM0MmCcI5Rut LneFx/zkF6aSNUUEv1SBvQXWu599gky+rAe0vqZBVSaZEwdoCtCm/RkrD/xViHGgNisx7/YEi LMGVNYGM+hGr0BAZ/3JmqB9k0/1EwMan3hBCLb88QTyy0xpdYA= Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 07:36:24 -0000 On 2018-10-12 09:29, Henrik Levkowetz wrote: > ... >> That said: >> >> 1. The insertion of the container really truly is trivial. >> >> 2. *If* we change the vocabulary, we'll need to make sure that we don't >> make things more confusing. For instance, would be allowed >> as sibling of ? > > I'd say no for . > > And should have siblings only within an outer > enclosing element. > >> And what if you had multiple instances of >> inside ? Would that still be allowed, and how would >> it be rendered? > > I'd say to disallow this in v3, and let the v2v3 converter transform > it to a v3-compliant form when found in v2. > > How would you prefer to do it? > ... I note that none of these can be trivially expressed in the grammar, so I fear it causes confusion. There's also the new element for which we'd need additional constraints. So I remain unconvinced that this is an improvement. Best regards, Julian From nobody Fri Oct 12 00:45:58 2018 Return-Path: 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 E33A7130E08 for ; Fri, 12 Oct 2018 00:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 sVCTdKMRy_oB for ; Fri, 12 Oct 2018 00:45:55 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A5F4130DFB for ; Fri, 12 Oct 2018 00:45:55 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:64644 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1gAs8w-0000Bh-OT; Fri, 12 Oct 2018 00:45:55 -0700 To: Julian Reschke , Heather Flanagan , xml2rfc-dev@ietf.org References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> <8b71a263-a280-270a-4fb4-7e0a4e2abb0a@gmx.de> <926f11a0-3d4b-ffe0-d7b5-c7ec51f1083b@levkowetz.com> <10b47376-f6a3-0df0-11c4-fe3a2a18f4a4@rfc-editor.org> <075701d46007$5b52d620$11f88260$@augustcellars.com> <369bdaa3-264b-57e0-c7ff-ec7f24f125c5@gmx.de> <4392e03c-f4a4-a9a0-c53a-a43f9cd0e99f@rfc-editor.org> <406808a6-a6b5-43f5-1a01-ce0c1c7c7371@levkowetz.com> <926f3f73-7c90-2a51-6849-3f6e8dcdbe8d@levkowetz.com> <99b1775d-eeca-6945-37d2-097651b1fd60@gmx.de> From: Henrik Levkowetz Message-ID: <77e010cf-5fd4-0fdc-3729-54de52ebf1a4@levkowetz.com> Date: Fri, 12 Oct 2018 09:45:47 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <99b1775d-eeca-6945-37d2-097651b1fd60@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="P76oPw67GMr4a8qbgkteTilwbQDfHeaWu" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, rse@rfc-editor.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 07:45:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --P76oPw67GMr4a8qbgkteTilwbQDfHeaWu Content-Type: multipart/mixed; boundary="N3FnCfo4MNRCUSufNxdxcLu5SBjVwWKRA"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , Heather Flanagan , xml2rfc-dev@ietf.org Message-ID: <77e010cf-5fd4-0fdc-3729-54de52ebf1a4@levkowetz.com> Subject: Re: [xml2rfc-dev] RFC 7991 issue #49: Schema Issue, RFC 7991, In Section 2.42, References: <706f9842-795e-7019-ab2d-e28bdd3db3b2@gmx.de> <11f8332a-cc6f-9ea6-d99c-5616e16f06a9@gmx.de> <8b71a263-a280-270a-4fb4-7e0a4e2abb0a@gmx.de> <926f11a0-3d4b-ffe0-d7b5-c7ec51f1083b@levkowetz.com> <10b47376-f6a3-0df0-11c4-fe3a2a18f4a4@rfc-editor.org> <075701d46007$5b52d620$11f88260$@augustcellars.com> <369bdaa3-264b-57e0-c7ff-ec7f24f125c5@gmx.de> <4392e03c-f4a4-a9a0-c53a-a43f9cd0e99f@rfc-editor.org> <406808a6-a6b5-43f5-1a01-ce0c1c7c7371@levkowetz.com> <926f3f73-7c90-2a51-6849-3f6e8dcdbe8d@levkowetz.com> <99b1775d-eeca-6945-37d2-097651b1fd60@gmx.de> In-Reply-To: <99b1775d-eeca-6945-37d2-097651b1fd60@gmx.de> --N3FnCfo4MNRCUSufNxdxcLu5SBjVwWKRA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-10-12 09:36, Julian Reschke wrote: > On 2018-10-12 09:29, Henrik Levkowetz wrote: >> ... >>> That said: >>> >>> 1. The insertion of the container really truly is trivial. >>> >>> 2. *If* we change the vocabulary, we'll need to make sure that we don= 't >>> make things more confusing. For instance, would be allowe= d >>> as sibling of ? >>=20 >> I'd say no for . >>=20 >> And should have siblings only within an oute= r >> enclosing element. >>=20 >>> And what if you had multiple instances of >>> inside ? Would that still be allowed, and how woul= d >>> it be rendered? >>=20 >> I'd say to disallow this in v3, and let the v2v3 converter transform >> it to a v3-compliant form when found in v2. >>=20 >> How would you prefer to do it? >> ... >=20 > I note that none of these can be trivially expressed in the grammar, so= =20 > I fear it causes confusion. I was thinking (in Relax NG compact): back =3D element back { attribute xml:base { text }?, attribute xml:lang { text }?, displayreference*, references, section* } references =3D element references { attribute xml:base { text }?, attribute xml:lang { text }?, attribute pn { text }?, attribute anchor { xsd:ID }?, attribute title { text }?, name?, (references+ | (reference | referencegroup)*) } Best regards, Henrik --N3FnCfo4MNRCUSufNxdxcLu5SBjVwWKRA-- --P76oPw67GMr4a8qbgkteTilwbQDfHeaWu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlvAUSsACgkQTptXS4+7 FxpfVQ//aZ/93vNVQF2JL0ekTOtNHz5J4fF1uxX7o8bhNZv4ZPmtsCTU0vQ9gEsl bkuJJX5WJ+cUex96hoZBPRsBr5fPx/oweLlNj6hLBiGuS0ScN7DU7l3UEyC/dhtV WcSt+w+SxoE+K+1SOQ0bjilqCh8pVHWXhsLvEuRAxN4quaTLu+70gAmUY/Q3wDe6 UI4fHQvORhXxCVD8tmV5M8GDD+vSyMQQsxeO8VZlioD5KfLzyu2Dfz4CRag0oyGj E1W9ncwJFP/AgArI2PzvhOQu1L8K+SLzlOSjclygYmKEO0nNbgV0ghXN8qmKkTv/ M+NKTFyyp5jPpz/8pfFkcJnAncwNdQirp36+0cYHYoobAp7fRRMFMk9S8RNhtVli blLMr7YUTgVRMaCZYFSa+G0cNmDjKmgjyE7pAgVh0TwfwiSfTRhcOVAqtPmGlKBu aCX2tV6e6vOckx+NHQyaGUAddLHDsjIwnYo7Ui9Wsp/gPr8Luk7TtRRaKQ3san8L jnqq+a+7keCxG7DJ7RFbP8zFx2jC8qnK3T6KDvF6z+Ysoknm1HBOMS+JGuLMvm27 dKaknhC+rgQc9n9RDTcU8/HuXj/2lVuorNtTwFNEswFOlxw16L2+acbRzZkrj038 ot2eT6VTnQgyKtmMM7GgOCMcgAmwcGdeZOel5fpy6jsKnaSdaG8= =X+Ya -----END PGP SIGNATURE----- --P76oPw67GMr4a8qbgkteTilwbQDfHeaWu-- From nobody Mon Oct 15 09:22:21 2018 Return-Path: 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 EE969130ED1 for ; Mon, 15 Oct 2018 09:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 vc4-gkrZol8h for ; Mon, 15 Oct 2018 09:22:07 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EFE2130EC8 for ; Mon, 15 Oct 2018 09:22:07 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:50543 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1gC5d8-0004es-Jc for xml2rfc-dev@ietf.org; Mon, 15 Oct 2018 09:22:06 -0700 To: xml2rfc-dev@ietf.org From: Henrik Levkowetz Message-ID: <0c4919af-9129-f0cc-8021-84f27819a2ea@levkowetz.com> Date: Mon, 15 Oct 2018 18:21:59 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CBRRECToItOAff7KQ2jAnXsPoGbMr1Qx1" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc-dev] Question about RFC 7992, Section 6.4 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 16:22:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CBRRECToItOAff7KQ2jAnXsPoGbMr1Qx1 Content-Type: multipart/mixed; boundary="1c2Rh5K5EELDdg6Sg0csm4tbP0ruFj20o"; protected-headers="v1" From: Henrik Levkowetz To: xml2rfc-dev@ietf.org Message-ID: <0c4919af-9129-f0cc-8021-84f27819a2ea@levkowetz.com> Subject: Question about RFC 7992, Section 6.4 --1c2Rh5K5EELDdg6Sg0csm4tbP0ruFj20o Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The document says: --- 6.4. Page Headers and Footers In order to simplify printing by HTML renderers that implement [W3C.WD-css3-page-20130314], a hidden HTML
    tag of class "ears" is added at the beginning of the HTML tag, containing HTML and tags, each of which contains an HTML tag, which contains three HTML corresponds to the top of the page, the to the bottom. The string "[Page]" can be used as a placeholder for the page number. In practice, this must always be in the 's right
    tags with class "left", "center", and "right", respectively. The
    , and no control of the formatting of the page number is implied.
    Internet-Draft HTML RFC March 2016
    Hildebrand Expires September 2, 2016 [Page]
    --- =2E.. and? Is the formatter expected to fill out the cells, based on the pattern abo= ve, or is that supposed to happen magically based on WD-css3-page-20130314 ? If the cell content is supposed to be provided by the formatter, I'd like to have a bit more specification than the example above; if not, it would be nice for that to be stated explicitly. THe mention of the '[Page]' placeholder could be taken as an indication that all cell content shown are placeholders, but ... ? Regards, Henrik --1c2Rh5K5EELDdg6Sg0csm4tbP0ruFj20o-- --CBRRECToItOAff7KQ2jAnXsPoGbMr1Qx1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlvEvqcACgkQTptXS4+7 Fxr4mhAAtcV0eeNQ5uM1bz8x5J6oGBHE1HtR/0lHRtzPY9jN/vxR0ZsN0Z+FDhcy zuLyooyDx/NwtMIpXyXUrrbeeacLQAdYttbyPzpSmfeEYd0bIkyVXvmai7FMUToi sMAk+MP27iJkGq9aJOiza/5fV/2QBvwlIu5mTmzWuOuec91NQeaUPqQ5jK1Twcy/ ikMEFzytgUCKqDgZTafWEbVlY7b6tUH4gXfFGAHHCP7ZFR5LKtzXqHONxluJJp4W tLZRLtN76L1+DAX9UyF/P1MBtkRBxbgZ8hGX0bRT9pRctYl4+L0RZwb1DmlOaJw8 VsIzp6IeU7OyGz9pXXcEuZULwtzx+SgsA7Z2BD7NisQBRyIXWOHyMPWBCfzRZCxi dodfkXKAYAEPcNL8lC4Dwp1IDDXeaUKRUhOBn2/6qMjVkEcDIx0DzkvrzDcp7BxL YQswJC5OIac9pzIAhO4aBPgwBw6zmP6lN2DUMY8WM14hpW9YlCOql1QvTeTHfRMg 3mzyqNt/zfQuyllLxj9QwTSpDvwh6R8u1RPL3jzp/r1eQo7D7tWiVLaFhdLRP6jJ kDV17vqOxzIX2Zb9DJIvHrciVpaM8gjJbbnDYvMR5wxsrpLRvJS7JZBRkzZSIonk E6rQ1fCwmwOm7H9WC5Eg1Alc6KqLVFKQKUY9tV/a99JKJ282dRU= =N+0x -----END PGP SIGNATURE----- --CBRRECToItOAff7KQ2jAnXsPoGbMr1Qx1-- From nobody Wed Oct 17 11:54:50 2018 Return-Path: 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 537FF130EE3 for ; Wed, 17 Oct 2018 11:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 uaeFyIxeLu-T for ; Wed, 17 Oct 2018 11:54:46 -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 4D3DB130E19 for ; Wed, 17 Oct 2018 11:54:46 -0700 (PDT) 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 Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 17 Oct 2018 11:54:44 -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; Wed, 17 Oct 2018 11:54:44 -0700 From: Paul Hoffman To: XML Developer List Thread-Topic: New v3 format draft: draft-iab-rfc7991bis-00 Thread-Index: AQHUZkrdsxn67jVAAE6y3TX0j5EHog== Date: Wed, 17 Oct 2018 18:54:43 +0000 Message-ID: <9EC71512-976D-4A8E-8F17-B1BF517AE298@icann.org> 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=_BB4C4552-D248-4DCF-83CD-0018272F3D2C"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: [xml2rfc-dev] New v3 format draft: draft-iab-rfc7991bis-00 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 18:54:48 -0000 --Apple-Mail=_BB4C4552-D248-4DCF-83CD-0018272F3D2C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings again. Based on a request from Robert Sparks, I have changed = the filename of the v3 format draft to draft-iab-rfc7991bis. I took this = opportunity to fix some tooling errors I had made in order to prepare = for the slew of updates that will be coming soon. The GitHub repo for the draft is still at https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis even thought the filename of the published draft has changed. --Paul Hoffman A New Internet-Draft is available from the on-line Internet-Drafts = directories.=20 This draft is a work item of the Internet Architecture Board IETF of the = IETF.=20 Title : The "xml2rfc" version 3 Vocabulary=20 Author : Paul Hoffman=20 Filename : draft-iab-rfc7991bis-00.txt=20 Pages : 160=20 Date : 2018-10-17=20 Abstract:=20 This document defines the "xml2rfc" version 3 vocabulary: an XML-=20 based language used for writing RFCs and Internet-Drafts. It is=20 heavily derived from the version 2 vocabulary that is also under=20 discussion. This document obsoletes the earlier v3 grammar described=20 in RFC 7991, which in turn obsoleted the v2 grammar in RFC 7749.=20 Editorial Note (To be removed by RFC Editor)=20 Discussion of this draft takes place on the xml2rfc-dev@ietf.org=20 mailing list, which has its home page at=20 .=20 The IETF datatracker status page for this draft is:=20 https://datatracker.ietf.org/doc/draft-iab-rfc7991bis/ There are also htmlized versions available at:=20 https://tools.ietf.org/html/draft-iab-rfc7991bis-00 https://datatracker.ietf.org/doc/html/draft-iab-rfc7991bis-00 --Apple-Mail=_BB4C4552-D248-4DCF-83CD-0018272F3D2C Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAxNzE4NTQ0M1owIwYJKoZIhvcNAQkEMRYEFDJbfoNDtFr+M4OoLlsynwdbencOMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQAWfh7X+X7IIXyty51kOq8WEbUgJP+p5e+dIDap6bWc9RskaUs2Oawgmi989Bpq937osZQK 52jLNk9a90u3K4ZzS7Unow0kdHC9CaoOi0EHsZKcYtkO8TGXk4NX1HLZCzYOZSktdrHO2oI0X5RE 4GbYaW9cLVqAMQTwjT46ItyU2TdcX3rOdsx7ilkw4EoU0fwa0Gt/4y+5DCaC1DQ1bFqYjN/7GGDg fooLk8pjnTA2OSPoN/mQrcXqaBk7N5gINcnJm25XZ49Th9wscirrVNNSBtoHCjeNe0V/BVoUdC3z J2IJhXM/uuhxXx27FJSr7fCVulGwXzogbvJOuf5MYC1SAAAAAAAA --Apple-Mail=_BB4C4552-D248-4DCF-83CD-0018272F3D2C-- From nobody Fri Oct 19 08:12:36 2018 Return-Path: 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 20530130E74 for ; Fri, 19 Oct 2018 08:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 WiLjgtWUX5EV for ; Fri, 19 Oct 2018 08:12:33 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DF3C128D68 for ; Fri, 19 Oct 2018 08:12:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id B57711CADD4 for ; Fri, 19 Oct 2018 08:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUckk1iSNsZX for ; Fri, 19 Oct 2018 08:11:56 -0700 (PDT) Received: from Heathers-MacBook-Pro-2.local (unknown [163.253.49.36]) by c8a.amsl.com (Postfix) with ESMTPSA id 687271CA42E for ; Fri, 19 Oct 2018 08:11:56 -0700 (PDT) From: Heather Flanagan To: xml2rfc-dev@ietf.org Message-ID: <48af95a7-3fc0-3c28-728c-c88e5915d89c@rfc-editor.org> Date: Fri, 19 Oct 2018 11:12:31 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [xml2rfc-dev] Summary of issues - weeks of October 8, October 15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 15:12:35 -0000 Hola a todos! Here's what I took from the next batch of conversation: ------- Issue #31 - consensus reached: add align, default center, wrapping the title to match the max table width for the table caption Issue #45 - consensus reached: leave spec as is wrt
  • and layout for unordered lists Issue #46 - consensus reached: leaved spec as is wrt
  • mixed content model Issue #47 - consensus reached: change the element schema to permit all inline elements that can contain, in addition to . Issue #48 - discussion not quite done (I have a few questions) Issue #49 - decision made: References must be expanded and complete in the final XML. TOC and Index are completely derivable from the XML, but the actual format of those may change per publication format - no specification in the v3 spec required. ------- FYI - I've asked Henrik to focus on the HTML publication formatter for a few weeks, to see if we can get a first cut available in time for Bangkok. Expect issue discussion to slow down between now and Bangkok. Thanks, everyone! Heather From nobody Fri Oct 19 08:40:13 2018 Return-Path: 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 5C707130F76 for ; Fri, 19 Oct 2018 08:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 BaYjohCtSsd7 for ; Fri, 19 Oct 2018 08:40:02 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80C34130F73 for ; Fri, 19 Oct 2018 08:40:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id C1C881D06DB for ; Fri, 19 Oct 2018 08:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siYmkhvkpnBZ for ; Fri, 19 Oct 2018 08:39:24 -0700 (PDT) Received: from Heathers-MacBook-Pro-2.local (unknown [163.253.49.36]) by c8a.amsl.com (Postfix) with ESMTPSA id 752851C6297 for ; Fri, 19 Oct 2018 08:39:24 -0700 (PDT) To: xml2rfc-dev@ietf.org References: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> <065401d45f46$d92c3710$8b84a530$@augustcellars.com> <4308bb9a-14ef-ca1c-03b3-2d1d09bc95a5@levkowetz.com> <4e4af1df-37b8-c180-93d8-14104fe2281c@gmx.de> <075301d46006$e88ef420$b9acdc60$@augustcellars.com> <96e521a6-3534-c986-ac63-e03a12e64c94@levkowetz.com> <93ab666b-e787-5c83-7992-a048b531b8b0@rfc-editor.org> From: Heather Flanagan Message-ID: <994fa4b3-3d4a-992f-970f-9fe93e1f83df@rfc-editor.org> Date: Fri, 19 Oct 2018 11:38:44 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 15:40:12 -0000 Hola a todos, AFAICT, we are talking about two issues: whether it should revert to being quote-title versus a consistent-with-the-rest-of-the-spec quoteTitle; and, whether we should back out the v3 changes to . Both seem to have implications to the reference library. For the smaller change around quote title, I like the idea of being more consistent, especially since it seems to be something that can be dealt with and has only used been used in 10 XML sources. But, I don't understand what implications that actually has when it comes to the bigger issue around . Could someone help me with this? If we go ahead with the v3 changes to , we'll end up needing a parallel reference library. We seem to have two proposals on the table: 1) Revert the change entirely back to v2 2) An intermediate suggestion from Henrik: I think an intermediate solution, where is permitted directly after also under , as within , and there holds only what is actual series information the way it's already used in v2, but not any of the additional attributes like RFC number and docName, would work too. That would make series information for the document itself map directly to series information as used in , without having any of the drawbacks mentioned above. Technically, we could itemize a third proposal to go ahead with the changes as defined in v3, but I don't think anyone has argued for that. Let me know if that's not correct. So, second question: Would the intermediate suggestion also require a parallel reference library? Thanks! Heather From nobody Fri Oct 19 08:48:18 2018 Return-Path: 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 19568130F58 for ; Fri, 19 Oct 2018 08:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 ENT2gdDecq8Z for ; Fri, 19 Oct 2018 08:48:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CD6B130EF6 for ; Fri, 19 Oct 2018 08:48:14 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:64319 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1gDX0S-0005G3-TK; Fri, 19 Oct 2018 08:48:12 -0700 To: Heather Flanagan , xml2rfc-dev@ietf.org References: <48af95a7-3fc0-3c28-728c-c88e5915d89c@rfc-editor.org> From: Henrik Levkowetz Message-ID: <6734f3b5-6e31-14c5-21cf-42acda715468@levkowetz.com> Date: Fri, 19 Oct 2018 17:48:01 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <48af95a7-3fc0-3c28-728c-c88e5915d89c@rfc-editor.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dtfmWsLcna6JDgMGUNtdRLw2mMvumrivN" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, rse@rfc-editor.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] Summary of issues - weeks of October 8, October 15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 15:48:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dtfmWsLcna6JDgMGUNtdRLw2mMvumrivN Content-Type: multipart/mixed; boundary="0bQno8TdixPiVRuaxlOTeJVRS9Cg9L9fI"; protected-headers="v1" From: Henrik Levkowetz To: Heather Flanagan , xml2rfc-dev@ietf.org Message-ID: <6734f3b5-6e31-14c5-21cf-42acda715468@levkowetz.com> Subject: Re: [xml2rfc-dev] Summary of issues - weeks of October 8, October 15 References: <48af95a7-3fc0-3c28-728c-c88e5915d89c@rfc-editor.org> In-Reply-To: <48af95a7-3fc0-3c28-728c-c88e5915d89c@rfc-editor.org> --0bQno8TdixPiVRuaxlOTeJVRS9Cg9L9fI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Heather, Thank you for this :-) With respect to the ToC and Index discussion (which was not mentioned in #49 originally, so need not affect the #49 resolution below) I've realized that an additional factor would be whether the RFC Editor would want to tweak ToC or Index. This is maybe something that the RFC Production Center needs to talk about. Till I hear otherwise, I'll adjust xml2rfc to only use the generated ToC and Index XML internally, and not write those sections out when running --prep. Best regards, Henrik On 2018-10-19 17:12, Heather Flanagan wrote: > Hola a todos! >=20 > Here's what I took from the next batch of conversation: >=20 > ------- >=20 > Issue #31 - consensus reached: add align, default center, wrapping the = > title to match the max table width for the table caption >=20 > Issue #45 - consensus reached: leave spec as is wrt
  • and layout for= =20 > unordered lists >=20 > Issue #46 - consensus reached: leaved spec as is wrt
  • mixed content= =20 > model >=20 > Issue #47 - consensus reached: change the element schema to=20 > permit all inline elements that can contain, in addition to . >=20 > Issue #48 - discussion not quite done (I have a few questions) >=20 > Issue #49 - decision made: References must be expanded and complete in = > the final XML. TOC and Index are completely derivable from the XML, but= =20 > the actual format of those may change per publication format - no=20 > specification in the v3 spec required. >=20 > ------- >=20 >=20 > FYI - I've asked Henrik to focus on the HTML publication formatter for = a=20 > few weeks, to see if we can get a first cut available in time for=20 > Bangkok. Expect issue discussion to slow down between now and Bangkok. >=20 > Thanks, everyone! >=20 > Heather >=20 > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc-dev >=20 --0bQno8TdixPiVRuaxlOTeJVRS9Cg9L9fI-- --dtfmWsLcna6JDgMGUNtdRLw2mMvumrivN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlvJ/LEACgkQTptXS4+7 FxrhHQ/9HqkT2E1JRGiTDtrdqBzNHNIMDoCcDI+YLOXsx6+fnw+V1H5YE6GwqGGF FIiQFYy7VADOBrjBcgA/dOEPsw+ivqLuOeoQrEg66a8LwOr6Dv/r6LvmyKg03Ack 2lL7dvvHEELPj5hxAw60J1yALSePJgRXunN5MTSS+sKWI+VzoGhGogIzvs1p7Mqg nfZUKq8V6xwG/hlntS75wIEK/JO+qg5FeXOj0wUd5AteeOImOUMpdLmBuupdjs6m Vch03XRfHtyNzPkckdwl6vin27Dm9b1CDTrAAeYvb1OcjP4XlhluBGEupTQnK5uv 8i/XDwhUYfxMvnjv79GFanyGtVBSCCeqv78Fxm81bVLujKW3kEzyIbxHQp8GcFCf egNBNBD0Mwm5GXTWfnF9od3ONkr5tGL3aluFTFh6P2EMP4n7aCu+qC0v6G3vtZ4E ZkdkmgGcIAqyMk6BmaRYoqiFE6a9fVLgL9uk1xn8RIJBrHgsHDyJMwwTMSzkZPGN sHnpYouYjUrn53zZHIsWak+Mpp07VhgJVZ1S1Hm5NJxqPKSdzUeBojDt4ZeuoRVy cHL1654+AEcqwN1SH9HYZ4gpOMzUIW7G3T8QGehCIelyACe27v5anUreWIo1Y2ji 37CA4h711l9I3VVHDZwCUps/o6dy6ZYW+tkMvbTgHLhX7X3ozaU= =Q414 -----END PGP SIGNATURE----- --dtfmWsLcna6JDgMGUNtdRLw2mMvumrivN-- From nobody Fri Oct 19 08:52:34 2018 Return-Path: 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 F3C2D130F7E for ; Fri, 19 Oct 2018 08:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 pIkoptON-vlG for ; Fri, 19 Oct 2018 08:52:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7172B130EF6 for ; Fri, 19 Oct 2018 08:52:21 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:64336 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1gDX4W-000573-NH; Fri, 19 Oct 2018 08:52:21 -0700 To: Heather Flanagan , xml2rfc-dev@ietf.org References: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> <065401d45f46$d92c3710$8b84a530$@augustcellars.com> <4308bb9a-14ef-ca1c-03b3-2d1d09bc95a5@levkowetz.com> <4e4af1df-37b8-c180-93d8-14104fe2281c@gmx.de> <075301d46006$e88ef420$b9acdc60$@augustcellars.com> <96e521a6-3534-c986-ac63-e03a12e64c94@levkowetz.com> <93ab666b-e787-5c83-7992-a048b531b8b0@rfc-editor.org> <994fa4b3-3d4a-992f-970f-9fe93e1f83df@rfc-editor.org> From: Henrik Levkowetz Message-ID: Date: Fri, 19 Oct 2018 17:52:13 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <994fa4b3-3d4a-992f-970f-9fe93e1f83df@rfc-editor.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DoRcWsQxB5hUKXdWT2sGs6RciWUqcPrVq" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, rse@rfc-editor.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 15:52:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DoRcWsQxB5hUKXdWT2sGs6RciWUqcPrVq Content-Type: multipart/mixed; boundary="DpBqRAfGOmksHotBSXXh1HDd3BWEj7l2B"; protected-headers="v1" From: Henrik Levkowetz To: Heather Flanagan , xml2rfc-dev@ietf.org Message-ID: Subject: Re: [xml2rfc-dev] RFC 7991 issue #48: Schema Issue, RFC 7991, In Section 2.40.2, "quoteTitle" References: <062601d45f2b$98af3a40$ca0daec0$@augustcellars.com> <2416fcf2-761a-328f-7052-e851df898d76@gmx.de> <35d6c9c7-9b4c-f953-fdec-b012d712ff73@gmx.de> <065401d45f46$d92c3710$8b84a530$@augustcellars.com> <4308bb9a-14ef-ca1c-03b3-2d1d09bc95a5@levkowetz.com> <4e4af1df-37b8-c180-93d8-14104fe2281c@gmx.de> <075301d46006$e88ef420$b9acdc60$@augustcellars.com> <96e521a6-3534-c986-ac63-e03a12e64c94@levkowetz.com> <93ab666b-e787-5c83-7992-a048b531b8b0@rfc-editor.org> <994fa4b3-3d4a-992f-970f-9fe93e1f83df@rfc-editor.org> In-Reply-To: <994fa4b3-3d4a-992f-970f-9fe93e1f83df@rfc-editor.org> --DpBqRAfGOmksHotBSXXh1HDd3BWEj7l2B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Heather, On 2018-10-19 17:38, Heather Flanagan wrote: > Hola a todos, >=20 > AFAICT, we are talking about two issues: whether it should revert to=20 > being quote-title versus a consistent-with-the-rest-of-the-spec=20 > quoteTitle; and, whether we should back out the v3 changes to=20 > . Both seem to have implications to the reference library. >=20 > For the smaller change around quote title, I like the idea of being mor= e=20 > consistent, especially since it seems to be something that can be dealt= =20 > with and has only used been used in 10 XML sources. But, I don't=20 > understand what implications that actually has when it comes to the=20 > bigger issue around . Could someone help me with this? >=20 > If we go ahead with the v3 changes to , we'll end up needin= g=20 > a parallel reference library. We seem to have two proposals on the tabl= e: >=20 > 1) Revert the change entirely back to v2 >=20 > 2) An intermediate suggestion from Henrik: >=20 > I think an intermediate solution, where is permitted > directly after also under , as within , and > there holds only what is actual series information the way it's > already used in v2, but not any of the additional attributes like > RFC number and docName, would work too. That would make series > information for the document itself map directly to series information > as used in , without having any of the drawbacks mentioned > above. >=20 >=20 > Technically, we could itemize a third proposal to go ahead with the=20 > changes as defined in v3, but I don't think anyone has argued for that.= =20 > Let me know if that's not correct. >=20 > So, second question: Would the intermediate suggestion also require a=20 > parallel reference library? I believe we won't, no. That was a factor in proposing this. Best, Henrik --DpBqRAfGOmksHotBSXXh1HDd3BWEj7l2B-- --DoRcWsQxB5hUKXdWT2sGs6RciWUqcPrVq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlvJ/a0ACgkQTptXS4+7 FxrrxhAAhcwVm+xZzbOL9NzDPndIT/mtKzAx63K2dhzsbbViVBpWyY84hvAfJV5S hzBkI0zndiAzWJ9uaCtJ2KxO6R6eFrBojrvXyA9DGa9C5dDUoWLxk/IAVYMlZPuF W3Ua4fUsrmOKbcrJ11yVG2jdwvltch4nzbeOnZFHzOVdyivgaToQWegGZ98iA9RB HHOSOO9oRwTkc/CzAw66cvKyZAaL1XTFSMyzLF/8BDU3swOB4iubwc8env5H70iX AF43HCNcTSxWL9Wk846nWPJlrhoTeo11Peypclw7TB3JRJea5EWiJIHF44zYqJ5y EzNhLG7RH0G+f9tW0WGSFs9HaWkhzfWmtNhRH/uC7aOoyBupeCduMJOkwxF/3jGE +J8ocGtaT6UUE+qp/Op0ZwJyvgzoxh016IClnLZpN5QirCqigqlEyPMC+toGmCrH 3HrjkpVdKf0piNH1y3VjzTVxhMSUuapL92SaHgz5u21M4lwEelaPDtm38l2UIViC VhUKfpKsSFtf115dgEI7N6O+0lXuDw4fMFOFnu+la4s5x7HFf/VqX2zk8vt8P16W gujhYNEi2VX41ecRls15uw3hFNsn7n/JWZLvrMvo7POfP5icWNON8LbxOO2tp3OQ TdnEt8p0SzMu5yqwQPwNk5AVjcyuIQ0jU6KBA+mWBy2DH7BvviU= =4X44 -----END PGP SIGNATURE----- --DoRcWsQxB5hUKXdWT2sGs6RciWUqcPrVq-- From nobody Fri Oct 19 11:00:51 2018 Return-Path: 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 25311130FAF for ; Fri, 19 Oct 2018 11:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 bLowZjrNAWyW for ; Fri, 19 Oct 2018 11:00:45 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEE00130E77 for ; Fri, 19 Oct 2018 11:00:45 -0700 (PDT) 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 Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 19 Oct 2018 11:00:43 -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; Fri, 19 Oct 2018 11:00:43 -0700 From: Paul Hoffman To: XML Developer List Thread-Topic: -01 of draft-iab-rfc7991bis published Thread-Index: AQHUZ9WnJrkkWPuHVEeXV2OITWyueg== Date: Fri, 19 Oct 2018 18:00:42 +0000 Message-ID: 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=_5C2BB37C-02D0-48CB-8E70-8B893DE02120"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: [xml2rfc-dev] -01 of draft-iab-rfc7991bis published 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 18:00:49 -0000 --Apple-Mail=_5C2BB37C-02D0-48CB-8E70-8B893DE02120 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The following represents a bunch of issues from the list that have been = accepted. The announcement is below, followed by a diff of the XML. The next draft will likely not be until after the IETF meeting in = Bangkok. In the meantime, I will be doing more pull requests for the = recently-closed issues, and updating the tools a bit. Comments are welcome, of course. --Paul Hoffman A New Internet-Draft is available from the on-line Internet-Drafts = directories.=20 This draft is a work item of the Internet Architecture Board IETF of the = IETF.=20 Title : The "xml2rfc" version 3 Vocabulary=20 Author : Paul Hoffman=20 Filename : draft-iab-rfc7991bis-01.txt=20 Pages : 160=20 Date : 2018-10-19=20 Abstract:=20 This document defines the "xml2rfc" version 3 vocabulary: an XML-=20 based language used for writing RFCs and Internet-Drafts. It is=20 heavily derived from the version 2 vocabulary that is also under=20 discussion. This document obsoletes the earlier v3 grammar described=20 in RFC 7991, which in turn obsoleted the v2 grammar in RFC 7749.=20 Editorial Note (To be removed by RFC Editor)=20 Discussion of this draft takes place on the xml2rfc-dev@ietf.org=20 mailing list, which has its home page at=20 .=20 The IETF datatracker status page for this draft is:=20 https://datatracker.ietf.org/doc/draft-iab-rfc7991bis/ There are also htmlized versions available at:=20 https://tools.ietf.org/html/draft-iab-rfc7991bis-01 https://datatracker.ietf.org/doc/html/draft-iab-rfc7991bis-01 A diff from the previous version is available at:=20 https://www.ietf.org/rfcdiff?url2=3Ddraft-iab-rfc7991bis-01 diff --git a/draft-iab-rfc7991bis.xml b/draft-iab-rfc7991bis.xml index c4a63da..0959d36 100644 --- a/draft-iab-rfc7991bis.xml +++ b/draft-iab-rfc7991bis.xml @@ -170,7 +170,18 @@ and this document. =20 Changed the text about what this draft obsoletes and updates. =20 -[[ More will be added here as the draft progresses. ]] +Allow <blockquote> as a child of <li>. + +Removed "It is an error to have both a "src" attribute and content = in the <artwork> element." +from . + +Removed <br> from the vocabulary. + +Changed the "hanging" attribute of <dl> to "newline". + +Added the "indent" attribute to <dl>. + +Added the "align" attribute to <table>. =20 =20 @@ -228,7 +239,7 @@ as STDs and BCPs. =20 Add <link> to point to a resource related to = the RFC. =20 -Add <br> to allow line breaks (but not blank = lines) in the generated output +Add <br> to allow line breaks (but not blank lines) in the = generated output for table cells. =20 Add <svg> to allow easy inclusion of SVG = drawings in <artwork>. @@ -783,9 +794,6 @@ See for a = description of how to deal with is In some cases, the prep tool may remove the "src" attribute = after processing its value. See for a description of this. - - It is an error to have both a "src" attribute and content in = the <artwork> element. - =20 @@ -1106,7 +1114,7 @@ See for a = description of how to deal with is Specifies that a block of text is a quotation. - This element appears as a child element of = <section> (). + This element appears as a child element of = <li> () and = <section> (). Content = model: @@ -1244,23 +1252,6 @@ See for a = description of how to deal with is =20 =20 - -
    - - <br> - - - - - - Indicates that a line break should be inserted in the generated = output by a formatting tool. - Multiple successive instances of this element are ignored. - - This element appears as a child element of = <td> () and = <th> (). - - Content model: = this element does not have any contents. -
    -
    @@ -1712,15 +1703,31 @@ See for a = description of how to deal with is
    =20 - -
    - "hanging" Attribute - - - + +
    + "indent" Attribute + + + - The "hanging" attribute defines whether or not the term = appears on the same line as the definition. - hanging=3D"true" indicates that the term is to the left of the = definition, while hanging=3D"false" + Indicates the indentation to be used for the rendering of the = second and + following lines of the item (the first line starts with the = term, and is not indented). + The indentation amount is interpreted as characters when = rendering + plain-text documents, and en-space units when rendering in = formats that have + richer typographic support such as HTML or PDF. + One en-space is assumed to be the length of 0.5 em-space in = CSS units. + +
    + + +
    + "newline" Attribute + + + + + The "newline" attribute defines whether or not the term = appears on the same line as the definition. + newline=3D"true" indicates that the term is to the left of the = definition, while newline=3D"false" indicates that the term will be on a separate line. Allowed values: @@ -2324,6 +2331,9 @@ See for a = description of how to deal with is
  • <artwork> elements ()
    • +
  • + + <blockquote> elements ()
  • <dl> elements ()
    • @@ -4465,6 +4475,25 @@ See for a = description of how to deal with is =20 =20 + +
    + "align" Attribute + + + + + Controls whether the table appears left justified, centered = (default), + or right justified. + Tables are aligned relative to the left margin of the document. + + Allowed values: +
      +
    • "left"
      • +
    • "center" (default)
      • +
    • "right"
      • +
    +
    +
    "anchor" Attribute @@ -4563,9 +4592,6 @@ See for a = description of how to deal with is
  • <bcp14> elements ()
    • -
  • - - <br> elements ()
  • <cref> elements ()
    • @@ -4743,9 +4769,6 @@ See for a = description of how to deal with is
  • <bcp14> elements ()
    • -
  • - - <br> elements ()
  • <cref> elements ()
    • @@ -7118,7 +7141,7 @@ namespace a =3D = "http://relaxng.org/ns/compatibility/annotations/1.0" attribute xml:lang { text }?, attribute anchor { xsd:ID }?, attribute pn { text }?, - ((artwork | dl | figure | ol | sourcecode | t | ul)+ + ((artwork | blockquote | dl | figure | ol | sourcecode | t | ul)+ | (text | bcp14 | cref @@ -7141,7 +7164,8 @@ namespace a =3D = "http://relaxng.org/ns/compatibility/annotations/1.0" [ a:defaultValue =3D "normal" ] attribute spacing { "normal" | "compact" }?, [ a:defaultValue =3D "true" ] - attribute hanging { "false" | "true" }?, + attribute newline { "false" | "true" }?, + [ a:defaultValue =3D "0" ] attribute indent { text }?, attribute pn { text }?, (dt, dd)+ } @@ -7372,6 +7396,8 @@ namespace a =3D = "http://relaxng.org/ns/compatibility/annotations/1.0" element table { attribute xml:base { text }?, attribute xml:lang { text }?, + [ a:defaultValue =3D "center" ] + attribute align { "left" | "center" | "right" }?, attribute anchor { xsd:ID }?, attribute pn { text }?, name?, @@ -7478,7 +7504,6 @@ include "svg.rnc" ((artwork | dl | figure | ol | sourcecode | t | ul)+ | (text | bcp14 - | br | cref | em | eref @@ -7503,7 +7528,6 @@ include "svg.rnc" ((artwork | dl | figure | ol | sourcecode | t | ul)+ | (text | bcp14 - | br | cref | em | eref @@ -7566,13 +7590,6 @@ include "svg.rnc" text } =20 -br =3D - element br { - attribute xml:base { text }?, - attribute xml:lang { text }?, - empty - } - back =3D element back { attribute xml:base { text }?, @@ -8103,7 +8120,8 @@ to the v3 schema. + attribute xml:lang { text }?, + attribute anchor { xsd:ID }?, + attribute pn { text }?, -+ ((artwork | dl | figure | ol | sourcecode | t | ul)+ ++ ((artwork | blockquote | dl | figure | ol | sourcecode | t |=20 ++ ul)+ + | (text + | bcp14 + | cref @@ -8125,7 +8143,8 @@ to the v3 schema. + [ a:defaultValue =3D "normal" ] + attribute spacing { "normal" | "compact" }?, + [ a:defaultValue =3D "true" ] -+ attribute hanging { "false" | "true" }?, ++ attribute newline { "false" | "true" }?, ++ [ a:defaultValue =3D "0" ] attribute indent { text }?, + attribute pn { text }?, + (dt, dd)+ + } @@ -8347,6 +8366,8 @@ to the v3 schema. + element table { + attribute xml:base { text }?, + attribute xml:lang { text }?, ++ [ a:defaultValue =3D "center" ] ++ attribute align { "left" | "center" | "right" }?, + attribute anchor { xsd:ID }?, + attribute pn { text }?, + name?, @@ -8450,7 +8471,6 @@ to the v3 schema. + ((artwork | dl | figure | ol | sourcecode | t | ul)+ + | (text + | bcp14 -+ | br + | cref + | em + | eref @@ -8474,7 +8494,6 @@ to the v3 schema. + ((artwork | dl | figure | ol | sourcecode | t | ul)+ + | (text + | bcp14 -+ | br + | cref + | em + | eref @@ -8534,12 +8553,6 @@ to the v3 schema. } - c =3D element c { (text | xref | eref | iref | cref | spanx)* } - back =3D element back { references*, section* } -+ br =3D -+ element br { -+ attribute xml:base { text }?, -+ attribute xml:lang { text }?, -+ empty -+ } + back =3D + element back { + attribute xml:base { text }?, --Apple-Mail=_5C2BB37C-02D0-48CB-8E70-8B893DE02120 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAxOTE4MDA0M1owIwYJKoZIhvcNAQkEMRYEFJAK1Olr5JkPNCfo0Ep35IsmK2iSMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQBPF83Jut4h/5RG4IEVCIX30GbjFxyg3kuAPIiNVPKg32tBI3GEM6woa2Iy/suBEYHaMdPb oAke4f4deJrF13v7m2n6h1oRMxs/kdIewMQO6JL9/d384aiSRgm6MXHnDoycVIwl8u2hCyCejIVl jESxPnUM5xIeabt6/lP++35FtsMuWrOnrQh7SDDewUNDUEOO64XmXo6joB4RII4mZdINLbjcSFOz H8dNseA0EHBcw9iZ7mVlpNwhhzJUKzSbe3A0M3WNQGCUmTcwzfe54Ea2UfwoXD/lE7UsKi997C1j iRonGeAjasmcKafOVRy70OMOaF/7qSIiHg31Uk/nAAepAAAAAAAA --Apple-Mail=_5C2BB37C-02D0-48CB-8E70-8B893DE02120-- From nobody Fri Oct 19 18:33:10 2018 Return-Path: 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 9BE9B130E01 for ; Fri, 19 Oct 2018 18:33: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 HqbUBBod9Iiw for ; Fri, 19 Oct 2018 18:33: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 7BD11130DE7 for ; Fri, 19 Oct 2018 18:33:07 -0700 (PDT) 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 Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 19 Oct 2018 18:33:05 -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; Fri, 19 Oct 2018 18:33:05 -0700 From: Paul Hoffman To: Henrik Levkowetz CC: Jim Schaad , Heather Flanagan , "xml2rfc-dev@ietf.org" Thread-Topic: [Ext] [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, In Section 2.54, Thread-Index: AQHUaBTZuPxGuz8mPkGpbuZ+7Nn5JA== Date: Sat, 20 Oct 2018 01:33:05 +0000 Message-ID: <2061F6E4-3DF8-4C60-BB35-AB52FCD98EB1@icann.org> References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> <050c01d45d97$714e51b0$53eaf510$@augustcellars.com> <052b01d45daa$87e71980$97b54c80$@augustcellars.com> <656afb2e-3aa7-53c5-5e39-55050387aa20@levkowetz.com> <0bac2940-1abc-87e3-35e7-f6d621e83f1c@rfc-editor.org> <073e01d45ffc$fc161550$f4423ff0$@augustcellars.com> In-Reply-To: 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=_03740569-7E7E-490C-8A74-3A639B24DB08"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #31: Schema Issue, RFC 7991, In Section 2.54,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2018 01:33:10 -0000 --Apple-Mail=_03740569-7E7E-490C-8A74-3A639B24DB08 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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. On Oct 9, 2018, at 11:26 AM, Henrik Levkowetz = wrote: >=20 >=20 >=20 > On 2018-10-09 20:22, Jim Schaad wrote: >>=20 >>> -----Original Message----- >>> From: xml2rfc-dev On Behalf Of = Heather >>> Flanagan >>> Sent: Tuesday, October 9, 2018 11:01 AM >>> To: xml2rfc-dev@ietf.org >>> Subject: Re: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC = 7991, In >>> Section 2.54,
    >>>=20 >>>=20 >>> On 10/6/18 2:53 PM, Henrik Levkowetz wrote: >>>> 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. >>>>>> Till now, both have been centered. That can be changed. >>>>>>=20 >>>>> 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. >>>>=20 >>>=20 >>> I'm not entirely sure how this issue differs from the table = alignment >> discussed >>> in issues 40 and 9? >>=20 >> The first was where do you place the table on the page. This one is = how do >> you place the caption in the table. >=20 > 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
    as = well? --Paul= --Apple-Mail=_03740569-7E7E-490C-8A74-3A639B24DB08 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAyMDAxMzMwNVowIwYJKoZIhvcNAQkEMRYEFGR3bmnp6hRebTtL8hcFnIoiZaTpMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQCnwPmdxDk9oxAyGpObC7fGKGEJ/UW7DvyOnwqdSF9aSuyCwUR1pV4Jngg8LPNG1xEhEgqa MHy5JG3SAPe1OqowqzHMjN75d/XXVHUEk+Cx23/srq/buU1N4Vlvr6+3GPyg3vSBxbNln+vsmRc9 P6Ha3zZphbScqJsn8Zi1uLbxg0lv38ot+04mLc6pKCYSE3Er/qcZFHhACuBtolm2hQ1YAtqNYIcw IYt4YXOsXdw6t2AMbpVVcWwjcr7pZdguZCXbTWnMIYCoTv9YHTFgBsgp9BAads2O+LLSjzSJ75XS fHBb0j8gfQXkirbVfjUOiXFLq7bf4zGHG70BvXhbq5lKAAAAAAAA --Apple-Mail=_03740569-7E7E-490C-8A74-3A639B24DB08-- From nobody Fri Oct 19 20:50:18 2018 Return-Path: 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 C8BED1271FF for ; Fri, 19 Oct 2018 20:50:14 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 znhBkCbgv3Z6 for ; Fri, 19 Oct 2018 20:50:11 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F69D127133 for ; Fri, 19 Oct 2018 20:50:10 -0700 (PDT) Received: from Jude (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 19 Oct 2018 20:45:21 -0700 From: Jim Schaad To: 'Paul Hoffman' , 'Henrik Levkowetz' CC: 'Heather Flanagan' , References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> <050c01d45d97$714e51b0$53eaf510$@augustcellars.com> <052b01d45daa$87e71980$97b54c80$@augustcellars.com> <656afb2e-3aa7-53c5-5e39-55050387aa20@levkowetz.com> <0bac2940-1abc-87e3-35e7-f6d621e83f1c@rfc-editor.org> <073e01d45ffc$fc161550$f4423ff0$@augustcellars.com> <2061F6E4-3DF8-4C60-BB35-AB52FCD98EB1@icann.org> In-Reply-To: <2061F6E4-3DF8-4C60-BB35-AB52FCD98EB1@icann.org> Date: Fri, 19 Oct 2018 20:50:01 -0700 Message-ID: <013601d46827$fc2b0cc0$f4812640$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKlc/I8qUpx6H6sTpIQv3vHmEIb5gGMQXb8AverSrcCvXax5QHGvedgAOtPwScCpgcF3ADkS5KAAqj1aRQB/yc3qAHvHWwdAnFKOwwCPeYpeAHzzxMrAbzXacsBRDvT8gLkbZkKAhhsP1UCsZlHM6JaK7sQ Content-Language: en-us X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #31: Schema Issue, RFC 7991, In Section 2.54,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2018 03:50:15 -0000 > -----Original Message----- > From: Paul Hoffman > Sent: Friday, October 19, 2018 6:33 PM > To: Henrik Levkowetz > Cc: Jim Schaad ; Heather Flanagan editor.org>; xml2rfc-dev@ietf.org > Subject: Re: [Ext] [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, In > Section 2.54,
    > > 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. > > > On Oct 9, 2018, at 11:26 AM, Henrik Levkowetz > wrote: > > > > > > > > On 2018-10-09 20:22, Jim Schaad wrote: > >> > >>> -----Original Message----- > >>> From: xml2rfc-dev On Behalf Of Heather > >>> Flanagan > >>> Sent: Tuesday, October 9, 2018 11:01 AM > >>> To: xml2rfc-dev@ietf.org > >>> Subject: Re: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, In > >>> Section 2.54,
    > >>> > >>> > >>> On 10/6/18 2:53 PM, Henrik Levkowetz wrote: > >>>> 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. > >>>>>> Till now, both have been centered. That can be changed. > >>>>>> > >>>>> 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. > >>>> > >>> > >>> I'm not entirely sure how this issue differs from the table alignment > >> 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. > > > > 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". I think that this is just text and no new attributes. "The caption will appear centered and the same width as the table." Jim > > If the latter, should this same new attribute be added to
    as well? > > --Paul From nobody Fri Oct 19 20:52:11 2018 Return-Path: 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 604CC130E23 for ; Fri, 19 Oct 2018 20:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 WrKLlzq9YgjO for ; Fri, 19 Oct 2018 20:52:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 991291271FF for ; Fri, 19 Oct 2018 20:52:06 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:50307 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1gDiJ2-0000Be-Nr; Fri, 19 Oct 2018 20:52:05 -0700 To: Paul Hoffman References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> <050c01d45d97$714e51b0$53eaf510$@augustcellars.com> <052b01d45daa$87e71980$97b54c80$@augustcellars.com> <656afb2e-3aa7-53c5-5e39-55050387aa20@levkowetz.com> <0bac2940-1abc-87e3-35e7-f6d621e83f1c@rfc-editor.org> <073e01d45ffc$fc161550$f4423ff0$@augustcellars.com> <2061F6E4-3DF8-4C60-BB35-AB52FCD98EB1@icann.org> Cc: Jim Schaad , Heather Flanagan , "xml2rfc-dev@ietf.org" From: Henrik Levkowetz Message-ID: <4d46965d-dde8-8143-9252-739c8500fd8a@levkowetz.com> Date: Sat, 20 Oct 2018 05:51:56 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2061F6E4-3DF8-4C60-BB35-AB52FCD98EB1@icann.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="p9dAHTdEnvRveHjmfI1UefjHigTO30cR1" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, rse@rfc-editor.org, ietf@augustcellars.com, paul.hoffman@icann.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #31: Schema Issue, RFC 7991, In Section 2.54,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2018 03:52:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --p9dAHTdEnvRveHjmfI1UefjHigTO30cR1 Content-Type: multipart/mixed; boundary="S1JDTp23IRbKGroShd4eDGwsHoQsspV3M"; protected-headers="v1" From: Henrik Levkowetz To: Paul Hoffman Cc: Jim Schaad , Heather Flanagan , "xml2rfc-dev@ietf.org" Message-ID: <4d46965d-dde8-8143-9252-739c8500fd8a@levkowetz.com> Subject: Re: [Ext] [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, In Section 2.54,
    References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> <050c01d45d97$714e51b0$53eaf510$@augustcellars.com> <052b01d45daa$87e71980$97b54c80$@augustcellars.com> <656afb2e-3aa7-53c5-5e39-55050387aa20@levkowetz.com> <0bac2940-1abc-87e3-35e7-f6d621e83f1c@rfc-editor.org> <073e01d45ffc$fc161550$f4423ff0$@augustcellars.com> <2061F6E4-3DF8-4C60-BB35-AB52FCD98EB1@icann.org> In-Reply-To: <2061F6E4-3DF8-4C60-BB35-AB52FCD98EB1@icann.org> --S1JDTp23IRbKGroShd4eDGwsHoQsspV3M Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-10-20 03:33, Paul Hoffman wrote: > 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. >=20 >=20 > On Oct 9, 2018, at 11:26 AM, Henrik Levkowetz wr= ote: >>=20 >>=20 >>=20 >> On 2018-10-09 20:22, Jim Schaad wrote: >>>=20 >>>> -----Original Message----- >>>> From: xml2rfc-dev On Behalf Of Heathe= r >>>> Flanagan >>>> Sent: Tuesday, October 9, 2018 11:01 AM >>>> To: xml2rfc-dev@ietf.org >>>> Subject: Re: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 799= 1, In >>>> Section 2.54,
    >>>>=20 >>>>=20 >>>> On 10/6/18 2:53 PM, Henrik Levkowetz wrote: >>>>> 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 figur= es >>>>>>>> and tables. >>>>>>> Till now, both have been centered. That can be changed. >>>>>>>=20 >>>>>> 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 e= dge >>>>>> 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. >>>>>=20 >>>>=20 >>>> I'm not entirely sure how this issue differs from the table alignmen= t >>> discussed >>>> in issues 40 and 9? >>>=20 >>> The first was where do you place the table on the page. This one is = how do >>> you place the caption in the table. >>=20 >> Much more succinct than my reply :-) >=20 > 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". The caption will be centred under the table, and the combined table and caption will be aligned according to the 'align' attribute on
    . Henrik >=20 > If the latter, should this same new attribute be added to
    as > well? >=20 > --Paul >=20 --S1JDTp23IRbKGroShd4eDGwsHoQsspV3M-- --p9dAHTdEnvRveHjmfI1UefjHigTO30cR1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlvKplwACgkQTptXS4+7 FxpXQxAA1ZZgTXgje8XWg6KaR6GwYRZ/82bZj4uUpeVnbb4CiEZ0+VDu7b8BFUD5 +ytMlwE9Y4HzlewwWSu+L2+2XVMXX8ptGKFxSD9TNvGdIydhq3zgbVxzOAOWFh4x qn/6XPx1TRi8/89Q2cnWQmLqgGtG9q54XPyArpXYJrMcec50Z+6WHADTEAryMXAA TRvof1OqY2Dvm59EaIj7hQqNSDux0CTMURP6h1FNCDij5FCJ+Lb2xrha7Ru1MH+J a2u1k9PizJBHP64BWo8ufmaNXCR2L2qQ7AlTi9egGBJC8HbfEFXDV6T4xLGbRwlJ 6uruTPmMQjp+bAMd99iRuvMYIHKCxVzR04eUj0lhn2r6RM4qtHlA6uhB/zEj7cbd 6erJPwqaFHfrHUEJ78/9OGCfYqpjO+ehfgny09kYCXe0pVGoYLwrjGYjLXhTOTbL SRUbWjQpNyK2mSTpYBC//VloGA3Ac8d0IN0Qx11gGCLFwbgneZUBYlvswHQ00PkV 14z7ORzFj344KALRMLckYX9CLOSz9SgbE26yQy8pfBbEa3vY/scR1o/gt25jvKfZ 9vBiEzGQJKTZcMbMmjNtblWxbtRSJ7lznaYy0zBTay0NYIIJY+DA4YUr19gIRIqh FKdU1shqbotMw1ZnxgE0fDWa9VCkol/d5iIvyhw8qhmrG7KKfYY= =eALR -----END PGP SIGNATURE----- --p9dAHTdEnvRveHjmfI1UefjHigTO30cR1-- From nobody Fri Oct 19 20:54:15 2018 Return-Path: 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 C9D2A130E23 for ; Fri, 19 Oct 2018 20:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 PHZIfDhpa9Ha for ; Fri, 19 Oct 2018 20:54:12 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19F26127133 for ; Fri, 19 Oct 2018 20:54:12 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:50310 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1gDiL5-0007eH-4u; Fri, 19 Oct 2018 20:54:11 -0700 To: Jim Schaad , 'Paul Hoffman' References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> <050c01d45d97$714e51b0$53eaf510$@augustcellars.com> <052b01d45daa$87e71980$97b54c80$@augustcellars.com> <656afb2e-3aa7-53c5-5e39-55050387aa20@levkowetz.com> <0bac2940-1abc-87e3-35e7-f6d621e83f1c@rfc-editor.org> <073e01d45ffc$fc161550$f4423ff0$@augustcellars.com> <2061F6E4-3DF8-4C60-BB35-AB52FCD98EB1@icann.org> <013601d46827$fc2b0cc0$f4812640$@augustcellars.com> Cc: 'Heather Flanagan' , xml2rfc-dev@ietf.org From: Henrik Levkowetz Message-ID: <967ba0b0-3f72-028b-c050-015184394861@levkowetz.com> Date: Sat, 20 Oct 2018 05:54:03 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <013601d46827$fc2b0cc0$f4812640$@augustcellars.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XPaGnWeD0wDvAui6VJDWkeVb9HXkgneqe" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, rse@rfc-editor.org, paul.hoffman@icann.org, ietf@augustcellars.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #31: Schema Issue, RFC 7991, In Section 2.54,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2018 03:54:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XPaGnWeD0wDvAui6VJDWkeVb9HXkgneqe Content-Type: multipart/mixed; boundary="7uQMTjmRaOTANp4STO8InRioXicBPioBP"; protected-headers="v1" From: Henrik Levkowetz To: Jim Schaad , 'Paul Hoffman' Cc: 'Heather Flanagan' , xml2rfc-dev@ietf.org Message-ID: <967ba0b0-3f72-028b-c050-015184394861@levkowetz.com> Subject: Re: [Ext] [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, In Section 2.54,
    References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> <050c01d45d97$714e51b0$53eaf510$@augustcellars.com> <052b01d45daa$87e71980$97b54c80$@augustcellars.com> <656afb2e-3aa7-53c5-5e39-55050387aa20@levkowetz.com> <0bac2940-1abc-87e3-35e7-f6d621e83f1c@rfc-editor.org> <073e01d45ffc$fc161550$f4423ff0$@augustcellars.com> <2061F6E4-3DF8-4C60-BB35-AB52FCD98EB1@icann.org> <013601d46827$fc2b0cc0$f4812640$@augustcellars.com> In-Reply-To: <013601d46827$fc2b0cc0$f4812640$@augustcellars.com> --7uQMTjmRaOTANp4STO8InRioXicBPioBP Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jim, On 2018-10-20 05:50, Jim Schaad wrote: >=20 >=20 >> -----Original Message----- >> From: Paul Hoffman >> Sent: Friday, October 19, 2018 6:33 PM >> To: Henrik Levkowetz >> Cc: Jim Schaad ; Heather Flanagan > editor.org>; xml2rfc-dev@ietf.org >> Subject: Re: [Ext] [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC= > 7991, In >> Section 2.54,
    >>=20 >> 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. >>=20 >>=20 >> On Oct 9, 2018, at 11:26 AM, Henrik Levkowetz >> wrote: >> > >> > >> > >> > On 2018-10-09 20:22, Jim Schaad wrote: >> >> >> >>> -----Original Message----- >> >>> From: xml2rfc-dev On Behalf Of Heat= her >> >>> Flanagan >> >>> Sent: Tuesday, October 9, 2018 11:01 AM >> >>> To: xml2rfc-dev@ietf.org >> >>> Subject: Re: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7= 991, > In >> >>> Section 2.54,
    >> >>> >> >>> >> >>> On 10/6/18 2:53 PM, Henrik Levkowetz wrote: >> >>>> 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 fig= ures >> >>>>>>> and tables. >> >>>>>> Till now, both have been centered. That can be changed. >> >>>>>> >> >>>>> No, I would not change this. I would keep the centering for the= >> >>>>> caption. The next interesting question the caption is wider tha= n > 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 curre= nt >> >>>> code wraps the title to fit within the table width. >> >>>> >> >>> >> >>> I'm not entirely sure how this issue differs from the table alignm= ent >> >> discussed >> >>> in issues 40 and 9? >> >> >> >> The first was where do you place the table on the page. This one i= s > how do >> >> you place the caption in the table. >> > >> > Much more succinct than my reply :-) >>=20 >> 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". >=20 > I think that this is just text and no new attributes. "The caption wil= l > 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 th= e same width as the table. Best regards, Henrik --7uQMTjmRaOTANp4STO8InRioXicBPioBP-- --XPaGnWeD0wDvAui6VJDWkeVb9HXkgneqe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlvKptsACgkQTptXS4+7 FxpQBw/9HgOfPUquFuYOXAkdoXvWTJ261roGFMWPrcdRSHbdgbXNQO6KWInDzbpW rGHjuu244v30Ei+3tIIAYp9YC/JDTk1+BU2xZaQCERofJzv82008lEO/n+/PHf6R VbPGVjT0BHNBFlxoJullZXbjzpgb0MSV8fsjGaQo/t7rZ61hb5XPpNI2WMbhRdER twagPjZOhgEcurv6hy0SfXBgwjCPgDCyuOCRQRKmO8gMDQsONlNtXVf17LwLKVqq wKvkCPLq+GCI1NyZle1EpcSzlwYY8YfRJBHeVx1jJyBpL15QdAegTkw9h+x3kM8T GPTJpV70Xc9K5s06uZqU7DuDyjvJqCQpm7UQ7biFr6PooUtlz/DfYJPvcFMiHznr k/qPkujoUWrDu9XXGUTKTSLcEFnYz3q3SLcc5qEa7imeBD/0Ynbq7QcNoTdVaTBI bbvLH+NXe2e8zgVGOUUT1MPQld+G2FuM7Ma/y9fdDouNRhmbYeGLbf9a8caHfrON DuO/63LOc/E3ydqQQs2jvJtixfkpa5foJ582Jx3vh5UdA0TSHy/C9bUabSSGJ33q oRJZZqUkuiEuKhqi3qn5Ep8DQpvbG4dwYeAkUMay/Fkq86Lkdxk0DD5bPwWPR6G+ tjJ14ayfdaMLwK7X66JsbziiixLOcy8p4RaCoByLzXu6RC5CWDg= =4iDa -----END PGP SIGNATURE----- --XPaGnWeD0wDvAui6VJDWkeVb9HXkgneqe-- From nobody Fri Oct 19 21:13:45 2018 Return-Path: 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 14E96130E29 for ; Fri, 19 Oct 2018 21:13:44 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 q-pHFHqy2EAY for ; Fri, 19 Oct 2018 21:13:42 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02FC3130E25 for ; Fri, 19 Oct 2018 21:13:42 -0700 (PDT) Received: from Jude (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 19 Oct 2018 21:08:54 -0700 From: Jim Schaad To: 'Henrik Levkowetz' , 'Paul Hoffman' CC: 'Heather Flanagan' , References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> <050c01d45d97$714e51b0$53eaf510$@augustcellars.com> <052b01d45daa$87e71980$97b54c80$@augustcellars.com> <656afb2e-3aa7-53c5-5e39-55050387aa20@levkowetz.com> <0bac2940-1abc-87e3-35e7-f6d621e83f1c@rfc-editor.org> <073e01d45ffc$fc161550$f4423ff0$@augustcellars.com> <2061F6E4-3DF8-4C60-BB35-AB52FCD98EB1@icann.org> <013601d46827$fc2b0cc0$f4812640$@augustcellars.com> <967ba0b0-3f72-028b-c050-015184394861@levkowetz.com> In-Reply-To: <967ba0b0-3f72-028b-c050-015184394861@levkowetz.com> Date: Fri, 19 Oct 2018 21:13:34 -0700 Message-ID: <014501d4682b$464f1fa0$d2ed5ee0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKlc/I8qUpx6H6sTpIQv3vHmEIb5gL3q0q3Ar12seUBxr3nYADrT8EnAqYHBdwA5EuSgAKo9WkUAf8nN6gB7x1sHQJxSjsMAj3mKXgB888TKwG812nLAUQ70/IC5G2ZCgIYbD9VArGZRzMCchLzIwIQSEDAokKBi8A= Content-Language: en-us X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #31: Schema Issue, RFC 7991, In Section 2.54,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2018 04:13:44 -0000 > -----Original Message----- > From: Henrik Levkowetz > Sent: Friday, October 19, 2018 8:54 PM > To: Jim Schaad ; 'Paul Hoffman' > > Cc: 'Heather Flanagan' ; xml2rfc-dev@ietf.org > Subject: Re: [Ext] [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC = 7991, In > Section 2.54,
    >=20 > Hi Jim, >=20 > On 2018-10-20 05:50, Jim Schaad wrote: > > > > > >> -----Original Message----- > >> From: Paul Hoffman > >> Sent: Friday, October 19, 2018 6:33 PM > >> To: Henrik Levkowetz > >> Cc: Jim Schaad ; Heather Flanagan >> editor.org>; xml2rfc-dev@ietf.org > >> Subject: Re: [Ext] [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, > >> RFC > > 7991, In > >> Section 2.54,
    > >> > >> 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. > >> > >> > >> On Oct 9, 2018, at 11:26 AM, Henrik Levkowetz = > >> wrote: > >> > > >> > > >> > > >> > On 2018-10-09 20:22, Jim Schaad wrote: > >> >> > >> >>> -----Original Message----- > >> >>> From: xml2rfc-dev On Behalf Of > >> >>> Heather Flanagan > >> >>> Sent: Tuesday, October 9, 2018 11:01 AM > >> >>> To: xml2rfc-dev@ietf.org > >> >>> Subject: Re: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, = RFC > >> >>> 7991, > > In > >> >>> Section 2.54,
    > >> >>> > >> >>> > >> >>> On 10/6/18 2:53 PM, Henrik Levkowetz wrote: > >> >>>> 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. > >> >>>>>> Till now, both have been centered. That can be changed. > >> >>>>>> > >> >>>>> 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. > >> >>>> > >> >>> > >> >>> I'm not entirely sure how this issue differs from the table > >> >>> alignment > >> >> 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. > >> > > >> > 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". > > > > I think that this is just text and no new attributes. "The caption > > will appear centered and the same width as the table." >=20 > 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 >=20 > Best regards, >=20 > Henrik >=20 From nobody Sat Oct 20 08:55:43 2018 Return-Path: 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 BB557130E63 for ; Sat, 20 Oct 2018 08:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 DODzgteLIesx for ; Sat, 20 Oct 2018 08:55:40 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20CEC12D4EB for ; Sat, 20 Oct 2018 08:55:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id A067D1CA42E; Sat, 20 Oct 2018 08:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7cn5bMbmuP3; Sat, 20 Oct 2018 08:55:01 -0700 (PDT) Received: from Heathers-MacBook-Pro-2.local (unknown [38.132.111.105]) by c8a.amsl.com (Postfix) with ESMTPSA id E309C1C6297; Sat, 20 Oct 2018 08:54:56 -0700 (PDT) To: Henrik Levkowetz , Paul Hoffman Cc: Jim Schaad , "xml2rfc-dev@ietf.org" References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> <050c01d45d97$714e51b0$53eaf510$@augustcellars.com> <052b01d45daa$87e71980$97b54c80$@augustcellars.com> <656afb2e-3aa7-53c5-5e39-55050387aa20@levkowetz.com> <0bac2940-1abc-87e3-35e7-f6d621e83f1c@rfc-editor.org> <073e01d45ffc$fc161550$f4423ff0$@augustcellars.com> <2061F6E4-3DF8-4C60-BB35-AB52FCD98EB1@icann.org> <4d46965d-dde8-8143-9252-739c8500fd8a@levkowetz.com> From: Heather Flanagan Message-ID: Date: Sat, 20 Oct 2018 08:55:26 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <4d46965d-dde8-8143-9252-739c8500fd8a@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #31: Schema Issue, RFC 7991, In Section 2.54,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2018 15:55:42 -0000 On 10/19/18 8:51 PM, Henrik Levkowetz wrote: > > On 2018-10-20 03:33, Paul Hoffman wrote: >> 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. >> >> >> On Oct 9, 2018, at 11:26 AM, Henrik Levkowetz wrote: >>> >>> >>> On 2018-10-09 20:22, Jim Schaad wrote: >>>>> -----Original Message----- >>>>> From: xml2rfc-dev On Behalf Of Heather >>>>> Flanagan >>>>> Sent: Tuesday, October 9, 2018 11:01 AM >>>>> To: xml2rfc-dev@ietf.org >>>>> Subject: Re: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, In >>>>> Section 2.54,
    >>>>> >>>>> >>>>> On 10/6/18 2:53 PM, Henrik Levkowetz wrote: >>>>>> 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. >>>>>>>> Till now, both have been centered. That can be changed. >>>>>>>> >>>>>>> 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. >>>>>> >>>>> I'm not entirely sure how this issue differs from the table alignment >>>> 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. >>> 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". > The caption will be centred under the table, and the combined table and > caption will be aligned according to the 'align' attribute on
    . Yes, this. -Heather > > Henrik > >> If the latter, should this same new attribute be added to
    as >> well? >> >> --Paul >> From nobody Tue Oct 23 05:27:49 2018 Return-Path: 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 9BAEE130EBA for ; Tue, 23 Oct 2018 05:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 A3WtWh_6mCI3 for ; Tue, 23 Oct 2018 05:27:45 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57F60130EB7 for ; Tue, 23 Oct 2018 05:27:45 -0700 (PDT) Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 81AE162899 for ; Tue, 23 Oct 2018 14:27:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1540297663; bh=VATqBj/emJ+AujiZ0TabfT2zNAHh8w+zT9o41Oc6IYE=; h=From:To:Date; b=eLqZ999KcaZpkcgN99hPjWU5bWZ/S6Ac8ZqbHshi07LhPYfV0QkPX8A6o5S1Hw02c RAeiVexs9dT1R6cyYNA0YdJcK4mwaUMLp85C2ZWbo5rbJxOnVRj3zX60Ok+nNZcCPl yxSf1APgChgFeAhVVuA5tS00BAC1Fo+Q/tpHaQHs= Message-ID: <76e598633d0fa0d476c902c017957da59976a56d.camel@nic.cz> From: Ladislav Lhotka To: xml2rfc-dev@ietf.org Date: Tue, 23 Oct 2018 14:27:43 +0200 Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: [xml2rfc-dev] element 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 12:27:48 -0000 Hi, I appreciated that xml2rfc v3 had added the element. It would also seem the right choice for the inclusion of YANG modules instead of . However, this is currently impossible because the xml2rfc tool automatically adds a markers. This interferes with the mandatory convention that is used for YANG modules, see RFC 8407, sec. 3.2: file "ietf-foo@2016-03-20.yang" module ietf-foo { namespace "urn:ietf:params:xml:ns:yang:ietf-foo"; prefix "foo"; organization "..."; contact "..."; description "..."; revision 2016-03-20 { description "Latest revision"; reference "RFC XXXX: Foo Protocol"; } // ... more statements } Given that YANG modules appear quite frequently in RFCs and I-Ds these days, it might be useful to support the above convention. One way to do this can be: - define an attribute for , for example "language", to indicate what language the source code is written in - automatically add the YANG-specific markers if the language is YANG. Thanks, Lada P.S. Sorry if this has been discussed before. -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Oct 23 06:09:32 2018 Return-Path: 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 340AA130FB7 for ; Tue, 23 Oct 2018 06:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 OdP0BlfGIHOD for ; Tue, 23 Oct 2018 06:09:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA361130DFC for ; Tue, 23 Oct 2018 06:09:14 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:59473 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1gEwQq-000725-PK; Tue, 23 Oct 2018 06:09:13 -0700 To: Ladislav Lhotka , xml2rfc-dev@ietf.org References: <76e598633d0fa0d476c902c017957da59976a56d.camel@nic.cz> From: Henrik Levkowetz Message-ID: <21390d69-63ba-d802-1b87-18a2793b1253@levkowetz.com> Date: Tue, 23 Oct 2018 15:08:58 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <76e598633d0fa0d476c902c017957da59976a56d.camel@nic.cz> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vkO0Rdj3JpienaTAeSJBjmor3RHiIxmXF" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, lhotka@nic.cz X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] element 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 13:09:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vkO0Rdj3JpienaTAeSJBjmor3RHiIxmXF Content-Type: multipart/mixed; boundary="Q1n4T9uCpmGbHGtWVSLrPwDHTT7nFdfMb"; protected-headers="v1" From: Henrik Levkowetz To: Ladislav Lhotka , xml2rfc-dev@ietf.org Message-ID: <21390d69-63ba-d802-1b87-18a2793b1253@levkowetz.com> Subject: Re: [xml2rfc-dev] element References: <76e598633d0fa0d476c902c017957da59976a56d.camel@nic.cz> In-Reply-To: <76e598633d0fa0d476c902c017957da59976a56d.camel@nic.cz> --Q1n4T9uCpmGbHGtWVSLrPwDHTT7nFdfMb Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ladislav, On 2018-10-23 14:27, Ladislav Lhotka wrote: > Hi, >=20 > I appreciated that xml2rfc v3 had added the element. It wo= uld also > seem the right choice for the inclusion of YANG modules instead of . >=20 > However, this is currently impossible because the xml2rfc tool automati= cally > adds a markers. This interferes with the mand= atory > convention that is used for YANG modules, see RFC 8407, sec. 3.2: If you add a 'name' attribute to , it will output exactly what you want: ... >=20 > file "ietf-foo@2016-03-20.yang" >=20 > module ietf-foo { > namespace "urn:ietf:params:xml:ns:yang:ietf-foo"; > prefix "foo"; > organization "..."; > contact "..."; > description "..."; > revision 2016-03-20 { > description "Latest revision"; > reference "RFC XXXX: Foo Protocol"; > } > // ... more statements > } >=20 > >=20 > Given that YANG modules appear quite frequently in RFCs and I-Ds these = days, it > might be useful to support the above convention. One way to do this can= be: >=20 > - define an attribute for , for example "language", to indi= cate > what language the source code is written in There already exists a 'type' attribute, but it's orthogonal to the expan= sion of the name attribute: ... In the next release of xml2rfc, there will also be a 'markers' attribute,= which will let you turn on and off the generation of the markers= =2E Best regards, Henrik --Q1n4T9uCpmGbHGtWVSLrPwDHTT7nFdfMb-- --vkO0Rdj3JpienaTAeSJBjmor3RHiIxmXF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlvPHWoACgkQTptXS4+7 Fxrlvg//X2NvQhLmNyxThLvjbirR0zn3HZ9MFKUH4v8zguKQvrrM5kNPoRSC3nFm yApRf0AqqF8c5SkBMKrM+6Z7nOODOMG0YgdKgZ/xnLpPMvEHSUJsUk6ZcpzP+Kfi 4sGI8+SivLb3Sdx6icG0iVWzmv85hiLmFlzej9/yhCHevArMwpadRqUaLjNjMfUg DYO6yJdDSzKHNIaQkGdzOtLi7CkS/UzdDVhq8o+Ycl5Q9dAdv1syutSNJ5b9eoUZ TzWK045pJdXsyqhIZZfplV9j8lpnCCpBfngHUaDXm8epDP+PDafxfcKgvJ664FBW trs7smPlQ0dea+x4XJeOsXnpAobwYlubUJKVe59vmegXHaeLMQ+QuNbsSsxmSMCA bTVU+X1nrWPDq4F+ZC6mbjF++D3MTA97igKZ/NnaI9qF3+RtYGbdq0ltpiLpAazI OaoFvy9hoMu2qrPPGg6OZSHd94FUSRXiLgAIFjk6IOWl5nhBDZzJMXvW47QPajE9 HB3PzIHdfHEM50ZXmwVioMKdnG03Ij11NvP1QRJ33j48ccuXZQVqJuvN90FjxtSN 5lXWKwt3PlpSnlwaAO1ZD1Lpvbd37xSWXOi8g2aoANlBALO8ckLSgFcE2oo4qcmi lb9qYtZhtV5IN3QJ50sobcMNm8U2y3yWjRvjSn4WKQ3H/Kh25Ag= =lDA/ -----END PGP SIGNATURE----- --vkO0Rdj3JpienaTAeSJBjmor3RHiIxmXF-- From nobody Tue Oct 23 06:19:53 2018 Return-Path: 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 B3168130E11 for ; Tue, 23 Oct 2018 06:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 w1sWMRWtqNqg for ; Tue, 23 Oct 2018 06:19:49 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF55130E00 for ; Tue, 23 Oct 2018 06:19:48 -0700 (PDT) Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 4520960AD3; Tue, 23 Oct 2018 15:19:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1540300786; bh=qhCDXO5MOSp8uSJYG9SS1GEFpRshLd1rsi4Vv3mlBV4=; h=From:To:Date; b=ZauuhIChXunecIUE0hZpoUi/YiqsMO0noIm/BWQ1FtUjw4h1hV/ekHxYy2pi9LVNT +DtfGJoaRA6Aif2IZ4Kl7yHLPwvk4OmHqkRlYnhpX2R2gWqu/pqmrY5XJLNsiXFBE3 sVjSUe2ngYQXceK9T7eDhoNsR2PMuWkkQW9LPruY= Message-ID: From: Ladislav Lhotka To: Henrik Levkowetz , xml2rfc-dev@ietf.org Date: Tue, 23 Oct 2018 15:19:45 +0200 In-Reply-To: <21390d69-63ba-d802-1b87-18a2793b1253@levkowetz.com> References: <76e598633d0fa0d476c902c017957da59976a56d.camel@nic.cz> <21390d69-63ba-d802-1b87-18a2793b1253@levkowetz.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [xml2rfc-dev] element 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 13:19:52 -0000 Hi Henrik, On Tue, 2018-10-23 at 15:08 +0200, Henrik Levkowetz wrote: > Hi Ladislav, > > On 2018-10-23 14:27, Ladislav Lhotka wrote: > > Hi, > > > > I appreciated that xml2rfc v3 had added the element. It would > > also > > seem the right choice for the inclusion of YANG modules instead of > > . > > > > However, this is currently impossible because the xml2rfc tool automatically > > adds a markers. This interferes with the mandatory > > convention that is used for YANG modules, see RFC 8407, sec. 3.2: > > If you add a 'name' attribute to , it will output exactly > what you want: > > > ... > It is not clear from RFC 7991 that the "name" attribute should result in this. > > > file "ietf-foo@2016-03-20.yang" > > > > module ietf-foo { > > namespace "urn:ietf:params:xml:ns:yang:ietf-foo"; > > prefix "foo"; > > organization "..."; > > contact "..."; > > description "..."; > > revision 2016-03-20 { > > description "Latest revision"; > > reference "RFC XXXX: Foo Protocol"; > > } > > // ... more statements > > } > > > > > > > > Given that YANG modules appear quite frequently in RFCs and I-Ds these days, > > it > > might be useful to support the above convention. One way to do this can be: > > > > - define an attribute for , for example "language", to indicate > > what language the source code is written in > > There already exists a 'type' attribute, but it's orthogonal to the expansion > of the name attribute: Oh, sorry, I missed this. > > > ... > > > In the next release of xml2rfc, there will also be a 'markers' attribute, > which will let you turn on and off the generation of the markers. Yes, that's useful. Thanks, Lada > > > Best regards, > > Henrik > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Oct 23 07:39:38 2018 Return-Path: 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 6D9BB130F91 for ; Tue, 23 Oct 2018 07:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 m_N9SGl43xmH for ; Tue, 23 Oct 2018 07:39:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877EC12D7F8 for ; Tue, 23 Oct 2018 07:39:30 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:59855 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1gExqB-0000FJ-TJ; Tue, 23 Oct 2018 07:39:28 -0700 To: Ladislav Lhotka , xml2rfc-dev@ietf.org References: <76e598633d0fa0d476c902c017957da59976a56d.camel@nic.cz> <21390d69-63ba-d802-1b87-18a2793b1253@levkowetz.com> From: Henrik Levkowetz Message-ID: <1fcf9a62-80a0-2c06-428a-139f3abb5ab5@levkowetz.com> Date: Tue, 23 Oct 2018 16:39:17 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="as4QIPLsIaDSnxeW7bdIOit42oNjUKjVc" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, lhotka@nic.cz X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] element 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 14:39:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --as4QIPLsIaDSnxeW7bdIOit42oNjUKjVc Content-Type: multipart/mixed; boundary="JxLi3n3r5e7QjaXjW2KaN1wflagwpwFu0"; protected-headers="v1" From: Henrik Levkowetz To: Ladislav Lhotka , xml2rfc-dev@ietf.org Message-ID: <1fcf9a62-80a0-2c06-428a-139f3abb5ab5@levkowetz.com> Subject: Re: [xml2rfc-dev] element References: <76e598633d0fa0d476c902c017957da59976a56d.camel@nic.cz> <21390d69-63ba-d802-1b87-18a2793b1253@levkowetz.com> In-Reply-To: --JxLi3n3r5e7QjaXjW2KaN1wflagwpwFu0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ladislav, On 2018-10-23 15:19, Ladislav Lhotka wrote: > Hi Henrik, >=20 > On Tue, 2018-10-23 at 15:08 +0200, Henrik Levkowetz wrote: >> Hi Ladislav, >>=20 >> On 2018-10-23 14:27, Ladislav Lhotka wrote: >> > Hi, >> >=20 >> > I appreciated that xml2rfc v3 had added the element. It= would >> > also >> > seem the right choice for the inclusion of YANG modules instead of >> > . >> >=20 >> > However, this is currently impossible because the xml2rfc tool autom= atically >> > adds a markers. This interferes with the m= andatory >> > convention that is used for YANG modules, see RFC 8407, sec. 3.2: >>=20 >> If you add a 'name' attribute to , it will output exactly >> what you want: >>=20 >> >> ... >> >=20 > It is not clear from RFC 7991 that the "name" attribute should result i= n this. Correct. If you're using the --v3 output of xml2rfc at this point in time, you might want to be familiar with the issues I've found while implementing RFC 7991: https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-not= es-04 I'll be adding some more information about the expansion of "name" and th= e use of "markers" there in the next revision, too. Best regards, Henrik >>=20 >> > file "ietf-foo@2016-03-20.yang" >> >=20 >> > module ietf-foo { >> > namespace "urn:ietf:params:xml:ns:yang:ietf-foo"; >> > prefix "foo"; >> > organization "..."; >> > contact "..."; >> > description "..."; >> > revision 2016-03-20 { >> > description "Latest revision"; >> > reference "RFC XXXX: Foo Protocol"; >> > } >> > // ... more statements >> > } >> >=20 >> > >> >=20 >> > Given that YANG modules appear quite frequently in RFCs and I-Ds the= se days, >> > it >> > might be useful to support the above convention. One way to do this = can be: >> >=20 >> > - define an attribute for , for example "language", to i= ndicate >> > what language the source code is written in >>=20 >> There already exists a 'type' attribute, but it's orthogonal to the ex= pansion >> of the name attribute: >=20 > Oh, sorry, I missed this. >=20 >>=20 >> >> ... >> >>=20 >> In the next release of xml2rfc, there will also be a 'markers' attribu= te, >> which will let you turn on and off the generation of the mark= ers. >=20 > Yes, that's useful. >=20 > Thanks, Lada >=20 >>=20 >>=20 >> Best regards, >>=20 >> Henrik >>=20 >=20 --JxLi3n3r5e7QjaXjW2KaN1wflagwpwFu0-- --as4QIPLsIaDSnxeW7bdIOit42oNjUKjVc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlvPMpUACgkQTptXS4+7 Fxrt8Q/8C945RwpqAQ3UZA7A1+LykHisfZwlREWxVxYo8t9t/aKf4jhY/oc9sKJ5 5Um26UV6hlFPvRJQWkyofQQX3gdhMM0tMbpjoY7bisOfwVBU8xuTI2bM4xTYji2X LDdpPCqt7iah5MXU4dxYPuxf5zlba2Vv/xLT/uxfd4BUmi3VOM7LVeB6aJNlAgXd q4EfAgRvg5NtnNK2TPBMfzR1o4lyesQglwZqFHlKQ7OciQyBKBCLmq3Jl2lYOihu FUg1LliqD9AN5wbFI2gDtHiBiMJueBQKkFWLAIoMkqDsoMUqAR7XKKL9bKrUHRcc AsnUMnidymck6d/7pX5tqRb3RhgGo1nWnyAdxfH9Rf3ySTiqyegF7C/kvU4Wxk9v ZIj9my2oJ8zQs5VDeBildMRCG5amEzxd/Wn3WENhl03OVEtv48M9edrMZ9EvaFb7 nXVLTAN/z3R0ae4m/Y8xR6Om14vy6VVHfspDpmkbB2LK7mmYysWI4l4Cp4bwINkh kqZu+qSc6CThA/SsVk2sZXyCkW0jhvfe8LC7wVuJcOMIpl64EGu+E76aJYSHI9x/ Tsu+fn5Rm/0oPi1M+GiU5WXoxnUqOQDpTBNO2/F44wTZr1XMmzlgTXlHbO+8A50D zZEFciWSwWlFjZVeJhWwN4Q+1vtAqMUYZsTefJaI6Hrump4Kihg= =f+vb -----END PGP SIGNATURE----- --as4QIPLsIaDSnxeW7bdIOit42oNjUKjVc-- From nobody Tue Oct 23 08:09:07 2018 Return-Path: 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 2BCED130E5D for ; Tue, 23 Oct 2018 08:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 i9omQ4HuRzha for ; Tue, 23 Oct 2018 08:09:04 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5EE4130DF0 for ; Tue, 23 Oct 2018 08:08:56 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:60112 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1gEyIg-0003jx-U4 for xml2rfc-dev@ietf.org; Tue, 23 Oct 2018 08:08:55 -0700 References: <154030702132.31409.2403318721299599147.idtracker@ietfa.amsl.com> To: XML Developer List From: Henrik Levkowetz X-Forwarded-Message-Id: <154030702132.31409.2403318721299599147.idtracker@ietfa.amsl.com> Message-ID: <87699400-a99b-368f-2b17-59b2a0ff4e30@levkowetz.com> Date: Tue, 23 Oct 2018 17:08:47 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <154030702132.31409.2403318721299599147.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dNho4cpwJw2ORgglpJ6pO69jABwufO21u" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc-dev] Fwd: New Version Notification for draft-levkowetz-xml2rfc-v3-implementation-notes-05.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 15:09:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dNho4cpwJw2ORgglpJ6pO69jABwufO21u Content-Type: multipart/mixed; boundary="a6iMjdHC3JwG0qaDfndJ7oU4sPT6MdIqr"; protected-headers="v1" From: Henrik Levkowetz To: XML Developer List Message-ID: <87699400-a99b-368f-2b17-59b2a0ff4e30@levkowetz.com> Subject: Fwd: New Version Notification for draft-levkowetz-xml2rfc-v3-implementation-notes-05.txt References: <154030702132.31409.2403318721299599147.idtracker@ietfa.amsl.com> In-Reply-To: <154030702132.31409.2403318721299599147.idtracker@ietfa.amsl.com> --a6iMjdHC3JwG0qaDfndJ7oU4sPT6MdIqr Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable FYI: -------- Forwarded Message -------- Subject: New Version Notification for draft-levkowetz-xml2rfc-v3-implemen= tation-notes-05.txt Date: Tue, 23 Oct 2018 08:03:41 -0700 From: internet-drafts@ietf.org To: Henrik Levkowetz A new version of I-D, draft-levkowetz-xml2rfc-v3-implementation-notes-05.= txt has been successfully submitted by Henrik Levkowetz and posted to the IETF repository. Name: draft-levkowetz-xml2rfc-v3-implementation-notes Revision: 05 Title: Implementation notes for RFC7991,=E2=80=A8"The 'xml2rfc' Version = 3 Vocabulary" Document date: 2018-10-23 Group: Individual Submission Pages: 35 URL: https://www.ietf.org/internet-drafts/draft-levkowetz-xml2= rfc-v3-implementation-notes-05.txt Status: https://datatracker.ietf.org/doc/draft-levkowetz-xml2rfc-= v3-implementation-notes/ Htmlized: https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-im= plementation-notes-05 Htmlized: https://datatracker.ietf.org/doc/html/draft-levkowetz-xml= 2rfc-v3-implementation-notes Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-levkowetz-xml2r= fc-v3-implementation-notes-05 Abstract: This memo documents issues and observations found while implementing RFC 7991. Individual notes are organised into separate sections, depending on their character. --a6iMjdHC3JwG0qaDfndJ7oU4sPT6MdIqr-- --dNho4cpwJw2ORgglpJ6pO69jABwufO21u Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlvPOX8ACgkQTptXS4+7 FxpcPg/+Kk6c0aUnn40DriAB80dbjo5yor8TCh+UdmPGYinR6yq56Ku/4PX3gtV7 UMfo871LEZQwtP3bo78F/pbVNNJPIEkJhR9MiCozLGAs9ZHY3l0EkIAyzslE7h12 3w6hrSO+noZVrete+kGYQ/hsqzFLSblp2+IdjjfiLPqwb9PUMtIR5AycIN7XmTqY 7MNqK1apEo0Y/zQZitiW+EYHnjYzDLCi7tlIk+zE0ifq99W/9+vZHJYG/Ri6NfPS lTRXgcH0LIqpuaMMrsCdpiFL/JREwIJYMR4zdxAPCDGifxcxJYWLAQCNovQ2lSA8 22Zt4eK8xwi7qjekf5afutlUPlp5z/7An1NtPd/8yhyG6UVd0wrdvYpUgGkqIp54 5v1hZHBtU7/KyOTYIA28tBfQu8HnvV+z4exwQHsVkzT01lzhe9DMLB/9Zkr/pOvt mKLDB2x59zwSp3R632FX1xeMu8sYbCdRtzwhTGApppXbhRpWCzIkIxjVKLbey9X4 y1VeqBThMNuGrM9LCxm6i1NAlW9fXemIn1R5Xgh3df1Snl2s67fnfzChqYiDaB3F jhVZteFt9Spwy0NG6i0eA5GHovYU9u2huE8ORSbmJYygW6HzgwMUqlsEb62vzSmO MZxWP5/++qujXoYNixPoXT0L4UTrjzxq7X8CmNe0Z23uKIKl0bU= =xO9c -----END PGP SIGNATURE----- --dNho4cpwJw2ORgglpJ6pO69jABwufO21u-- From nobody Sun Oct 28 13:48:23 2018 Return-Path: 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 D94BA130DD0; Sun, 28 Oct 2018 13:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 vDX8pZk2vLmj; Sun, 28 Oct 2018 13:48:02 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A4A7130DCB; Sun, 28 Oct 2018 13:48:02 -0700 (PDT) Received: from henrik by durif.tools.ietf.org with local (Exim 4.80) (envelope-from ) id 1gGryb-0000PN-V1; Sun, 28 Oct 2018 13:48:01 -0700 To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org Cc: rfc-markdown@ietf.org Message-Id: From: Henrik Levkowetz Date: Sun, 28 Oct 2018 13:48:01 -0700 X-SA-Exim-Connect-IP: X-SA-Exim-Rcpt-To: rfc-markdown@ietf.org, xml2rfc-dev@ietf.org, xml2rfc@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc-dev] New xml2rfc release: v2.12.0 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2018 20:48:16 -0000 Hi, This is an automatic notification about a new xml2rfc release, v2.12.0, generated when running the mkrelease script. Release notes: xml2rfc (2.12.0) ietf; urgency=medium This release introduces the vocabulary v3 html formatter. In order to invoke this formatter, use the regular --html switch for html output, and add the --v3 switch to specify the v3 html formatter. In v3 html formatter mode, xml2rfc accepts any valid xml2rfc input file, but since the actual formatter only understands the XML elements and attributes which have not been deprecated by RFC7991, it first applies the xml2rfc v2v3 converter in order to transform any deprecated markup to the elements and attributes it understands, and then applies the preptool in order to normalize the input before it starts rendering. This is the first release of the v3 html formatter. It is quite feature complete, but has been tested only on a limited number of documents, so expect that there could be some rough edges. In building the html v3 formatter, a number of rough edges were also discovered in the schema, RFC 7991; html format output, RFC 7992; and preptool specification, RFC 7998. The modifications applied in the code are described in draft-levkowetz-xml2rfc-v3-implementation-notes-05. -- Henrik Levkowetz 28 Oct 2018 13:45:04 -0700 The preferred way to install xml2rfc is by doing 'pip install xml2rfc', and 'pip install --upgrade xml2rfc' to upgrade. If there are system- installed python modules which pip will not upgrade, you may have to use 'pip install --upgrade --no-deps xml2rfc' and install dependencies manually. The new version is also available through SVN checkout, with 'svn checkout http://svn.tools.ietf.org/svn/tools/xml2rfc/tags/cli/2.12.0' Regards, Henrik (via the mkrelease script) From nobody Sun Oct 28 17:58:12 2018 Return-Path: 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 E6427128C65 for ; Sun, 28 Oct 2018 17:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 ZXxN1VjRHtbY for ; Sun, 28 Oct 2018 17:58:09 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07D97124C04 for ; Sun, 28 Oct 2018 17:58:08 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w9T0tA2G046319 for ; Sun, 28 Oct 2018 20:58:08 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049458.ppops.net-00191d01. with ESMTP id 2ndq3ps0ju-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sun, 28 Oct 2018 20:58:07 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w9T0w7Ia007032 for ; Sun, 28 Oct 2018 20:58:07 -0400 Received: from zlp27130.vci.att.com (zlp27130.vci.att.com [135.66.87.38]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w9T0w4ZN007020 for ; Sun, 28 Oct 2018 20:58:06 -0400 Received: from zlp27130.vci.att.com (zlp27130.vci.att.com [127.0.0.1]) by zlp27130.vci.att.com (Service) with ESMTP id CEB1C400055C for ; Mon, 29 Oct 2018 00:58:04 +0000 (GMT) Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (unknown [130.9.129.147]) by zlp27130.vci.att.com (Service) with ESMTPS id B686A400054A for ; Mon, 29 Oct 2018 00:58:04 +0000 (GMT) Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.94]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0415.000; Sun, 28 Oct 2018 20:58:04 -0400 From: "HANSEN, TONY L" To: "xml2rfc-dev@ietf.org" Thread-Topic: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    Thread-Index: AQHUWXpP2bIGgqHK60e8v7OAHMJ3RqUKjt6AgAAIXgCAAHmvgIAADAUAgAJpLQCAACU6AIAAAu6AgAACsYCAAAQUgIAAAb6AgAAJYYCAACXaAIAAkUAAgAAsmYCAJu4TgA== Date: Mon, 29 Oct 2018 00:58:03 +0000 Message-ID: <126D2B1E-3F0E-4248-AEFC-658B56243438@att.com> References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <1BA3E011-CEB3-4F56-9CB5-599C6D2D8A5D@icann.org> <2a71916e-4704-ef8c-b9bb-0cda1781c706@levkowetz.com> <2a06b7c8-5a84-60eb-c96e-25d07c61d67f@gmx.de> <4b49045f-49d7-2b01-bb57-087f8e014e5b@levkowetz.com> <32ef6fd2-058a-c44a-5129-26cd22343943@gmx.de> <6c9785df-73c0-78ff-0c69-1ea1b369b0e0@levkowetz.com> <766a8834-4e7a-e819-6b76-2682eb99be9e@gmx.de> <81f488c3-1caf-a7cc-dc38-c39b3ca2ba5a@levkowetz.com> <037501d45b89$e3562db0$aa028910$@augustcellars.com> In-Reply-To: <037501d45b89$e3562db0$aa028910$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.210.13.249] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-28_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810290007 Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 00:58:11 -0000 KFRyeWluZyB0byBjYXRjaCB1cCB3aXRoIHNvbWUgb2YgdGhlc2UgZW1haWxzLikgWWVzLCBJIERJ RCBkbyBleHRlbnNpdmUgYW5hbHlzaXMgb2YgdGhlIHVzZSBvZiA8dnNwYWNlLz4gaW4gZXhpc3Rp bmcgWE1MIGZpbGVzLCBidXQgSSBjYW5ub3QgZmluZCB0aGUgZW1haWxzIHRoYXQgSSBzZW50IGJh Y2sgdGhlbi4NCg0KVGhlIGdpc3Qgb2YgdGhlIGFuYWx5c2lzIHdhcyB0aGF0IHRoZSBvbmx5IHVz ZSBvZiA8dnNwYWNlLz4gdGhhdCBib3RoIDEpIGhhZCBjb25zaWRlcmFibGUgdXNlIGFuZCAyKSBj b3VsZG4ndCBiZSBoYW5kbGVkIHRocm91Z2ggb3RoZXIgbWVhbnMsIHdhcyB3aXRoaW4gdGFibGUg Y2VsbHMuIFRoZXJlIHdhcyBhIG1vdmUgYWZvb3QgYXQgdGhlIHRpbWUgdG8gcmVtb3ZlIHRoZSBj YXBhYmlsaXR5IGVudGlyZWx5LCBhbmQgdGhlc2UgY291bnRlcmFyZ3VtZW50cyBhcmUgd2hhdCBs ZWFkIHRvIHRoZSBpbmNsdXNpb24gb2YgPGJyLz4gYXQgbGVhc3QgZm9yIHRoZSBsaW1pdGVkIHVz ZSB3aXRoaW4gdGFibGVzIHRoYXQgd2UgZ290LiBJIGRvbid0IHRoaW5rIHRob3NlIHVzZSBjYXNl cyBoYXZlIGdvbmUgYXdheSBhbmQgd2Ugc2hvdWxkIG5vdCByZW1vdmUgdGhlIGFiaWxpdHkgdG8g Zm9yY2UgYSBsaW5lIGJyZWFrIHdoZW4gaXQgaXMgYWJzb2x1dGVseSBuZWVkZWQuIEkgZG9uJ3Qg cmVhbGx5IGNhcmUgd2hldGhlciB0aGF0IGFiaWxpdHkgaXMgc3BlbGxlZCA8dnNwYWNlLz4sIDxi ci8+LCA8dGJyLz4gb3Igd2hhdGV2ZXIuDQoNCkknbGwga2VlcCBsb29raW5nIGZvciB0aGUgZW1h aWxzIGFuZCB0aGUgcmVzdWx0cyBvZiBteSBhbmFseXNpcyBiYWNrIHRoZW4uDQoNCglUb255DQoN Cu+7v09uIDEwLzMvMTgsIDEwOjI4IFBNLCAieG1sMnJmYy1kZXYgb24gYmVoYWxmIG9mIEppbSBT Y2hhYWQiIDx4bWwycmZjLWRldi1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBpZXRmQGF1 Z3VzdGNlbGxhcnMuY29tPiB3cm90ZToNCg0KICAgIA0KICAgIA0KICAgID4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCiAgICA+IEZyb206IHhtbDJyZmMtZGV2IDx4bWwycmZjLWRldi1ib3Vu Y2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgSGVucmlrDQogICAgPiBMZXZrb3dldHoNCiAgICA+ IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAzLCAyMDE4IDQ6NDggUE0NCiAgICA+IFRvOiBKdWxp YW4gUmVzY2hrZSA8anVsaWFuLnJlc2Noa2VAZ214LmRlPjsgUGF1bCBIb2ZmbWFuDQogICAgPiA8 cGF1bC5ob2ZmbWFuQGljYW5uLm9yZz47IHhtbDJyZmMtZGV2QGlldGYub3JnDQogICAgPiBTdWJq ZWN0OiBSZTogW3htbDJyZmMtZGV2XSBSRkMgNzk5MSBpc3N1ZSAjMzc6IFNjaGVtYSBJc3N1ZSwg UkZDIDc5OTEsIEluDQogICAgPiBTZWN0aW9uIDIuMTIsIDxicj4NCiAgICA+IA0KICAgID4gT24g MjAxOC0xMC0wMyAxNzowOCwgSnVsaWFuIFJlc2Noa2Ugd3JvdGU6DQogICAgPiA+IE9uIDEwLzMv MjAxOCAyOjUzIFBNLCBIZW5yaWsgTGV2a293ZXR6IHdyb3RlOg0KICAgID4gPj4gSGkgSnVsaWFu LA0KICAgID4gPj4NCiAgICA+ID4+IE9uIDIwMTgtMTAtMDMgMTQ6MTksIEp1bGlhbiBSZXNjaGtl IHdyb3RlOg0KICAgID4gPj4+IE9uIDEwLzMvMjAxOCAyOjEzIFBNLCBIZW5yaWsgTGV2a293ZXR6 IHdyb3RlOg0KICAgID4gPj4+PiAuLi4NCiAgICA+ID4+Pj4gWWVzLCBJJ3ZlIHJ1biB0aGF0IHRo cm91Z2ggdGhlIGN1cnJlbnQgdGV4dCBwcm9jZXNzb3IsIGFuZCBJDQogICAgPiA+Pj4+IHBhcnRp Y3VsYXJseSBsb29rZWQgYXQgaXQgd2hlbiB3b3JraW5nIG9uIHRhYmxlIHJlbmRlcmluZy4NCiAg ICA+ID4+Pj4NCiAgICA+ID4+Pj4gV2hlcmUgaXMgaXQgeW91IG5lZWQgPGJyPiB0byBtYWtlIHRo aXMgY29tZSBvdXQgcmlnaHQ/DQogICAgPiA+Pj4NCiAgICA+ID4+PiBJbiB0aGUgdGl0bGVzLCBh dCBsZWFzdCBpZiB3ZSB3YW50IHRvIHJlcHJvZHVjZSB3aGF0IHRoZSBSRkMgaGFzLg0KICAgID4g Pj4NCiAgICA+ID4+IFRoYW5rIHlvdSBmb3IgdGhhdC4gIEl0IHByb3ZpZGVzIG11Y2ggYmV0dGVy IHVuZGVyc3RhbmRpbmcgb2YgdGhlDQogICAgPiA+PiBjYXNlIHdoaWNoIHByb21wdGVkIHRoZSBp bnRyb2R1Y3Rpb24gb2YgPGJyPi4NCiAgICA+ID4+DQogICAgPiA+PiBOb3csIHRoZSBuZXcgdjMg ZmVhdHVyZSB3aGljaCBjb3N0IGFic29sdXRlbHkgbW9zdCBleHRyYSB3b3JrIHRvDQogICAgPiA+ PiBpbXBsZW1lbnQsIGJ5IGZhciwgd2FzIHRoZSBhZGRpdGlvbiBvZiB0YWJsZSByb3dzcGFuIGNh cGFiaWxpdHkuDQogICAgPiA+DQogICAgPiA+IEkgZmVlbCB5b3VyIHBhaW4uDQogICAgPiA+DQog ICAgPiA+PiBJZiBpdCByZWFsbHkgaXMgaW1wZXJhdGl2ZSB0byBicmVhayBhIGNvbHVtbiB0aXRs ZSBpbiBvbmUgcGFydGljdWxhcg0KICAgID4gPj4gcGxhY2UgKGFuZCBJIGFncmVlIGl0IG1heSBi ZSBkZXNpcmFibGUpIHRoZW4gd2h5IGNhbid0IGl0IGJlIGhhbmRsZWQNCiAgICA+ID4+IGJ5IHVz aW5nIHJvd3NwYW4gZm9yIHRoZSBvdGhlciBoZWFkZXIgY2VsbHMsIGFuZCB0d28gY2VsbHMgZm9y IHRoZQ0KICAgID4gPj4gcGFydGljdWxhciBjb2x1bW4gdGl0bGUgdGhhdCBuZWVkcyB0byBiZSBi cm9rZW4gaW4gYSBjb250cm9sbGVkIG1hbm5lcj8NCiAgICA+ID4NCiAgICA+ID4gRXhhbXBsZSwg cGxlYXNlPw0KICAgID4gDQogICAgPiBVbW0/ICBUYWtlIHRoZSB0YWJsZSB5b3UgcG9pbnRlZCBh dCwgZ2l2ZSBlYWNoIGhlYWRlciBjZWxsIHJvd3NwYW49IjIiLA0KICAgID4gZXhjZXB0IHRoZSBj ZWxsKHMpIHdoZXJlIHlvdSB3YW50IGEgcGFydGljdWxhciBsaW5lIGJyZWFrLCBhbmQgcHV0IHRo ZSBmaXJzdCBwYXJ0DQogICAgPiBpbiB0aGUgZmlyc3QgY2VsbCBhbmQgdGhlIHNlY29uZCBwYXJ0 IGluIHRoZSBzZWNvbmQgY2VsbC4NCiAgICA+IA0KICAgID4gPj4gQW5kIHNlY29uZCwgd2h5IGlz IHRoaXMgYSBjb25jZXJuIGluIGEgY29sdW1uIGhlYWRlciwgYW5kIG5vdCwgZm9yDQogICAgPiA+ PiBpbnN0YW5jZSBpbiB0aGUgZG9jdW1lbnQgdGl0bGU/DQogICAgPiA+Pg0KICAgID4gPj4gVGhp cyBpcyB0aGUgcmVzdWx0IG9mIGEgdG9vIGxvbmcgZG9jdW1lbnQgdGl0bGUgdG9kYXkgKGFuIGFj dHVhbA0KICAgID4gPj4gZXhhbXBsZSBhcyByZW5kZXJlZCBieSB0aGUgdjMgdGV4dCByZW5kZXJl cik6DQogICAgPiA+Pg0KICAgID4gPj4gLS0tDQogICAgPiA+PiBOZXR3b3JrIFdvcmtpbmcgR3Jv dXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBILiBMZXZrb3dldHoNCiAg ICA+ID4+IEludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEVsZiBUb29scyBBQg0KICAgID4gPj4gSW50ZW5kZWQgc3RhdHVzOiBJbmZvcm1h dGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgICAgIDMgT2N0b2JlciAyMDE4DQogICAgPiA+ PiBFeHBpcmVzOiA2IEFwcmlsIDIwMTkNCiAgICA+ID4+DQogICAgPiA+Pg0KICAgID4gPj4gICAg ICAgICBJbXBsZW1lbnRhdGlvbiBub3RlcyBmb3IgUkZDNzk5MSwgIlRoZSAneG1sMnJmYycgVmVy c2lvbiAzDQogICAgPiA+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVm9jYWJ1bGFy eSINCiAgICA+ID4+ICAgICAgICAgICAgIGRyYWZ0LWxldmtvd2V0ei14bWwycmZjLXYzLWltcGxl bWVudGF0aW9uLW5vdGVzLTA0DQogICAgPiA+DQogICAgPiA+IEluIHRoZSBwYXN0LCB3ZSBoYXZl IHdvcmtlZCBhcm91bmQgdGhhdCBieSB1c2luZyBub24tYnJlYWtpbmcgc3BhY2VzDQogICAgPiA+ IHdoZXJlIHdlIHdhbnQgdG8ga2VlcCB0aGluZ3MgdG9nZXRoZXIuIEkgZG91YnQgdGhhdCB0aGUg c2FtZSBhcHByb2FjaA0KICAgID4gPiB3b3VsZCB3b3JrIHdlbGwgaW4gbmFycm93IHRhYmxlIGNl bGxzLi4uDQogICAgPiANCiAgICA+IFdoeSBub3Q/ICBUaGVyZSdzIG5vIG1hdGhlbWF0aWNhbCBk aWZmZXJlbmNlIGJldHdlZW4gdGhlIHR3byBjYXNlcy4NCiAgICA+IA0KICAgID4gPj4gLi4uDQog ICAgPiA+Pj4gVGhhdCBpcyB0cnVlLCBidXQgSSdtIHByZXBhcmVkIHRvIGFyZ3VlIHRoYXQgaWYg dGhleSB3YW50IHRvIGVuZm9yY2UNCiAgICA+ID4+PiBhIGxpbmUgYnJlYWsgaW4gcnVubmluZyB0 ZXh0LCB0aGV5IGFyZSBkb2luZyBzb21ldGhpbmcgd3JvbmcuDQogICAgPiA+Pg0KICAgID4gPj4g QnV0IGNhbiB3ZSBiZSBzbyBzdXJlIG9mIHRoYXQsIHRoYXQgaXQncyByaWdodCB0byBlbmZvcmNl IHRoZSBjdXJyZW50DQogICAgPiA+PiBsaW1pdGF0aW9uPyAgSGFkIHlvdSB0aG91Z2h0IG9mIHRo ZSBjYXNlIG9mIGEgZG9jdW1lbnQgdGl0bGUsIGFib3ZlPw0KICAgID4gPg0KICAgID4gPiBZZXMu DQogICAgPiANCiAgICA+IE9rLCBnb29kLiAgSW4gdGhhdCBjYXNlIEkgcmVhbGx5IGRvbid0IHVu ZGVyc3RhbmQgd2h5IDxicj4gd2Fzbid0IHByb3ZpZGVkIGZvcg0KICAgID4gZG9jdW1lbnQgdGl0 bGVzIChhbmQgc2VjdGlvbiB0aXRsZXMsIHRvbywgd2hlcmUgSSd2ZSBhbHNvIGNvbWUgYWNyb3Nz IHNpbWlsYXINCiAgICA+IGlzc3VlcyBmb3IgbG9uZyB0aXRsZXMpLg0KICAgID4gDQogICAgPiA+ PiBNaWdodCB0aGVyZSBub3QgYmUgb3RoZXIgY2FzZXM/ICBNYXliZSBpdCB3b3VsZCBiZSBiZXR0 ZXIgdG8gcGVybWl0DQogICAgPiA+PiBpdCwgYW5kIG1heWJlIChhdCBsZWFzdCBpbiBzb21lIGNh c2VzKSBpc3N1ZSBhIHdhcm5pbmc/DQogICAgPiA+DQogICAgPiA+IE9yIHdlIGNhbiB3YWl0IGZv ciB0aGlzIHRvIGJlY29tZSBhbiBpc3N1ZS4NCiAgICA+IA0KICAgID4gTm8sIHRoZSBjaGFuY2Ug d2UgaGF2ZSB0byBnZXQgdGhpcyByaWdodCBpcyBub3cuICBXZSBoYXZlIGEgZmlyc3QgaXRlcmF0 aW9uLCBhbmQNCiAgICA+IHRoYW5rcyBmb3IgYWxsIHRoZSB3b3JrIHRoYXQgd2VudCBpbnRvIGl0 LCBidXQgbGV0J3Mgbm93IHBvbGlzaCBpdCBiYXNlZCBvbiBleHBsaWNpdA0KICAgID4gZXhwZXJp ZW5jZSwgdG8gbWFrZSBpdCBldmVuIGJldHRlci4NCiAgICA+IA0KICAgID4gPiBXZSAqY291bGQq IGFuYWx5emUgdGhlIHNldCBvZiBSRkMgWE1MIHNvdXJjZSBkb2N1bWVudHMgZm9yIHdoZXJlDQog ICAgPiA+IHZzcGFjZSBpcyBjdXJyZW50bHkgdXNlZC4NCiAgICA+IA0KICAgID4gWWVzLCB0aGF0 IHdvdWxkIHByb3ZpZGUgYWRkaXRpb25hbCBtZWFuaW5nZnVsIGRhdGEuDQogICAgDQogICAgSSBo YXZlIGEgdmFndWUgbWVtb3J5IHRoYXQgVG9ueSBkaWQgbG9vayBhdCB0aGlzIHNvIGl0IG1pZ2h0 IGJlIG9uIHRoZSBvbGQgZGlzY3Vzc2lvbiBncm91cCBsaXN0Lg0KICAgIA0KICAgIEppbQ0KICAg IA0KDQo= From nobody Sun Oct 28 18:02:32 2018 Return-Path: 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 BFC14128C65 for ; Sun, 28 Oct 2018 18:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 LUZQP8H9IvXp for ; Sun, 28 Oct 2018 18:02:29 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D382124C04 for ; Sun, 28 Oct 2018 18:02:29 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w9T0t2MT044858; Sun, 28 Oct 2018 21:02:27 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049459.ppops.net-00191d01. with ESMTP id 2ndqjgrnb4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 28 Oct 2018 21:02:27 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w9T12R6b016760; Sun, 28 Oct 2018 21:02:27 -0400 Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [135.66.87.52]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w9T12OMZ016731; Sun, 28 Oct 2018 21:02:24 -0400 Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [127.0.0.1]) by zlp27125.vci.att.com (Service) with ESMTP id 38B9316A3EE; Mon, 29 Oct 2018 01:02:24 +0000 (GMT) Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (unknown [130.9.129.147]) by zlp27125.vci.att.com (Service) with ESMTPS id 22BDF16A3ED; Mon, 29 Oct 2018 01:02:24 +0000 (GMT) Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.94]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0415.000; Sun, 28 Oct 2018 21:02:24 -0400 From: "HANSEN, TONY L" To: Heather Flanagan , "xml2rfc-dev@ietf.org" Thread-Topic: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    Thread-Index: AQHUWXpP2bIGgqHK60e8v7OAHMJ3RqUKjt6AgAAIXgCAAHmvgIABcamAgAMaDICAAAq3AIAB6tEAgCQA+wA= Date: Mon, 29 Oct 2018 01:02:23 +0000 Message-ID: <62E32D1C-4E14-4D48-AEA7-B157A60D139C@att.com> References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <65f7d2f9-21ed-c7a1-a234-05e00e1c7dae@rfc-editor.org> In-Reply-To: <65f7d2f9-21ed-c7a1-a234-05e00e1c7dae@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.210.13.249] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-28_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810290007 Archived-At: Subject: Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 01:02:31 -0000 R2l2ZW4gdGhpcywgc2hvdWxkIEkgY29udGludWUgdG8gbG9vayBmb3IgbXkgYW5hbHlzaXMgdGhh dCBJIHJhaXNlZCBkdXJpbmcgdGhlIGRlc2lnbiBwcm9jZXNzIHRoYXQgbGVkIHVzIHRvIGNvbmNs dWRlIHRoYXQgPGJyLz4gZnVuY3Rpb25hbGl0eSBXQVMgcmVxdWlyZWQgZm9yIGNlcnRhaW4gdXNl IGNhc2VzLCBhbmQgdGhhdCB0aGVyZSB3YXMgbm8gIGNsZWFuIGFsdGVybmF0aXZlIHdheSBvZiBo YW5kbGluZyBpdD8NCg0KCVRvbnkNCg0K77u/T24gMTAvNS8xOCwgNzoxMyBQTSwgInhtbDJyZmMt ZGV2IG9uIGJlaGFsZiBvZiBIZWF0aGVyIEZsYW5hZ2FuIiA8eG1sMnJmYy1kZXYtYm91bmNlc0Bp ZXRmLm9yZyBvbiBiZWhhbGYgb2YgcnNlQHJmYy1lZGl0b3Iub3JnPiB3cm90ZToNCg0KICAgIEhv bGEgYSB0b2RvcyENCiAgICANCiAgICBBcG9sb2dpZXMgZm9yIGxldHRpbmcgdGhpcyB0aHJlYWQg Z2V0IGEgYml0IG91dCBvZiBoYW5kLiBBaXJwbGFuZXMgYW5kIA0KICAgIHNtYWxsLCBvbi1zaXRl IG1lZXRpbmdzIGFyZSBub3QgY29uZHVjaXZlIHRvIGhhbmRsaW5nIGFjdGl2ZSB0aHJlYWRzLg0K ICAgIA0KICAgIFRoaXMgaXNuJ3QgYW4gSUVURiBXRywgYnV0IHdlJ3JlIGdvaW5nIHRvIHdvcmsg YWxvbmcgdGhvc2UgbW9kZWxzIGZvciANCiAgICBzYWtlIG9mIGNsYXJpdHkuIENvbnNpZGVyIG1l IHRoZSBXRyBjaGFpciBmb3IgdGhlIHB1cnBvc2Ugb2YgY29uc2Vuc3VzIA0KICAgIGNhbGxzIGFu ZCBicmVha2luZyBkZWFkbG9jayBkZWNpc2lvbnMuDQogICAgDQogICAgTXkgY29tbWVudHMgYW5k IGRlY2lzaW9uIG9uIHdoYXQgdG8gZG8gd2l0aCA8YnI+IGJlbG93Li4uDQogICAgDQogICAgT24g MTAvNC8xOCAxMDo1NiBBTSwgSGVucmlrIExldmtvd2V0eiB3cm90ZToNCiAgICA+IE9uIDIwMTgt MTAtMDQgMTk6MTgsIFJvYmVydCBTcGFya3Mgd3JvdGU6DQogICAgPj4gSSBkaWRuJ3Qgc2VlIGEg cmVzcG9uc2UgdG8gdGhpcy4NCiAgICA+Pg0KICAgID4+IElmIHdlIGRlY2lkZSB0aGF0IHByZXNl cnZpbmcgdGhlICJvbmx5IGluIHRhYmxlcyIgaWRlYSwgdGhpcyBhdm9pZHMgdGhlDQogICAgPj4g YXJndW1lbnQgYWJvdXQgY2F1c2luZyBhdXRob3JzIHVubmVjZXNzYXJ5IGNvbmZ1c2lvbi4NCiAg ICA+Pg0KICAgID4+IElmIGl0J3MgY2xlYXJseSBhIGJhZCBpZGVhLCBwbGVhc2UgY2FwdHVyZSB3 aHkgb24gdGhlIGxpc3QgZm9yIGxhdGVyLg0KICAgID4+DQogICAgPj4gUmpTDQogICAgPj4NCiAg ICA+Pg0KICAgID4+IE9uIDEwLzIvMTggMTI6NTYgUE0sIFBhdWwgSG9mZm1hbiB3cm90ZToNCiAg ICA+Pj4gSSBqdXN0IHRob3VnaHQgb2Ygc29tZXRoaW5nIGRpZmZlcmVudCB0aGF0IG1pZ2h0IGRl YWwgd2l0aCBNaWVrJ3MNCiAgICA+Pj4gaXNzdWU6IGNoYW5nZSB0aGUgbmFtZSBvZiB0aGUgZWxl bWVudCB0byA8dGJyPi4gVGhhdCB3aWxsIHByZXZlbnQNCiAgICA+Pj4gcGVvcGxlIHdobyAia25v dyIgd2hhdCA8YnI+ICJtZWFucyIgZnJvbSBleHBlY3RpbmcgaXQgdG8gd29yaw0KICAgID4+PiBi ZWNhdXNlIDxicj4gZG9lc24ndCBleGlzdC4NCiAgICA+Pj4NCiAgICA+Pj4gSWYsIGxhdGVyLCB3 ZSB3YW50IHRvIGFkZCA8YnI+IGZvciBydW5uaW5nIHRleHQgKHdpdGggbG90cyBvZg0KICAgID4+ PiBkZXNjcmlwdGlvbiBvZiB3aGF0IGl0IHdpbGwgYW5kIHdpbGwgbm90IGRvIHRvIGRpc3BsYXll ZCBSRkNzKSwgd2UNCiAgICA+Pj4gY2FuIGRvIHNvIHRoZW4uDQogICAgPg0KICAgID4gU28sIE1p ZWsncyBvcmlnaW5hbCBpc3N1ZSwgYXMgY29tbXVuaWNhdGVkIHRvIG1lLCBhcyBJIHVuZGVyc3Rv b2QgaXQsDQogICAgPiBmb3VuZCByZWFzb25hYmxlLCBhbmQgdHJpZWQgdG8gY2FwdHVyZSBpbiAj MzcsIHdhcyB0aGF0IDxicj4gd2FzIGdlbmVyYWxseQ0KICAgID4gdW5hdmFpbGFibGUsIGJ1dCB0 aGUgZnVuY3Rpb25hbGl0eSBleGlzdGVkIHNwZWNpZmljYWxseSB3aXRoaW4gdGFibGUgY2VsbHMu DQogICAgPg0KICAgID4gTWllayBoYXMgYWxzbyByYWlzZWQgYSByZWxhdGVkIGlzc3VlLCAjNDEs IGFib3V0IG5vdCBoYXZpbmcgc28gbWFueSBzcGVjaWFsDQogICAgPiBjYXNlcyBpbiB0aGUgc2No ZW1hLg0KICAgID4NCiAgICA+IEZpbmFsbHksIDxicj4gaXMgYSBrbm93biB0b29sIGZvciBhdXRo b3JzIGFjcXVhaW50ZWQgd2l0aCBIVE1MLCBpZiB0aGV5DQogICAgPiBoYXZlIGEgc2l0dWF0aW9u IHdoZXJlIGRlZmF1bHQgbGF5b3V0IGRvZXNuJ3QgZG8gdGhlIHJpZ2h0IHRoaW5nLg0KICAgID4N CiAgICA+IFNvIHJlbmFtaW5nIDxicj4gdG8gPHRicj4gd2lsbCBkZWFsIHdpdGggdGhlIGV4cGVj dGF0aW9uIG9mIDxicj4gYmVpbmcNCiAgICA+IGdlbmVyYWxseSB1c2VmdWwsIHNpbmNlIGl0J3Mg bm90IGNhbGxlZCA8YnI+IGFueSBtb3JlLiAgSXQgd2lsbCBwcm9iYWJseQ0KICAgID4gbGVhdmUg c29tZSBhdXRob3JzIHdpdGhvdXQgcmVtZWR5IGZvciB0aGUgY2FzZSBvZiBjb250cm9sbGluZyB0 YWJsZQ0KICAgID4gY29sdW1uIHRpdGxlIGJyZWFrcywgYXMgdGhleSB3b24ndCB0aGluayB0byBs b29rIGZvciA8dGJyPiBpZiA8YnI+IGRvZXNuJ3QNCiAgICA+IHdvcmsuDQogICAgPg0KICAgID4g VGhlIHJlbmFtaW5nIHdpbGwgbm90IGRvIGFueXRoaW5nIGZvciBpc3N1ZSAjNDEsIGFuZCBpdCB3 aWxsIGFsc28gZG8gbm90aGluZw0KICAgID4gdG8gYWRkcmVzcyB0aGUgbmVlZCBmb3IgYSBzdHJh aWdodGZvcndhcmQgY2FwYWJpbGl0eSBsaWtlIDxicj4gaW4gb3RoZXINCiAgICA+IGNvbnRleHRz Lg0KICAgID4NCiAgICA+IFNvIEkgZG9uJ3Qgc2VlIHRoaXMgYSBjbGVhbiBzb2x1dGlvbiwgYW5k IHRoZSBwYXJ0cyBpdCBzb2x2ZXMgYWxzbyBpbnRyb2R1Y2VzDQogICAgPiBuZXcgZHJhd2JhY2tz Lg0KICAgID4NCiAgICA+IEkgdHJpZWQgdG8gY2FwdHVyZSB3aGF0IEkgZmVsdCB3YXMgdGhlIGVz c2VuY2Ugb2YgdGhlIHByb2JsZW0gaW4gbXkgcHJvcG9zZWQNCiAgICA+IHJlc29sdXRpb24sIG9m IGVpdGhlciBwZXJtaXR0aW5nIDxicj4gd2lkZWx5LCBvciByZW1vdmluZyBpdC4gIEkgc3RpbGwg ZG9uJ3QNCiAgICA+IGNhcmUgbXVjaCBlaXRoZXIgd2F5LCBidXQgPHRicj4gc2VlbXMgdG8gcHJv dmlkZSBuZWl0aGVyIHRoZSBjbGVhbm5lc3Mgb2YNCiAgICA+IHJlbW92aW5nIDxicj4gaXQgY29t cGxldGVseSwgb3IgcGVybWl0dGluZyBpdCBtb3JlIGdlbmVyYWxseS4NCiAgICANCiAgICANCiAg ICBUaGUgZGVzaWduIHRlYW0gaGFkIGEgZ29hbCBvZiByZXF1aXJpbmcgc2VtYW50aWMgbWVhbmlu ZyBmb3IgYWxsIHRhZ3MgDQogICAgKHdlIGRpZG4ndCBxdWl0ZSBnZXQgdGhlcmUsIGJ1dCBpdCB3 YXMgYSBkZXNpZ24gZ29hbCkgYW5kIGdldHRpbmcgdGhlIA0KICAgIGF1dGhvciBvdXQgb2YgdGhl IGJ1c2luZXNzIG9mIGZpZGRsaW5nIHdpdGggdGhlIHJlbmRlcmluZy4gVGhlIHRlYW0gd2FzIA0K ICAgIHByb2JhYmx5IGEgYml0IHRvbyBmb2N1c2VkIG9uIHRoZSBsYXR0ZXIsIGFuZCBkaWRuJ3Qg dGFrZSBpbnRvIGFjY291bnQgDQogICAgc29tZSBvZiB0aGUgdXNlIGNhc2VzIHRoYXQgaGF2ZSBi ZWVuIGRpc2N1c3NlZCBvbiB0aGF0IHRocmVhZC4gU3RpbGwsIGl0IA0KICAgIGlzIGFuIGltcG9y dGFudCBjb25zaWRlcmF0aW9uIHNpbmNlIGl0IGltcGFjdHMgdGhlIHRpbWUgdGhlIGVkaXRvcnMg aGF2ZSANCiAgICB0byBzcGVuZCBvbiBsYXlvdXQgYXMgb3Bwb3NlZCB0byBjb250ZW50IChncmFu dGVkLCB0aGVzZSBhcmVuJ3QgYWx3YXlzIA0KICAgIG11dHVhbGx5IGV4Y2x1c2l2ZSkuDQogICAg DQogICAgU28sIGFsbCB0aGF0IHNhaWQsIEknbSBwYXJ0aWN1bGFybHkgY29uY2VybmVkIGFib3V0 IHRoZSBhbWJpZ3VpdHkgdGhhdCANCiAgICA8YnI+IGlzIGludHJvZHVjaW5nIGhlcmUsIG1ha2lu ZyB0b29saW5nIHRoYXQgbXVjaCBtb3JlIGNvbXBsaWNhdGVkLiANCiAgICBBZnRlciByZWFkaW5n IGFsbCB0aGUgYXJndW1lbnRzLCBJJ20gZ29pbmcgdG8gc2F5IHdlIHJlbW92ZSA8YnI+IA0KICAg IGVudGlyZWx5IGZyb20gdGhlIFhNTCB2MyBzcGVjLiBJdCdzIG5vdCBhZGRpbmcgZW5vdWdoIHZh bHVlIHRvIHN1cHBvcnQgDQogICAgdGhlIGNvbmZ1c2lvbiBpdCdzIGNhdXNpbmcuDQogICAgDQog ICAgVGhhbmsgeW91IGFsbCBmb3IgYSB3ZWxsLXJvdW5kZWQgZGlzY3Vzc2lvbiBvZiB0aGUgaXNz dWVzIQ0KICAgIA0KICAgIEhlYXRoZXINCiAgICANCiAgICANCiAgICBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIHhtbDJyZmMtZGV2IG1haWxpbmcg bGlzdA0KICAgIHhtbDJyZmMtZGV2QGlldGYub3JnDQogICAgaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0 aW5mb194bWwycmZjLTJEZGV2JmQ9RHdJQ0FnJmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPUt6 OFZkZ1BWY3RETlNOUEo2UHNCYXcmbT1Ibjlsc1BIcnp2TmRmb1Z5QjBra256a0JreHVWUW1uYjk2 NHBXZnBhVkx3JnM9dE5CNjlLc2JtdHNBWnh0d2dLRFBvWTd0RFFjTGhRaXMtWWdQQmN0R3RTVSZl PQ0KICAgIA0KDQo= From nobody Sun Oct 28 18:05:10 2018 Return-Path: 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 1229F123FFD for ; Sun, 28 Oct 2018 18:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 ZB8e4qRq_t48 for ; Sun, 28 Oct 2018 18:05:07 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25CC6124C04 for ; Sun, 28 Oct 2018 18:05:07 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w9T14pEd032462 for ; Sun, 28 Oct 2018 21:05:06 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by mx0a-00191d01.pphosted.com with ESMTP id 2nd5175ub1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sun, 28 Oct 2018 21:05:06 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w9T155hg018380 for ; Sun, 28 Oct 2018 21:05:05 -0400 Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [135.66.87.50]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w9T153Aw018362 for ; Sun, 28 Oct 2018 21:05:03 -0400 Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [127.0.0.1]) by zlp27128.vci.att.com (Service) with ESMTP id B5742400043F for ; Mon, 29 Oct 2018 01:05:03 +0000 (GMT) Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (unknown [130.9.129.148]) by zlp27128.vci.att.com (Service) with ESMTPS id A2C7F4000420 for ; Mon, 29 Oct 2018 01:05:03 +0000 (GMT) Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.94]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0415.000; Sun, 28 Oct 2018 21:05:03 -0400 From: "HANSEN, TONY L" To: "xml2rfc-dev@ietf.org" Thread-Topic: [xml2rfc-dev] [Ext] Re: RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    Thread-Index: AQHUXCn+L4cO5s1BlUKevcJWeRuycqUP5HIAgCWqEQA= Date: Mon, 29 Oct 2018 01:05:02 +0000 Message-ID: <410BB67F-2C5A-4B9E-AF78-04D94991A082@att.com> References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.210.13.249] Content-Type: text/plain; charset="utf-8" Content-ID: <2FB0EF7D501F3E4FBD174F2B0BFBAB03@LOCAL> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-28_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=867 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810290009 Archived-At: Subject: Re: [xml2rfc-dev] [Ext] Re: RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12,
    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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 01:05:08 -0000 TXkgZHJ1dGhlcnMgd291bGQgaGF2ZSBiZWVuIHRvIGFsbG93IGl0IGFueXdoZXJlLg0KDQoJVG9u eQ0KDQrvu79PbiAxMC80LzE4LCA1OjU1IFBNLCAieG1sMnJmYy1kZXYgb24gYmVoYWxmIG9mIEhl bnJpayBMZXZrb3dldHoiIDx4bWwycmZjLWRldi1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBv ZiBoZW5yaWtAbGV2a293ZXR6LmNvbT4gd3JvdGU6DQoNCiAgICBIaSBKdWxpYW4sDQogICAgDQog ICAgT24gMjAxOC0xMC0wNCAyMzozMywgSnVsaWFuIFJlc2Noa2Ugd3JvdGU6DQogICAgPiBPbiAy MDE4LTEwLTA0IDIxOjM5LCBNaWVrIEdpZWJlbiB3cm90ZToNCiAgICA+PiBbIFF1b3RpbmcgPHBh dWwuaG9mZm1hbkBpY2Fubi5vcmc+IGluICJSZTogW0V4dF0gUmU6IFt4bWwycmZjLWRldl0gUkZD IA0KICAgID4+IDc5OS4uLiIgXQ0KICAgID4+PiBPbmUgb2YgdGhlIGRlc2lnbiBnb2FscyBmb3Ig djMgd2FzIHRvIGdldCByaWQgb2YgbWFya3VwIHRoYXQgaGFkIG5vIA0KICAgID4+PiBzZW1hbnRp YyBtZWFuaW5nIHRvIHRoZSBkb2N1bWVudHMuIFdlIG1vc3RseSBzdWNjZWVkZWQgYXQgdGhhdCwg YnV0IA0KICAgID4+PiBjbGVhcmx5IGZhaWxlZCB0byBjbGVhbiB1cCBzb21lIG9mIGl0IChzdWNo IGFzIGJ5IGFsbG93aW5nIDxicj4gaW4gDQogICAgPj4+IHRhYmxlIGNlbGxzKS4gSSBzdGlsbCB0 aGluayB0aGlzIGlzIGEgZ29vZCBnb2FsLCBhbmQgaWYgd2Ugd2FudCB0byBiZSANCiAgICA+Pj4g Y29uc2lzdGVudCwgd2Ugc2hvdWxkIGp1c3QgcmlkIG9mIDxicj4uDQogICAgPj4gDQogICAgPj4g SWYgdGhhdCdzIHRlY2huaWNhbGx5IHBvc3NpYmxlOiArMSBmb3IgcmVtb3ZpbmcgPGJyPiBlbnRp cmVseQ0KICAgID4gDQogICAgPiBNaXNsZWFkaW5nLg0KICAgID4gDQogICAgPiBIVE1MIGNhbiBm b2N1cyBvbiBzZW1hbnRpYyBtYXJrdXAsIGJlY2F1c2UgaXQgaGFzIGEgc2lzdGVyIHRlY2hub2xv Z3kgdG8gDQogICAgPiBkZWFsIHdpdGggcHJlc2VudGF0aW9uIChDU1MpLiBXZSBkb24ndCBoYXZl IHRoYXQsIHNvIHdlIG5lZWQgdG8gY29uc2lkZXIgDQogICAgPiBjb21tb24gY2FzZXMgd2hlcmUg YSBkZWZhdWx0IHByZXNlbnRhdGlvbiBqdXN0IGlzbid0IGdvb2QgZW5vdWdoLg0KICAgID4gDQog ICAgPiBJJ20gdmVyeSBzdXJwcmlzZWQgdGhhdCBwZW9wbGUgaGF2ZSBubyBwcm9ibGVtIGFkZGlu ZyBhbiBhdHRyaWJ1dGUgZm9yIA0KICAgID4gaGFuZ2luZyBsaXN0IHByZXNlbnRhdGlvbiBidXQg dGhlbiBhdCB0aGUgc2FtZSB0aW1lIG9iamVjdCB0byBlbmZvcmNlZCANCiAgICA+IGxpbmUgYnJl YWtzIGluIHRhYmxlIGNlbGxzLg0KICAgIA0KICAgIEZvciBtZSwgaXQncyBub3QgdGhhdC4gIEl0 IGlzIGFkZGluZyA8YnI+IGZvciB0aGF0IGNhc2UsIGFuZCBub3QgZm9yDQogICAgb3RoZXJzIHdo ZXJlIGl0IHdvdWxkIGJlIGp1c3QgYXMgdXNlZnVsLiAgSXQncyB0aGUgaW5jb25zaXN0ZW5jeS4N CiAgICANCiAgICANCiAgICBCZXN0IHJlZ2FyZHMsDQogICAgDQogICAgCUhlbnJpaw0KICAgIA0K ICAgIA0KICAgIA0KDQo= From nobody Mon Oct 29 05:20:39 2018 Return-Path: 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 92D4D130F3B; Mon, 29 Oct 2018 05:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 BIEL5DH3_EZm; Mon, 29 Oct 2018 05:20:17 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81D7C130EE6; Mon, 29 Oct 2018 05:20:17 -0700 (PDT) Received: from henrik by durif.tools.ietf.org with local (Exim 4.80) (envelope-from ) id 1gH6Wn-0002ca-CU; Mon, 29 Oct 2018 05:20:17 -0700 To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org Cc: rfc-markdown@ietf.org Message-Id: From: Henrik Levkowetz Date: Mon, 29 Oct 2018 05:20:17 -0700 X-SA-Exim-Connect-IP: X-SA-Exim-Rcpt-To: rfc-markdown@ietf.org, xml2rfc-dev@ietf.org, xml2rfc@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc-dev] New xml2rfc release: v2.12.1 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 12:20:25 -0000 Hi, This is an automatic notification about a new xml2rfc release, v2.12.1, generated when running the mkrelease script. Release notes: xml2rfc (2.12.1) ietf; urgency=medium This release provides some additional polish over release 2.12.0, and also a few bugfixes. The primary focus for this release has been HTML compliance based on the W3C validator at https://validator.w3.org/. Valid HTML 5 is now generated for all documents used during testing. From the commit log: * Fixed a number of issues with the v3 html renderer, to improve the generated html. Many of these were caught by the W3C validator at validator.w3.org: - removed the element, as it should not appear when there is a element - removed type="text/javascript" from a