From nobody Mon Feb 12 11: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 C56E612D864 for ; Mon, 12 Feb 2018 11:02:39 -0800 (PST) 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 iNr7UTyiqLip for ; Mon, 12 Feb 2018 11:02:37 -0800 (PST) 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 9B2301243F3 for ; Mon, 12 Feb 2018 11:02:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 160D31CAE53 for ; Mon, 12 Feb 2018 11:02:08 -0800 (PST) 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 oKlSAeTGpgr6 for ; Mon, 12 Feb 2018 11:02:07 -0800 (PST) Received: from Heathers-MacBook-Pro.local (c-73-181-135-61.hsd1.wa.comcast.net [73.181.135.61]) by c8a.amsl.com (Postfix) with ESMTPSA id D4D4F1CAE50 for ; Mon, 12 Feb 2018 11:02:07 -0800 (PST) References: To: xml2rfc-dev@ietf.org From: "Heather Flanagan (RFC Series Editor)" X-Forwarded-Message-Id: Message-ID: <55b140a1-f526-73eb-6209-720d46b310c9@rfc-editor.org> Date: Mon, 12 Feb 2018 11:02:36 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E180EF7FA886D42D0AE73B6D" Content-Language: en-US Archived-At: Subject: [xml2rfc-dev] Fwd: New xml2rfc release: v2.9.0 X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.22 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, 12 Feb 2018 19:02:40 -0000 This is a multi-part message in MIME format. --------------E180EF7FA886D42D0AE73B6D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit In case folks didn't see this elsewhere. Relevant to the new format work. -Heather -------- Forwarded Message -------- Subject: New xml2rfc release: v2.9.0 Date: Sat, 10 Feb 2018 00:24:50 +0100 From: Henrik Levkowetz To: rse@rfc-editor.org CC: arusso@amsl.com, glen@amsl.com, henrik@levkowetz.com, housley@vigilsec.com, mferguson@amsl.com, mlarson@amsl.com, rjs@nostrum.com, sginoza@amsl.com Hi, This is an automatic notification about a new xml2rfc release, v2.9.0, generated when running the mkrelease script. Release notes: xml2rfc (2.9.0) ietf; urgency=medium This release introduces preptool functionality, through a --preptool output mode. With reservation for some points for which issues has been raised, this follows the spedicfication in RFC7998. The preptool currently takes vocabulary v3 input, and produces prepped output. When work on the text formatter commences, the idea is that the input xml source will always be run through v2v3 conversion and preptool processing before the output formatting, in order to increase consistency and reduce complexity of the output formatter. There are also some changes which are not related to the preptool functionality: The tox tests have been changed to add testing under Python 3.6, and removed test runs for Python 3.3. Although there is no intention of breaking compatibility with Python 3.3, it may happen eventually since there will not be any release testing with that version of Python. The v2v3 converter in some cases could insert elements with only a name= attribute, because the required seriesNo= attribute on was missing. This has been changed. In order to work around a debilitating issue with relax-ng validation in libxml2 (time to validate increases exponentially with number of attributes on the root element: https://bugzilla.gnome.org/show_bug.cgi?id=133736) some empty attributes on are removed during processing; for instance obsoletes="" and updates="". They don't contribute information, but increase validation time with a factor ~20. In order to identify the unicode scripts needed to display a document, a module to efficiently identify the scripts related to unicode codepoints has been written. The 'uniscripts' module which was originally intended to be used for this turned out not to be viable. The new 'scripts' module can be broken out for separate release as a library module, if desired. In order to work with vocabulary v3 input, the parser has been slightly modified to not do input validation according to rfc2629.dtd if not appropriate. The preferred way to install xml2rfc is by doing 'pip install xml2rfc', and 'pip install --upgrade xml2rfc' to upgrade. The new version is also available through SVN checkout, with 'svn checkout http://svn.tools.ietf.org/svn/tools/xml2rfc/tags/cli/2.9.0' Regards, Henrik (via the mkrelease script) --------------E180EF7FA886D42D0AE73B6D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

In case folks didn't see this elsewhere. Relevant to the new format work.

-Heather

-------- Forwarded Message --------
Subject: New xml2rfc release: v2.9.0
Date: Sat, 10 Feb 2018 00:24:50 +0100
From: Henrik Levkowetz <henrik@dornfelder.tools.ietf.org>
To: rse@rfc-editor.org
CC: arusso@amsl.com, glen@amsl.com, henrik@levkowetz.com, housley@vigilsec.com, mferguson@amsl.com, mlarson@amsl.com, rjs@nostrum.com, sginoza@amsl.com


Hi,

This is an automatic notification about a new xml2rfc release, 
v2.9.0, generated when running the mkrelease script.

Release notes:

