Re: [Tools-discuss] [rfc-i] Update: The transition to xml2rfc v3 (today!) (fwd) Heather Flanagan: Update: The transition to xml2rfc v3 (today!)

Dave Rice <dave@dericed.com> Mon, 21 October 2019 16:15 UTC

Return-Path: <dave@dericed.com>
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37361200B6 for <tools-discuss@ietfa.amsl.com>; Mon, 21 Oct 2019 09:15:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.119
X-Spam-Level:
X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] 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 I84xhmkMXrC2 for <tools-discuss@ietfa.amsl.com>; Mon, 21 Oct 2019 09:14:59 -0700 (PDT)
Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (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 E504E120089 for <tools-discuss@ietf.org>; Mon, 21 Oct 2019 09:14:58 -0700 (PDT)
Received: from [146.96.19.240] (port=40594 helo=[10.10.201.23]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <dave@dericed.com>) id 1iMaKa-002zQi-7J; Mon, 21 Oct 2019 12:14:57 -0400
From: Dave Rice <dave@dericed.com>
Message-Id: <CB32A50B-D6F2-41C4-8AC7-750E35F4941D@dericed.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B20C7190-BE01-4B9F-9E1E-3DFEF488C1CF"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Mon, 21 Oct 2019 12:14:46 -0400
In-Reply-To: <06122b6d-d5f9-30b9-2db4-a2427d299a1f@levkowetz.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, rfc-interest <rfc-interest@rfc-editor.org>, tools-discuss@ietf.org
To: Henrik Levkowetz <henrik@levkowetz.com>
References: <20285.1568652805@localhost> <705AA16B-68B1-4B5E-AE47-0714F6781C1A@dericed.com> <26105.1568818137@localhost> <E70CD0FF-0294-47E5-873F-5E184A248577@dericed.com> <1268.1568828850@localhost> <B4047303-E2B9-4B9D-B368-2ACC85A06D15@dericed.com> <15814.1569013442@localhost> <3a8f5865-9f5c-8c65-63be-bca31c5f1c86@levkowetz.com> <3650B5EF-A442-4291-928A-2FCB2144134C@dericed.com> <06122b6d-d5f9-30b9-2db4-a2427d299a1f@levkowetz.com>
X-Mailer: Apple Mail (2.3445.104.8)
X-OutGoing-Spam-Status: No, score=-2.6
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server172.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - dericed.com
X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com
X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-discuss/seyKMr5seqaDiaaAuO2fse-2fW4>
X-Mailman-Approved-At: Mon, 21 Oct 2019 09:33:55 -0700
Subject: Re: [Tools-discuss] [rfc-i] Update: The transition to xml2rfc v3 (today!) (fwd) Heather Flanagan: Update: The transition to xml2rfc v3 (today!)
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion <tools-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-discuss/>
List-Post: <mailto:tools-discuss@ietf.org>
List-Help: <mailto:tools-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Oct 2019 16:15:02 -0000

Hi all,

> On Oct 9, 2019, at 1:38 PM, Henrik Levkowetz <henrik@levkowetz.com> wrote:
> 
> Hi David,
> 
> On 2019-10-09 17:32, Dave Rice wrote:
>> Thanks Henrik,
>> 
>>> On Sep 20, 2019, at 5:26 PM, Henrik Levkowetz <henrik@levkowetz.com> wrote:
>>> 
>>> Hi Michael, David,
>>> 
>>> On 2019-09-20 23:04, Michael Richardson wrote:
>>>> 
>>>> Dave Rice <dave@dericed.com> wrote:
>>>>> Another annoyance here is the the xml processor in the submission tool
>>>>> and the xml processor at
>>>>> https://xml2rfc.tools.ietf.org/experimental.html
>>>>> <https://xml2rfc.tools.ietf.org/experimental.html> perform differently,
>>>>> so there’s effectively no test environment to use before submitting.
>>>>> Dave
>>>> 
>>>> Dave, can you please try xml2rfc.ietf.org, which is a different installation,
>>>> supported by a different entity?
>>> 
>>> Michael:  Umm, no, that redirects to tools.ietf.org, too, and the processor
>>> behind that, and behind https://xml2rfc.tools.ietf.org/experimental.html,
>>> _and_ behind the submission tool are all the latest release of xml2rfc.
>>> 
>>> David: I'd be happy to look into any discrepancies you see, but I can only
>>> do so if you provide observations and input XML files for me to work
>>> with.  It won't happen if I don't know about it :-)
>> 
> 
>> When I use the tool at https://xml2rfc.tools.ietf.org or
>> https://xml2rfc.tools.ietf.org/experimental.html, the plain text
>> output appears ok, but when I use
>> https://datatracker.ietf.org/submit/
>> <https://datatracker.ietf.org/submit/ <https://datatracker.ietf.org/submit/>>, the contents of the
>> <sourcecode> elements (which are new in xml2rfc version 3) have their
>> line breaks stripped out and thus cause an error when the line length
>> limits are exceeded.
> 
> That sounds like a bug.
> 
>> For the moment, I’m proposing a find and replace to convert the newer
>> <sourcecode> elements back to <artwork> elements as in
>> https://github.com/FFmpeg/FFV1/pull/171/commits/a018f091534678f45cc157bfd154518ad6267c7e <https://github.com/FFmpeg/FFV1/pull/171/commits/a018f091534678f45cc157bfd154518ad6267c7e>
>> <https://github.com/FFmpeg/FFV1/pull/171/commits/a018f091534678f45cc157bfd154518ad6267c7e <https://github.com/FFmpeg/FFV1/pull/171/commits/a018f091534678f45cc157bfd154518ad6267c7e>>,
>> thus an xml2rfc version 2 processor or version 3 processor should
>> proceed accurate results though not as semantically clear in the
>> xml.
>> 
>>> FWIW, if you have a tools.ietf.org <http://tools.ietf.org/> login, you can use the xml2rfc
>>> issue
>>> tracker at https://trac.tools.ietf.org/tools/xml2rfc/trac/newticket <https://trac.tools.ietf.org/tools/xml2rfc/trac/newticket>, for
>>> xml2rfc issues, and https://trac.tools.ietf.org/tools/ietfdb/newticket <https://trac.tools.ietf.org/tools/ietfdb/newticket>
>>> for datatracker issues.
>> 
>> I don’t have a login, but I’ll see if I can make a tiny test file for this issue and file a concise ticket.
> 
> Please don't put time into this; I'm perfectly happy to work from the xml
> file you found problematic on submission.  Just let me know the name of the
> draft in question, so I can pull it.


I just uploaded this new version of the EBML specification to the datatracker.


On lines 559-609 and 824-939 there are <sourcecode> nodes that contain multi-line xml expressions. During the upload the idnit test showed no issues or nits at all.  However in the resulting files at https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/12/ <https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/12/> the outputs remove the line-breaks of the multi-line xml within the <sourcecode> nodes. So in the HTML version the <sourcecode> is shown as a single line, see https://www.ietf.org/id/draft-ietf-cellar-ebml-12.html#name-ebml-schema-example <https://www.ietf.org/id/draft-ietf-cellar-ebml-12.html#name-ebml-schema-example>, and in the plain text as well, see Section 11.1.1 of https://www.ietf.org/id/draft-ietf-cellar-ebml-12.txt <https://www.ietf.org/id/draft-ietf-cellar-ebml-12.txt>.

In another document, I have been find/replacing the <sourcecode> node with the older <artwork> node as a workaround.

Best Regards,

Dave Rice