xml2rfc (2.9.0) ietf; urgency=medium
  This release introduces preptool functionality, through a --preptool output
  mode.  With reservation for some points for which issues has been raised,
  this follows the spedicfication in RFC7998.
  The preptool currently takes vocabulary v3 input, and produces prepped
  output.  When work on the text formatter commences, the idea is that the
  input xml source will always be run through v2v3 conversion and preptool
  processing before the output formatting, in order to increase consistency
  and reduce complexity of the output formatter.
  There are also some changes which are not related to the preptool
  functionality: The tox tests have been changed to add testing under Python
  3.6, and removed test runs for Python 3.3.  Although there is no intention
  of breaking compatibility with Python 3.3, it may happen eventually since
  there will not be any release testing with that version of Python.
  The v2v3 converter in some cases could insert <seriesInfo> elements with
  only a name= attribute, because the required seriesNo= attribute on <rfc>
  was missing.  This has been changed.
  In order to work around a debilitating issue with relax-ng validation in
  libxml2 (time to validate increases exponentially with number of attributes
  on the root element: https://bugzilla.gnome.org/show_bug.cgi?id=133736)
  some empty attributes on <rfc> are removed during processing; for instance
  obsoletes="" and updates="".  They don't contribute information, but
  increase validation time with a factor ~20.
  In order to identify the unicode scripts needed to display a document,
  a module to efficiently identify the scripts related to unicode codepoints
  has been written.  The 'uniscripts' module which was originally intended to
  be used for this turned out not to be viable.  The new 'scripts' module can
  be broken out for separate release as a library module, if desired.
  In order to work with vocabulary v3 input, the parser has been slightly
  modified to not do input validation according to rfc2629.dtd if not
  appropriate.

The preferred way to install xml2rfc is by doing 'pip install xml2rfc',
and 'pip install --upgrade xml2rfc' to upgrade.

The new version is also available through SVN checkout, with
  'svn checkout http://svn.tools.ietf.org/svn/tools/xml2rfc/tags/cli/2.9.0'

Regards,

	Henrik
	(via the mkrelease script)

--------------E180EF7FA886D42D0AE73B6D-- From nobody Tue Feb 13 09:44: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 6412212D863 for ; Tue, 13 Feb 2018 09:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 0mrFCofGSW4l for ; Tue, 13 Feb 2018 09:44:10 -0800 (PST) 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 47BBE12D860 for ; Tue, 13 Feb 2018 09:44:10 -0800 (PST) Received: from Jude (100.44.187.196) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 13 Feb 2018 09:42:04 -0800 From: Jim Schaad To: 'RFC Editor' CC: Date: Tue, 13 Feb 2018 09:43:41 -0800 Message-ID: <01ea01d3a4f2$3187ca60$94975f20$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01EB_01D3A4AF.2364B170" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdOk7/LTlTFOqbGES2OFdWr/zISTGg== Content-Language: en-us X-Originating-IP: [100.44.187.196] Archived-At: Subject: [xml2rfc-dev] Non-ASCII punctuation X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.22 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, 13 Feb 2018 17:44:14 -0000 ------=_NextPart_000_01EB_01D3A4AF.2364B170 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I am currently running into problems with non-ASCII punctuation when = doing spell checking, so I went to the RFC to see what it said about = this issue. As near as I can tell, there is nothing in the current = document that says anything about this. I believe that the document = needs to be updated to address this issue. I am not sure what I fell = about this. One of the issues in working on this is that the current = kramdown converter to xml2rfc v2 language automatically uses the left = and right double quotes rather than the vertical double quotes. =20 For text files, the use of characters such as =E2=80=9F (left double = quote) is a problem as they are not ASCII. In HTML, I believe that the = general consensus is that the use of left and right double quotes is = more readable than single quotes as it is what is generally used in = typesetting. I am not sure that the previous statement is correct or = not. On the third hand, consistency of quotes between the different = display formats is probably a nice thing to have. =20 I believe that my opinion would be that they are permitted, however we = need say that we are not going to want to allow some punctuation such as = =C2=A1 (inverted exclamation mark) even though they are in the Latin-1 = page. So if we allow extended punctuation, then we need to be clear = that not all is going to be allowed except in specific cases (such as = quoted text). =20 Jim =20 ------=_NextPart_000_01EB_01D3A4AF.2364B170 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I am currently running into problems with non-ASCII = punctuation when doing spell checking, so I went to the RFC to see what = it said about this issue.=C2=A0 As near as I can tell, there is nothing = in the current document that says anything about this.=C2=A0 I believe = that the document needs to be updated to address this issue.=C2=A0 I am = not sure what I fell about this.=C2=A0 One of the issues in working on = this is that the current kramdown converter to xml2rfc v2 language = automatically uses the left and right double quotes rather than the = vertical double quotes.

 

For = text files, the use of characters such as =E2=80=9F (left double quote) = is a problem as they are not ASCII.=C2=A0 In HTML, I believe that the = general consensus is that the use of left and right double quotes is = more readable than single quotes as it is what is generally used in = typesetting.=C2=A0 =C2=A0I am not sure that the previous statement is = correct or not.=C2=A0 On the third hand, consistency of quotes between = the different display formats is probably a nice thing to = have.

 

I believe that my opinion would be that they are = permitted, however we need say that we are not going to want to allow = some punctuation such as =C2=A1 (inverted exclamation mark) even though = they are in the Latin-1 page.=C2=A0 So if we allow extended punctuation, = then we need to be clear that not all is going to be allowed except in = specific cases (such as quoted text).

 

Jim

 

------=_NextPart_000_01EB_01D3A4AF.2364B170-- From nobody Tue Feb 13 09:51: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 0820F126D45 for ; Tue, 13 Feb 2018 09:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 n8afa9OQEULM for ; Tue, 13 Feb 2018 09:51:18 -0800 (PST) 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 BA90812D860 for ; Tue, 13 Feb 2018 09:51:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 46CF41D35B4 for ; Tue, 13 Feb 2018 09:50:48 -0800 (PST) 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 7Nzs1D-_4RjM for ; Tue, 13 Feb 2018 09:50:48 -0800 (PST) Received: from Heathers-MacBook-Pro.local (c-73-181-135-61.hsd1.wa.comcast.net [73.181.135.61]) by c8a.amsl.com (Postfix) with ESMTPSA id 089961D35AE for ; Tue, 13 Feb 2018 09:50:48 -0800 (PST) To: xml2rfc-dev@ietf.org References: <01ea01d3a4f2$3187ca60$94975f20$@augustcellars.com> From: "Heather Flanagan (RFC Series Editor)" Message-ID: Date: Tue, 13 Feb 2018 09:51:17 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <01ea01d3a4f2$3187ca60$94975f20$@augustcellars.com> Content-Type: multipart/alternative; boundary="------------9AA00746B4AF8AACD4D397EC" Content-Language: en-US Archived-At: Subject: Re: [xml2rfc-dev] Non-ASCII punctuation X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.22 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, 13 Feb 2018 17:51:25 -0000 This is a multi-part message in MIME format. --------------9AA00746B4AF8AACD4D397EC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 2/13/18 9:43 AM, Jim Schaad wrote: > > I am currently running into problems with non-ASCII punctuation when > doing spell checking, so I went to the RFC to see what it said about > this issue.  As near as I can tell, there is nothing in the current > document that says anything about this.  I believe that the document > needs to be updated to address this issue.  I am not sure what I fell > about this.  One of the issues in working on this is that the current > kramdown converter to xml2rfc v2 language automatically uses the left > and right double quotes rather than the vertical double quotes. > >   > > For text files, the use of characters such as ‟ (left double quote) is > a problem as they are not ASCII.  In HTML, I believe that the general > consensus is that the use of left and right double quotes is more > readable than single quotes as it is what is generally used in > typesetting.   I am not sure that the previous statement is correct or > not.  On the third hand, consistency of quotes between the different > display formats is probably a nice thing to have. > >   > > I believe that my opinion would be that they are permitted, however we > need say that we are not going to want to allow some punctuation such > as ¡ (inverted exclamation mark) even though they are in the Latin-1 > page.  So if we allow extended punctuation, then we need to be clear > that not all is going to be allowed except in specific cases (such as > quoted text). > I'm doing a bit of homework on this, and found this to be interesting reading: https://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html I am leaning towards straight quotes as unambiguous and consistent. If someone wants to use other punctuation in Latin-1 such as ¡, that's not used in English (language of the series) so it would have to be treated like any other non-ASCII character described in RFC 7997. -Heather --------------9AA00746B4AF8AACD4D397EC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 2/13/18 9:43 AM, Jim Schaad wrote:

I am currently running into problems with non-ASCII punctuation when doing spell checking, so I went to the RFC to see what it said about this issue.  As near as I can tell, there is nothing in the current document that says anything about this.  I believe that the document needs to be updated to address this issue.  I am not sure what I fell about this.  One of the issues in working on this is that the current kramdown converter to xml2rfc v2 language automatically uses the left and right double quotes rather than the vertical double quotes.

 

For text files, the use of characters such as ‟ (left double quote) is a problem as they are not ASCII.  In HTML, I believe that the general consensus is that the use of left and right double quotes is more readable than single quotes as it is what is generally used in typesetting.   I am not sure that the previous statement is correct or not.  On the third hand, consistency of quotes between the different display formats is probably a nice thing to have.

 

I believe that my opinion would be that they are permitted, however we need say that we are not going to want to allow some punctuation such as ¡ (inverted exclamation mark) even though they are in the Latin-1 page.  So if we allow extended punctuation, then we need to be clear that not all is going to be allowed except in specific cases (such as quoted text).


I'm doing a bit of homework on this, and found this to be interesting reading:

https://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html

I am leaning towards straight quotes as unambiguous and consistent. If someone wants to use other punctuation in Latin-1 such as ¡, that's not used in English (language of the series) so it would have to be treated like any other non-ASCII character described in RFC 7997.

-Heather
--------------9AA00746B4AF8AACD4D397EC-- From nobody Tue Feb 13 13:15: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 0F38012D947 for ; Tue, 13 Feb 2018 13:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 yu3pdO85pVi1 for ; Tue, 13 Feb 2018 13:15:47 -0800 (PST) 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 45DA01243FE for ; Tue, 13 Feb 2018 13:15:47 -0800 (PST) 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 w1DLFhrC022900; Tue, 13 Feb 2018 22:15:43 +0100 (CET) Received: from [192.168.217.114] (p5DC7EAF5.dip0.t-ipconnect.de [93.199.234.245]) (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 3zgwLR2M4bzDWs1; Tue, 13 Feb 2018 22:15:43 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Tue, 13 Feb 2018 22:15:42 +0100 Cc: xml2rfc-dev@ietf.org X-Mao-Original-Outgoing-Id: 540249341.199394-eedf33512062424acafad3517ed671e4 Content-Transfer-Encoding: quoted-printable Message-Id: <3BB018B4-4A43-44A9-85F1-C7B565E32CFD@tzi.org> References: <01ea01d3a4f2$3187ca60$94975f20$@augustcellars.com> To: "Heather Flanagan (RFC Series Editor)" X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [xml2rfc-dev] Non-ASCII punctuation X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.22 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, 13 Feb 2018 21:15:50 -0000 Hi Heather, I own a hardbound *book* that is entirely about quotation marks. It is = a fun subject=E2=80=A6 For a starter: https://en.wikipedia.org/wiki/Quotation_mark#Summary_table Kramdown-rfc generates =E2=80=9Csmart quotes=E2=80=9D (i.e. = typographically correct quotes, just as in this email) because, at the = time I wrote the code, that setting just was the default, and I didn=E2=80= =99t have to change it as xml2rfc happily converts typographic quotes = into the typewriter quotes that ASCII offers. So unless the author = changes the settings (search for smart_quotes or 1.0.31 in = https://github.com/cabo/kramdown-rfc2629), they get the characters that = are called ldquo and rdquo (or lsquo/rsquo) in HTML. I never changed = this because the HTML generated from these XML files just reads better. I would expect at least some other tools to output XML with = typographically correct quotes, as well, so any prep tool for RFCXMLv3 = would need to handle them. By the way, similar considerations apply to = other basic typographical characters such as dashes, hyphens, ellipses. Obviously, RFCs can opt to side with ASCII on the typographic features = of the English language even on the XML side, as xml2rfc has been doing = for the TXT final form for a long time now. If you want to go that way, = that should not be a submission setting, but a post-preptool = distribution setting. (I personally don=E2=80=99t understand why we = would need to do this, as XML is perfectly capable of handling basic = typographic features as is HTML. But it may still be the right thing = for formatting to TXT, as it is done now.) It becomes interesting when people start using non-English variants of = quotes (e.g., the German left and right quotes, where the German right = quote is identical in many fonts to the English left quote, but we use a = lowered left quote). That is not going to work well with English text. Guillemets (=E2=80=9Cangle quotes=E2=80=9D) are a boundary case, but = probably should not be accepted either (they are rarely used in English, = and they have inverse roles in French and Swiss vs. German German = typography).=20 I=E2=80=99m not going to start talking about thin spaces, but these also = need to be handled reasonably. Gr=C3=BC=C3=9Fe, Carsten PS.: Apple=E2=80=99s spelling dictionary =E2=80=9Cautocorrects=E2=80=9D = Guillemets into birds (Guillemots) =E2=80=94 even Adobe fell for this = malapropism, and Wikipedia outright says =E2=80=9Cthey are not used in = the English language=E2=80=9D. Yeah right. > On Feb 13, 2018, at 18:51, Heather Flanagan (RFC Series Editor) = wrote: >=20 > On 2/13/18 9:43 AM, Jim Schaad wrote: >> I am currently running into problems with non-ASCII punctuation when = doing spell checking, so I went to the RFC to see what it said about = this issue. As near as I can tell, there is nothing in the current = document that says anything about this. I believe that the document = needs to be updated to address this issue. I am not sure what I fell = about this. One of the issues in working on this is that the current = kramdown converter to xml2rfc v2 language automatically uses the left = and right double quotes rather than the vertical double quotes. >> =20 >> For text files, the use of characters such as =E2=80=9F (left double = quote) is a problem as they are not ASCII. In HTML, I believe that the = general consensus is that the use of left and right double quotes is = more readable than single quotes as it is what is generally used in = typesetting. I am not sure that the previous statement is correct or = not. On the third hand, consistency of quotes between the different = display formats is probably a nice thing to have. >> =20 >> I believe that my opinion would be that they are permitted, however = we need say that we are not going to want to allow some punctuation such = as =C2=A1 (inverted exclamation mark) even though they are in the = Latin-1 page. So if we allow extended punctuation, then we need to be = clear that not all is going to be allowed except in specific cases (such = as quoted text). >=20 > I'm doing a bit of homework on this, and found this to be interesting = reading: >=20 > https://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html >=20 > I am leaning towards straight quotes as unambiguous and consistent. If = someone wants to use other punctuation in Latin-1 such as =C2=A1, that's = not used in English (language of the series) so it would have to be = treated like any other non-ASCII character described in RFC 7997. >=20 > -Heather > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc-dev From nobody Tue Feb 13 22:26: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 AD98B126579 for ; Tue, 13 Feb 2018 22:26:14 -0800 (PST) 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, 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 lv07uPnWzVuP for ; Tue, 13 Feb 2018 22:26:11 -0800 (PST) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0092.outbound.protection.outlook.com [104.47.92.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D796124F57 for ; Tue, 13 Feb 2018 22:26:11 -0800 (PST) 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; bh=QYGXYkemA2vh2s9kPIRk6uFdIS2Qp3V41eA2yu4lw5o=; b=OrNcxlphevXPhrfu/14GvJQWCQIDLVoSo9+8cpsdO7FpQRd0wHSoX32/7SYJiFdDJjlYl8IYM3nhu4zcmwM2r64dCuVjB4YeYc0s/lDsBX6Er0T4IxBguPdJXezM4BK/h1qTL6WWzttgyx4i7qMCO5x10yf5P2udUBeij27Bung= 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 OSAPR01MB1537.jpnprd01.prod.outlook.com (2603:1096:603:2e::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Wed, 14 Feb 2018 06:26:08 +0000 To: Carsten Bormann , "Heather Flanagan (RFC Series Editor)" Cc: xml2rfc-dev@ietf.org References: <01ea01d3a4f2$3187ca60$94975f20$@augustcellars.com> <3BB018B4-4A43-44A9-85F1-C7B565E32CFD@tzi.org> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <0772880d-be86-97df-53f2-e7a4db5bb594@it.aoyama.ac.jp> Date: Wed, 14 Feb 2018 15:26:07 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <3BB018B4-4A43-44A9-85F1-C7B565E32CFD@tzi.org> 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: TY1PR01CA0191.jpnprd01.prod.outlook.com (2603:1096:403::21) To OSAPR01MB1537.jpnprd01.prod.outlook.com (2603:1096:603:2e::16) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8c928981-7ae0-4050-390f-08d57373d5a1 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307)(7153060)(7193020); SRVR:OSAPR01MB1537; X-Microsoft-Exchange-Diagnostics: 1; OSAPR01MB1537; 3:AxrAbBP7POaYAjuj3Cqg/paEDANHq/KQFrpXUr49ps1XxOWr4/Rp7XVa4VCF6p2wMRXKLZwsbMY6N1gpgAaIRsqJopKNgT6Y9aLB7NWvBHlyKcBZovJQ4VVDFsWzIqkT+/8lgzEQ3MrTxNRreL0bUClH20Nrj0H3u51lX7NVFRZ8M25ufw1n9Dd27JCiewC/BEfx22AmpoErCaTgijXh/Ku8lbnWHbFI/+sjVCin/jayPK47VC8ieaH8DYsUIczy; 25:JojynKHYvOHZobQ3geW6wDRhGKhaCf/GCR+xKayj1QVzEov+tYUtq9g2F7RBgZ08DqPq8p8zlBz21jre/E4TfL9Bebc6nc1IWLaN4YE4qWwoa7oI4iZX5jvyGiU5owwG7vxLgCiv0lKR32NMCdHQcsFmVa8UnoXjWLD+2ZJhTy03kZdMGRIIslhoc0HskC7xf+D73iclSWm1vAempxoLO2MQOtcu10pFXaTN9f+zXgZcaEN+GydlaFSkLxc+UiFsjdNBg5Xho7PVpQkZ4OGTVZx6nuG3y5MvIiTAqZZ9Wl793EGQj2MRxGfkUGdQSyWIRJE97o7h0Im4W8iPEOiRbA==; 31:QqdEIqNtsExgEGtCskFmTbCPuh/kHX2RgS+C8Xju1ltegyZnSu9q5Tyt+zi9uz4kWGXxOxTMJsiojMzpFjc9jK2iyR5kQgY+VCPEdKGzUsQFgdF5aNjj2sfakMuXq/o72SvvpXNuYoUZMqm9FpyAUZYuj9XhezYjd4Y6h+nJs7cTHhBV6sdAG5pwlUM1OyFRtchI+cfxUoLouu8V8WlsSRy5i2QI7t8Z1jmugh/gnpo= X-MS-TrafficTypeDiagnostic: OSAPR01MB1537: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(166708455590820); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231101)(2400082)(944501161)(93006095)(93001095)(6041288)(20161123562045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:OSAPR01MB1537; BCL:0; PCL:0; RULEID:; SRVR:OSAPR01MB1537; X-Microsoft-Exchange-Diagnostics: 1; OSAPR01MB1537; 4:dUYynYUsViWr6nSwU2qWEmut6kYAfgVAI/WN236jcAcb+A14/Q4YNCaBr43PBlEt7es0RKdEvRuMWVd6Yu3mdnrfi7Ho5D97xKu1JWfglnC1acbWRnJg0H16PSxMSR3dIldmh/Abo/Fxgo2e6UL17Yagtge1ruxgkaQATRSyZpNQoHdwevzQXWDFatvdbP9/IDHWVTuTEwrBwPzyA1uZveFgveeBpcXF0VVFfLM+zux+SurdIb0Ku1tFXC+42iXTIQGqN1pDzpJ47OCdvITePikG/8KZbA44tyB5M3WL5//dIEwPvdUulosbtzhRN0F8 X-Forefront-PRVS: 0583A86C08 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(346002)(396003)(376002)(39380400002)(366004)(39840400004)(189003)(199004)(36916002)(186003)(2870700001)(5660300001)(68736007)(97736004)(7736002)(65806001)(316002)(2906002)(305945005)(16526019)(76176011)(16576012)(786003)(49976009)(50466002)(966005)(66066001)(386003)(52146003)(65956001)(47776003)(4326008)(23676004)(53546011)(26005)(59450400001)(2486003)(478600001)(52116002)(229853002)(106356001)(25786009)(6306002)(64126003)(6246003)(6486002)(8676002)(53936002)(65826007)(6116002)(2950100002)(58126008)(31686004)(81156014)(74482002)(42882006)(110136005)(81166006)(86362001)(3846002)(8936002)(105586002)(83506002)(67846002)(31696002)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OSAPR01MB1537; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPU0FQUjAxTUIxNTM3OzIzOmp0SEhENU12QzQ3OWdDSWxQbzUyciszcitP?= =?utf-8?B?Y3ZOLzFtc0NITmxHOU92eWcyTXVTdlZJVVRneTNndmNFd0pkbE1jVWw3blZO?= =?utf-8?B?cjZXR01iYk95aEVyTGFPeEVrRStoNWd2YkNKcHhyWUFHMEx3eFdNbFlsTFdC?= =?utf-8?B?aEF1SlpYYU5na2xteDVtaFN3VklNTGlOdnlzVVRBM3M2cWFEM01ibGplVUVR?= =?utf-8?B?dDZGdFFrV0JIS2tsUUhCcmp1aGE1emJJVVVmU3A5b1d2TlVUK0JJa3N5eVo0?= =?utf-8?B?Z0ltQzNDOTBlZWVXWktzRm9DWkhhTUNudE1oS1pZdzV6OGREN2x6MkdSV2hj?= =?utf-8?B?MllMWVRJRVNCMlNUQ2p2SkVZazMxNE04aFI2S1dONCtIaDNxdzlFUVorY05K?= =?utf-8?B?dXB2RmMyTTQxZGRGZlVESnZ3NjFCckZBNmdWNzdUOGRsZUtEMktvYkRjRmpS?= =?utf-8?B?aEY4bEJUU21OUnBkZUhZT1pXdVdrdHNDNmZZTWVwelUvT1QydzUzMk9zVldS?= =?utf-8?B?cnJ1ejR5MDNMMXJ4MllkOWlZM1Bab2V6Vy85ZHhuNTR5d0w3TTJPZVN5MGdC?= =?utf-8?B?cVRiQm12NmowamsxQUN1L0hwS3lBUjhZeDVVY0owTmpOSHU3bSs3a1ZIZTZK?= =?utf-8?B?c3QyMDFYU290RE54VFMzZHJvMENQakU3cTFMVjVkdlN6M2VNMlBsYWd3Ny9s?= =?utf-8?B?QlUwTDlxNlJmbjFIcHkySUFnMlJrRzh2dGRHb081V0NTNHRmVEE4Szd0YXJn?= =?utf-8?B?SXYvSGN6QVI4WlNNM2FRQkVsaUhNbG8rOStHVVpyUXFZaDhMQXdjMVZ2SUVp?= =?utf-8?B?RGNVNW9HU0NST2pRT0VDRnkrNy9qNlArNEZMV1pONFdFWEVRSXZpMGg4RmMy?= =?utf-8?B?TFcwaHZGUXdkVW1ROUpkVGpKMmM5TUlWcU1OWWhoRmo5Rjc5UEdQcDc2S3lj?= =?utf-8?B?NlluT0xVUU51N2wrS21WNDAxOFJBZ0ZXL0ppdHJVRWR0eW5wYzUyOFZwcWVm?= =?utf-8?B?WlMyclFieWlRZjJQb2lTaFl0VmZOWERMaU9LUDIwUlZieFNUelpjZGIvTi9T?= =?utf-8?B?ZXROVzVMZDFRNHltWDlSNUd5S2xaMm1CUVNFSEJLdkM1TXVhbTB3TnY3dWJv?= =?utf-8?B?VUc0cmNaS0ZFZ1hESmVzay94SmkyRG8xUWZlY3c1UGpvT1JxNWdVSGQ1MjBi?= =?utf-8?B?RnplM25pclFtK3E3dVlIaERaL1YrYXlZeHIyMGZEdlV2L1dHNlNqRWlNdjVR?= =?utf-8?B?T2theERKQmNmZ1dQd3dIaGFSU1FJZjhXMkZwT042dVZFYUsrWks2TGJ1UDRC?= =?utf-8?B?MHlxVGtESm0yL2lYOHMzME8yK0hJazdob2RyY2xQOGd3L0NnZWxHY1ZYSW1r?= =?utf-8?B?VjlqOFBSSGRRcmdrYWZyMXYrTkpzeTVXaVRLV3diT0N1cVVxc1NNV1E0VUg2?= =?utf-8?B?NWVSR2ZucnR6Sld2WlpSeHFNMkpGS2F0RDI3QkVpYnBZQTR3NUxtSnV0ZE0r?= =?utf-8?B?UG5zREk3enhQUE5xSkp5Y3E2NEVCWGF5K0FzK09zV0hNZDVyZDJpak5ucWxF?= =?utf-8?B?TjE5MmN1Q0I4bEpEdUplWUJPdWlLdUUweGh4eEFUTTA0d2R5ZTJvUWVXVG83?= =?utf-8?B?M3hkSEU1di9neXY3d2RERUlMdjFzNS9GRGRQdkNUOE5xWjdQSEhKb2dLeW5L?= =?utf-8?B?SDliRFFWbDJ6MFpxbkpyc0EyMW9ONTV1SlpGeVhHNnJmc0NoMTV5V3BYL2kx?= =?utf-8?B?emdLbzg1ZGYxQ3RBRFVtYUNTVGlpZDh1QWZCVzViZnh1Y2d3NFNoZ0V5L3pt?= =?utf-8?B?Z2VtbW9raHRNOEZ4TUh6RnpXN1VDcUFZdGJacGVkL0xOWVJjOEtmazFCK3ZT?= =?utf-8?B?czlNa3NaVWZ0MjVqeHJzWFNCelVIbEVIL0NYZk16V1VNWjBGNUUrd25DM25Q?= =?utf-8?B?UDN0YVE3RmJzSGMzS1FZNmpkb1BtVlM1SS9BekpBUytqRS9IMlh5aXVleW9n?= =?utf-8?B?ZTJkbUJCekZkU05EcXZuQmUrQ0RuQ2JJRU5VNThJUi82dGJtRE43QnJoT0dt?= =?utf-8?Q?fgvo=3D?= X-Microsoft-Exchange-Diagnostics: 1; OSAPR01MB1537; 6:bTwMzf5qyLL50ovGTCXVML+WuCW9/dNvXs6V/1R/kIhl62Z0NG9/a/pTef05Rizmd/xb8jJhh/AtBz2lR0rD5J4ZL4szSstoqJZCole/my0V27cEO0cxbO3H37YavDEWKmpLZu6In0JZZ4AZ/4aRGjpuznvEEN1xpP8P+VmyP92Bb68sHcZdYvBwV9erkozAsLTAtjxZ6qHy7e8D3W8/yxs9CpzoQrcXNI3C8rTOA8LMqgVlsKijTe+nZouG98tn4udwBEJMqIRBIM2cXIdftgi81MTUgnNWhWOB8nssq4GBK6NPGOXvR/TLL5IqeuiFajQHKvV5zIhHJNZeIun1yMKGRaVmPlms8cw/+qWiDyY=; 5:4tfP2edca84If7x8n/2XVK9JsND/Osw4zx6O3plHEgWLQ6r9hC13h68A1yXzpPfCgvQyYKvFHFaWqHvmTuAP1d7kYwnMgqP0hE2hoQrn35PjtLBoiXu3gisT0EPKJ9/tPqy503t6SohghP2AqdS5tj5LiSsdvef5WRNpT2OKuUY=; 24:T+UQqXpRgiRkfvJgFEqI4beL8w+N3u7X1LZzqkOi4kj85GCmwEOruTgjj9Ntojiv1rmuo+09PIMA+2BNlwgr7NoK4hMtDfkr3kfWqk2K96M=; 7:tNx1NgYoCPXhFrjISRj+kycOmcNUmD+IGJ5a3ZechEwM/XIhdI5J4+tV964WvmUMBSjVxCRuB3gF1iS0DF85y2Rg1bxEq9ii0zhC+SCMl7Vvyr5M2nxcstV4r7+/aXh9xeHMnNHnf0HZj6MamZ5bWycZjKKEy+aldO74RiYp05XxqM9U09v9z1yeBYATGpBQwMSZLTR/oK8xMgAzcQP3WYLnXUqCB7e5371huThPgbd1JLa9gf/0nYRlZrl3ROke SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Feb 2018 06:26:08.3151 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8c928981-7ae0-4050-390f-08d57373d5a1 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSAPR01MB1537 Archived-At: Subject: Re: [xml2rfc-dev] Non-ASCII punctuation X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.22 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, 14 Feb 2018 06:26:15 -0000 Hi Heather, others, I was predicting (on this or a related mailing list I think) that this issue would turn up sooner or later. It was unavoidable, and easy to predict given that already before the 'modern' (incl. non-ASCII) RFCs, one occasionally saw Internet Drafts with 'smart' quotes. On 2018/02/14 06:15, Carsten Bormann wrote: > Hi Heather, > > I own a hardbound *book* that is entirely about quotation marks. Can you give us a pointer? > It is a fun subject… > For a starter: > https://en.wikipedia.org/wiki/Quotation_mark#Summary_table > > Kramdown-rfc generates “smart quotes” (i.e. typographically correct quotes, just as in this email) because, at the time I wrote the code, that setting just was the default, and I didn’t have to change it as xml2rfc happily converts typographic quotes into the typewriter quotes that ASCII offers. So unless the author changes the settings (search for smart_quotes or 1.0.31 in https://github.com/cabo/kramdown-rfc2629), they get the characters that are called ldquo and rdquo (or lsquo/rsquo) in HTML. I never changed this because the HTML generated from these XML files just reads better. > > I would expect at least some other tools to output XML with typographically correct quotes, as well, so any prep tool for RFCXMLv3 would need to handle them. By the way, similar considerations apply to other basic typographical characters such as dashes, hyphens, ellipses. > > Obviously, RFCs can opt to side with ASCII on the typographic features of the English language even on the XML side, as xml2rfc has been doing for the TXT final form for a long time now. If you want to go that way, that should not be a submission setting, but a post-preptool distribution setting. (I personally don’t understand why we would need to do this, as XML is perfectly capable of handling basic typographic features as is HTML. But it may still be the right thing for formatting to TXT, as it is done now.) I think it's a bit more difficult than that. It is important to realize that RFCs often contain program text, and program text easily contains a few quotes, and these quotes have to be straight quotes, not typographic ones. On the other hand, many authors and editors won't use typographic quotes, but if the RFC editor wants to keep a consistent style, it would want to use typographic quotes in all RFCs where appropriate (i.e. for actual quotations, not strings in programs). Getting that right would in my opinion be worth-while, but it's important to understand that it's something that will require a significant effort by the RFC production center. > It becomes interesting when people start using non-English variants of quotes (e.g., the German left and right quotes, where the German right quote is identical in many fonts to the English left quote, but we use a lowered left quote). > That is not going to work well with English text. > Guillemets (“angle quotes”) are a boundary case, but probably should not be accepted either (they are rarely used in English, and they have inverse roles in French and Swiss vs. German German typography). At first approximation, there should be no need for these in RFCs. RFCs are English, so they should use English quotes. Citations from French or German including quotes should be exceedingly rare. > I’m not going to start talking about thin spaces, but these also need to be handled reasonably. And hyphens, and probably a few more things like this. Regards, Martin. > Grüße, Carsten > > PS.: Apple’s spelling dictionary “autocorrects” Guillemets into birds (Guillemots) — even Adobe fell for this malapropism, and Wikipedia outright says “they are not used in the English language”. Yeah right. From nobody Wed Feb 14 01:47: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 C6F96127275 for ; Wed, 14 Feb 2018 01:47:40 -0800 (PST) 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 0luaAlOOtHMl for ; Wed, 14 Feb 2018 01:47:38 -0800 (PST) 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 65078126CF9 for ; Wed, 14 Feb 2018 01:47:38 -0800 (PST) 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 w1E9lYcu024866; Wed, 14 Feb 2018 10:47:34 +0100 (CET) Received: from [192.168.217.102] (p5DC7EAF5.dip0.t-ipconnect.de [93.199.234.245]) (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 3zhF1y35gKzDWyL; Wed, 14 Feb 2018 10:47:34 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: <0772880d-be86-97df-53f2-e7a4db5bb594@it.aoyama.ac.jp> Date: Wed, 14 Feb 2018 10:47:33 +0100 Cc: "Heather Flanagan (RFC Series Editor)" , xml2rfc-dev@ietf.org X-Mao-Original-Outgoing-Id: 540294451.9096971-6f291490f7adf5c7478f01b0356ed97b Content-Transfer-Encoding: quoted-printable Message-Id: References: <01ea01d3a4f2$3187ca60$94975f20$@augustcellars.com> <3BB018B4-4A43-44A9-85F1-C7B565E32CFD@tzi.org> <0772880d-be86-97df-53f2-e7a4db5bb594@it.aoyama.ac.jp> To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [xml2rfc-dev] Non-ASCII punctuation X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.22 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, 14 Feb 2018 09:47:41 -0000 On Feb 14, 2018, at 07:26, Martin J. D=C3=BCrst = wrote: >=20 > Hi Heather, others, >=20 > I was predicting (on this or a related mailing list I think) that this = issue would turn up sooner or later. It was unavoidable, and easy to = predict given that already before the 'modern' (incl. non-ASCII) RFCs, = one occasionally saw Internet Drafts with 'smart' quotes. >=20 > On 2018/02/14 06:15, Carsten Bormann wrote: >> Hi Heather, >> I own a hardbound *book* that is entirely about quotation marks. >=20 > Can you give us a pointer? Oh, I'd have to dig that one up. (I used it in the process of preparing = my PhD thesis, so it has been a while.) > I think it's a bit more difficult than that. It is important to = realize that RFCs often contain program text, and program text easily = contains a few quotes, and these quotes have to be straight quotes, not = typographic ones. Right, that=E2=80=99s why it is a good idea to support this right from = the authoring level. (If the author used markdown as intended, it all just works out right = with very few exceptions.) > On the other hand, many authors and editors won=E2=80=99t use = typographic quotes, but if the RFC editor wants to keep a consistent = style, it would want to use typographic quotes in all RFCs where = appropriate (i.e. for actual quotations, not strings in programs). Not sure we need this level of consistency across all RFCs. If authors = want to go for typographic quotes (manually or using tools that handle = these for them), let them, but don=E2=80=99t force them on authors that = couldn=E2=80=99t care less. Again, that=E2=80=99s why it is a good = thing to support this on the authoring level. > Getting that right would in my opinion be worth-while, but it=E2=80=99s = important to understand that it's something that will require a = significant effort by the RFC production center. (A few scripts can probably be written that will catch almost all errors = an author can make here, with a small false-positive rate.) >> It becomes interesting when people start using non-English variants = of quotes (e.g., the German left and right quotes, where the German = right quote is identical in many fonts to the English left quote, but we = use a lowered left quote). >> That is not going to work well with English text. >> Guillemets (=E2=80=9Cangle quotes=E2=80=9D) are a boundary case, but = probably should not be accepted either (they are rarely used in English, = and they have inverse roles in French and Swiss vs. German German = typography). >=20 > At first approximation, there should be no need for these in RFCs. = RFCs are English, so they should use English quotes. Citations from = French or German including quotes should be exceedingly rare. Right. (More so for Chinese, Japanese, Korean, Thai=E2=80=A6). So I was = focusing on the English usage. (Oh, and there are at least two of these, with the British often = exchanging the role of double and single quotes, starting around the = 1960s. Once more, best handled at the authoring level.) >> I=E2=80=99m not going to start talking about thin spaces, but these = also need to be handled reasonably. >=20 > And hyphens, and probably a few more things like this. And dashes, ellipses, =E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Feb 14 09:17: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 5FC3212D77E for ; Wed, 14 Feb 2018 09:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 mac7k2PYBeCV for ; Wed, 14 Feb 2018 09:17:20 -0800 (PST) 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 0DCFD126CE8 for ; Wed, 14 Feb 2018 09:17:20 -0800 (PST) Received: from Jude (100.44.187.196) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 14 Feb 2018 09:15:28 -0800 From: Jim Schaad To: 'Carsten Bormann' , =?utf-8?Q?'=22Martin_J._D=C3=BCrst=22'?= CC: References: <01ea01d3a4f2$3187ca60$94975f20$@augustcellars.com> <3BB018B4-4A43-44A9-85F1-C7B565E32CFD@tzi.org> <0772880d-be86-97df-53f2-e7a4db5bb594@it.aoyama.ac.jp> In-Reply-To: Date: Wed, 14 Feb 2018 09:17:05 -0800 Message-ID: <004601d3a5b7$a5499ee0$efdcdca0$@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: AQHlDMUeu3uIoqsmlvhVxuhIAcuvSQJOtiqTAsCNJz0BwM3viAHYYAl2ozwRx/A= Content-Language: en-us X-Originating-IP: [100.44.187.196] Archived-At: Subject: Re: [xml2rfc-dev] Non-ASCII punctuation X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.22 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, 14 Feb 2018 17:17:22 -0000 > -----Original Message----- > From: xml2rfc-dev [mailto:xml2rfc-dev-bounces@ietf.org] On Behalf Of > Carsten Bormann > Sent: Wednesday, February 14, 2018 1:48 AM > To: "Martin J. D=C3=BCrst" > Cc: xml2rfc-dev@ietf.org > Subject: Re: [xml2rfc-dev] Non-ASCII punctuation >=20 > On Feb 14, 2018, at 07:26, Martin J. D=C3=BCrst = wrote: > > > > Hi Heather, others, > > > > I was predicting (on this or a related mailing list I think) that = this issue would > turn up sooner or later. It was unavoidable, and easy to predict given = that > already before the 'modern' (incl. non-ASCII) RFCs, one occasionally = saw > Internet Drafts with 'smart' quotes. > > > > On 2018/02/14 06:15, Carsten Bormann wrote: > >> Hi Heather, > >> I own a hardbound *book* that is entirely about quotation marks. > > > > Can you give us a pointer? >=20 > Oh, I'd have to dig that one up. (I used it in the process of = preparing my PhD > thesis, so it has been a while.) >=20 > > I think it's a bit more difficult than that. It is important to = realize that RFCs > often contain program text, and program text easily contains a few = quotes, > and these quotes have to be straight quotes, not typographic ones. >=20 > Right, that=E2=80=99s why it is a good idea to support this right from = the authoring > level. > (If the author used markdown as intended, it all just works out right = with > very few exceptions.) >=20 > > On the other hand, many authors and editors won=E2=80=99t use = typographic > quotes, but if the RFC editor wants to keep a consistent style, it = would want > to use typographic quotes in all RFCs where appropriate (i.e. for = actual > quotations, not strings in programs). >=20 > Not sure we need this level of consistency across all RFCs. If = authors want to > go for typographic quotes (manually or using tools that handle these = for > them), let them, but don=E2=80=99t force them on authors that = couldn=E2=80=99t care less. > Again, that=E2=80=99s why it is a good thing to support this on the = authoring level. >=20 > > Getting that right would in my opinion be worth-while, but = it=E2=80=99s important to > understand that it's something that will require a significant effort = by the RFC > production center. >=20 > (A few scripts can probably be written that will catch almost all = errors an > author can make here, with a small false-positive rate.) >=20 > >> It becomes interesting when people start using non-English variants = of > quotes (e.g., the German left and right quotes, where the German right > quote is identical in many fonts to the English left quote, but we use = a > lowered left quote). > >> That is not going to work well with English text. > >> Guillemets (=E2=80=9Cangle quotes=E2=80=9D) are a boundary case, = but probably should not > be accepted either (they are rarely used in English, and they have = inverse > roles in French and Swiss vs. German German typography). > > > > At first approximation, there should be no need for these in RFCs. = RFCs are > English, so they should use English quotes. Citations from French or = German > including quotes should be exceedingly rare. >=20 > Right. (More so for Chinese, Japanese, Korean, Thai=E2=80=A6). So I = was focusing on > the English usage. > (Oh, and there are at least two of these, with the British often = exchanging > the role of double and single quotes, starting around the 1960s. Once = more, > best handled at the authoring level.) >=20 > >> I=E2=80=99m not going to start talking about thin spaces, but these = also need to be > handled reasonably. > > > > And hyphens, and probably a few more things like this. >=20 > And dashes, ellipses, =E2=80=A6 A good place to start with the list of interesting symbols is the v2 = xml2rfc code. Between it and the DTD it references there is a list of = entities that are going to be converted from the Unicode into ASCII = text. Jim >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc-dev From nobody Mon Feb 26 14:23: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 F2C49126C2F for ; Mon, 26 Feb 2018 14:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 sECeJjygsojs for ; Mon, 26 Feb 2018 14:23:52 -0800 (PST) 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 BB5561200B9 for ; Mon, 26 Feb 2018 14:23:51 -0800 (PST) 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; Mon, 26 Feb 2018 14:22:02 -0800 From: Jim Schaad To: Date: Mon, 26 Feb 2018 14:23:43 -0800 Message-ID: <022c01d3af50$77aa4b90$66fee2b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdOvT6QdkoAtZCwvRLaJjNEMAuKPxg== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [xml2rfc-dev] preserve space and artwork X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.22 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, 26 Feb 2018 22:23:53 -0000 In writing some test cases I got a surprise because what I was planning to use for detection of the need to deal with preserving spaces in artwork was not there. For the v2 grammar there was a default attribute of xml:space="preserve" on the artwork element. With the new RNG grammar this is no longer the case. I am unsure of how this would affect XSLT, but it appears that I need to make sure that whitespace handling is done differently based on the element name. Is this expected behavior - that the program needs to know when to preserve whitespace - or should there be something that will set the xml:space attribute on the appropriate nodes? Specifically is this a requirement of document authors. Jim From nobody Mon Feb 26 22:39: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 CBD3E120727 for ; Mon, 26 Feb 2018 22:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 WdIjyPjp7RH2 for ; Mon, 26 Feb 2018 22:39:13 -0800 (PST) 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 441281200B9 for ; Mon, 26 Feb 2018 22:39:12 -0800 (PST) Received: from [192.168.178.20] ([93.217.125.225]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Ld4xA-1ePzVw0Ys4-00iBqx; Tue, 27 Feb 2018 07:38:32 +0100 To: Jim Schaad , xml2rfc-dev@ietf.org References: <022c01d3af50$77aa4b90$66fee2b0$@augustcellars.com> From: Julian Reschke Message-ID: Date: Tue, 27 Feb 2018 07:38:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <022c01d3af50$77aa4b90$66fee2b0$@augustcellars.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:42kUkulxs8pwkcLDLNvm3xQ0wbhepnvpD2jkU2RwKGMmhRw5xSi 3ow9O7Z9nKs1hozCGfuevwuVmwhXse8Bls39aaHbvUe9Y5IS4unDkmC0irn0CxGFJXmfU3d XsgNEDPCzc3Vcrxr81S+9IoFTNLQCEiLDo3mKLGvELZBTMLopP30MNji8gHFfALY+U1P5sD eujIuwp2yFGq+Bh0vdzVA== X-UI-Out-Filterresults: notjunk:1;V01:K0:U4BY1TfPRJ0=:YHI/Zo+8yNhQxi5iPMjWXZ 99q65t7ID+DfZ2gg9V/OBgZjs9bJeK8TXQ/dVwBDgJnpsPbSlZ6BaVeI7fQW3/eNsv6srAUTs GWTPvPYDWTPf9rjN3kw+9iUjvETGnCIX0ZKe+lKrEHTXqXo1ubpY4BMv+3voQ1X93yML+55Tg Pl5EbyG48AlZTbhE5kx9zn/aCCMvJVS+jZtgZDWX/QFWl1vtB1Ljrfi7O54yzdu5TwK+KqyIx L1TXBG7yAVdhyJWFyceU1cTC1sj8Yq1i6sOyaozyr3NZs1RJWimoDc80kyLCa3dVDf51mal9l Vb9Cs0JTkAOYb+cbBCRmMMDrWFXCDEMZN/wcPFjARLsTu0SzORkQraJvQB8pwFw3/KwSxNZdR D6eyNZ8tuwEXX/hjmbc1T2QNZcNF9qge4L0rTPSGRuoDB/tLXIKQrz7+pQzW6E0Imn5HBi8p6 artwSCa1XmVEtyqb10uHXUV3Xbio2einvNAza6yOfH1iQkIUxA+ML8vp39JlryAoO9knM8enk DMu1qPIzoFUqQsKZJ6eiA0mXGFyl7WBIk9K4cI5ZZrChHQBnMGiIYKtn/QVRfK3qTMft3HXGa 3WlBk3BhMOgmh8lX+mzEb0xCWi6iWojWvYyEl7NT7QDrSTzqtu4jbFMkW0K5DJetoqQDXezuG zS4kYQdpSZzwnfK0KOM3TczM6W2/Nn1hUCSjjhnd7jPMHOaI/Mb+NN4xLhISbKFR5UIA/vFf5 RP17yaZnf5X7QLCD+W/KSwCVp8T813FOnNoVLtPm4JdAfxx+IMOFCaw2Iz2ngHDfC0bXAqgyH 601e0KUgf24gMz7af2XvUz9x8fQWmxWUxCCvLyGLzN6J2en4zc= Archived-At: Subject: Re: [xml2rfc-dev] preserve space and artwork X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.22 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, 27 Feb 2018 06:39:15 -0000 On 2018-02-26 23:23, Jim Schaad wrote: > In writing some test cases I got a surprise because what I was planning to > use for detection of the need to deal with preserving spaces in artwork was > not there. For the v2 grammar there was a default attribute of > xml:space="preserve" on the artwork element. With the new RNG grammar this > is no longer the case. I am unsure of how this would affect XSLT, but it > appears that I need to make sure that whitespace handling is done > differently based on the element name. Yes, and this really isn't a change. Even back in DTD times, a document would need to be processed correctly in absence of xml:space. On the other hand, putting xml:space=preserve anywhere else never had an effect. > ... Best regards, Julian From nobody Tue Feb 27 09:57: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 7DB1E127201 for ; Tue, 27 Feb 2018 09:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 f7LguA1PPSYp for ; Tue, 27 Feb 2018 09:57:51 -0800 (PST) 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 496BF126C26 for ; Tue, 27 Feb 2018 09:57:51 -0800 (PST) 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; Tue, 27 Feb 2018 09:56:01 -0800 From: Jim Schaad To: 'Julian Reschke' , References: <022c01d3af50$77aa4b90$66fee2b0$@augustcellars.com> In-Reply-To: Date: Tue, 27 Feb 2018 09:57:43 -0800 Message-ID: <028e01d3aff4$794173d0$6bc45b70$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQHPQqc8L1nErPxkqyYfbigXDXiZ3QK38zY4o6ujvZA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [xml2rfc-dev] preserve space and artwork X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.22 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, 27 Feb 2018 17:57:53 -0000 > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Monday, February 26, 2018 10:39 PM > To: Jim Schaad ; xml2rfc-dev@ietf.org > Subject: Re: [xml2rfc-dev] preserve space and artwork >=20 > On 2018-02-26 23:23, Jim Schaad wrote: > > In writing some test cases I got a surprise because what I was > > planning to use for detection of the need to deal with preserving > > spaces in artwork was not there. For the v2 grammar there was a > > default attribute of xml:space=3D"preserve" on the artwork element. > > With the new RNG grammar this is no longer the case. I am unsure of > > how this would affect XSLT, but it appears that I need to make sure > > that whitespace handling is done differently based on the element = name. >=20 > Yes, and this really isn't a change. Even back in DTD times, a = document would > need to be processed correctly in absence of xml:space. Yes, but in the DTD times, the DTD would provide that attribute so when = I was comparing v2 to v3 documents it was working correctly. It started = failing when I was comparing v3 to v3 documents. However I have patched = my code. Jim >=20 > On the other hand, putting xml:space=3Dpreserve anywhere else never = had an > effect. >=20 > > ... >=20 > Best regards, Julian From nobody Tue Feb 27 10:12: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 E622E126CD6 for ; Tue, 27 Feb 2018 10:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 f5mB0G0Q5i5Z for ; Tue, 27 Feb 2018 10:12:54 -0800 (PST) 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 5B661120726 for ; Tue, 27 Feb 2018 10:12:54 -0800 (PST) Received: from [192.168.178.20] ([93.217.125.225]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lxgnf-1efwth2347-017EBe; Tue, 27 Feb 2018 19:12:22 +0100 To: Jim Schaad , xml2rfc-dev@ietf.org References: <022c01d3af50$77aa4b90$66fee2b0$@augustcellars.com> <028e01d3aff4$794173d0$6bc45b70$@augustcellars.com> From: Julian Reschke Message-ID: <041356d5-da9c-ac01-5719-e43472827da2@gmx.de> Date: Tue, 27 Feb 2018 19:12:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <028e01d3aff4$794173d0$6bc45b70$@augustcellars.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:q184D1Qkyz0MVAAePpLHCNwKFKQAiHmWbTB8tOwEPmIQnujfJ/h 8mJD2YP9vkYJt9L0tX6MRaF5fxZvWtQ7bAb/7QeZvTR8F4yjiU1pugakzdAI5EXsu7hXmoR fBR0GpYW3E4JZFGjcX2tCTGU8Ky4ReM6ICmx6nUlKiJ7bC3pZEm49duzeA8KCbecnpmUhi1 K634xlanheAvfj3HoaI5Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:GdPvk0QTd9Y=:dh5QtZBXqhneM1ni4d7I/7 x4Bj3gQdRMwFPzH6/fYS7VucOoImlL31wlgXK3sRUN/zoYyCcGENj+wJZ6ZeSF+LX5FmwybA3 j4kDwT5NAmh0gEB/0wQ40jZZeIN3gjjF59urUuuqfaGHvzRFntgErihDa9bNy6L8a1ddS29uN XQcusZ23Iez+5O9yds1BVB1w03+5w3wKtt1VqnEZIWDG0JuLLU4h761Uyduhr7vIE/JrpwY1i hLq+An2btHWMvwC/b2aIZdS7Q0IX6xfm+T3cFSrmpB/iQeqK3Hy3we3bw6EIqf3gEWvRXSMl3 HIIlZhOkV21ojq6hgFz+5YTTmwCQhqFYcw48X6ZnDTN+yEUboW9f7si+Oku5S9M9oFfhYjJSF DwoIeLdJwmeePFEcjXD603RIxQUlDtFkjB7TD44NsnyzdjEsDDtXv0nao/e0Ss1ZdcPWIIQlU dgbuwM9kOxYzgWexx8DoPvfQ59FTQ2vEp/itFo4tqCvPm1QvBMmsd8aQa9g6OoMgASlzYlmcg gQPJcN4/nqb/6BCekyAJ2SB6sDq/dAs8t5Vw8TYaPC5dOINMjnomi5y+T0QRkfxkp/GLlYZW5 sL7UZxkf66Tcg9TWEAN6gfURk5TVeboxdrVMrWzvN9EJpzYgNNuA4eTACDTzSl80F+zItwjbS 6XdYe5D8sLMv3CHP6XSuyW/8w4VKeenzRhstXHHiImm66E2KYzcnBJ7pq7p3y8UPyHLx1kGOE MKO/xEr4HfLzFKxEEVVAOa8QepS6mlSAcCeiupOG2S7gwMIV6GTPurRt2g83fuJ+/Nv74D9m7 NTgUeVd7rj43DrEDKsYMl03EXVKK1loNFkEeqQxkaGv2QRNYp8= Archived-At: Subject: Re: [xml2rfc-dev] preserve space and artwork X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.22 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, 27 Feb 2018 18:12:56 -0000 On 2018-02-27 18:57, Jim Schaad wrote: > ... > Yes, but in the DTD times, the DTD would provide that attribute so when I was comparing v2 to v3 documents it was working correctly. It started failing when I was comparing v3 to v3 documents. However I have patched my code. > ... Even for v2, the DTD was truly optional. The processor just needs to know that has different whitespace rules. Best regards, Julian