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

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 9 Oct 2019 19:38:31 +0200

Hi David,

On 2019-10-09 17:32, Dave Rice wrote:
> Thanks Henrik,
> 
>> On Sep 20, 2019, at 5:26 PM, Henrik Levkowetz <[email-masked]> wrote:
>> 
>> Hi Michael, David,
>> 
>> On 2019-09-20 23:04, Michael Richardson wrote:
>>> 
>>> Dave Rice <[email-masked]> 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/>, 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>,
> 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 login, you can use the xml2rfc
>> issue
>> tracker at https://trac.tools.ietf.org/tools/xml2rfc/trac/newticket, for
>> xml2rfc issues, and 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.

Best regards,

	Henrik

_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Dave Rice <[email-masked]>
Date: Wed, 9 Oct 2019 11:32:42 -0400

Thanks Henrik,

> 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/>, 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.

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>, 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 login, you can use the xml2rfc issue

---

From: Dave Rice <[email-masked]>
Date: Wed, 9 Oct 2019 13:47:18 -0400

Hi Henrik,

> On Oct 9, 2019, at 1:38 PM, Henrik Levkowetz <[email-masked]> wrote:
> 
> Hi David,
> 
>> <https://datatracker.ietf.org/submit/ <https://datatracker.ietf.org/submit/>>, the contents of the
>> 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>>,
>>> 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.
>> 

The draft at https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ <https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/>. The current version, 09, has several sections where the content of <sourcecode> elements exceed the line length in txt renderings, such as in https://www.ietf.org/id/draft-ietf-cellar-ffv1-09.txt <https://www.ietf.org/id/draft-ietf-cellar-ffv1-09.txt>.

For example, this in the xml:

> <section anchor="level-coding">
>               <name>Level Coding</name>
>               <t>Level coding is identical to the normal difference coding with the exception that the 0 value is removed as it cannot occur:</t>
>               <sourcecode type="c">    diff = get_vlc_symbol(context_state);
>     if (diff &gt;= 0) {
>         diff++;
>     }
> </sourcecode>
>               <t>Note, this is different from JPEG-LS, which doesn’t use prediction in run mode and uses a different encoding and context model for the last difference On a small set of test <tt>Samples</tt> the use of prediction slightly improved the compression rate.</t>
>             </section>

will become this in the output txt:
> 3.8.2.2.2.  Level Coding
> 
>    Level coding is identical to the normal difference coding with the
>    exception that the 0 value is removed as it cannot occur:
> 
>    diff = get_vlc_symbol(context_state); if (diff >= 0) { diff++; }
> 
>    Note, this is different from JPEG-LS, which doesn't use prediction in
>    run mode and uses a different encoding and context model for the last
> 
> 
> 
> Niedermayer, et al.       Expires March 9, 2020                [Page 21]
> 
> Internet-Draft                    FFV1                    September 2019
> 
> 
>    difference On a small set of test "Samples" the use of prediction
>    slightly improved the compression rate.

I’m adding underlines to these to show where the line returns are lost. In this case it doesn’t result in exceeding the line length but in most it does. I can workaround this issue by change the <sourcecode type=“c"> element to <artwork type=“ascii-art”>.

Dave Rice

---

From: Dave Rice <[email-masked]>
Date: Mon, 21 Oct 2019 12:14:46 -0400

Hi all,

> 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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 21 Oct 2019 18:46:12 +0200

On 21.10.2019 18:14, Dave Rice wrote:
> Hi all,
>
>> On Oct 9, 2019, at 1:38 PM, Henrik Levkowetz <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Hi David,
>>
>>>> On Sep 20, 2019, at 5:26 PM, Henrik Levkowetz <[email-masked]
>>>> <mailto:[email-masked]>> wrote:
>>>>
>>>> Hi Michael, David,
>>>>
>>>>> Dave Rice <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> Dave, can you please try xml2rfc.ietf.org
>>>>> <http://xml2rfc.ietf.org>, which is a different installation,
>>>> Michael:  Umm, no, that redirects to tools.ietf.org
>>>> <http://tools.ietf.org>, too, and the processor
>>>> behind that, and behind
>>>> https://xml2rfc.tools.ietf.org/experimental.html,
>>>> FWIW, if you have atools.ietf.org <http://tools.ietf.org/>login, you
>>>> can use the xml2rfc
>>>> issue
>>>> tracker athttps://trac.tools.ietf.org/tools/xml2rfc/trac/newticket, for
>>>> xml2rfc issues, andhttps://trac.tools.ietf.org/tools/ietfdb/newticket
>>>> for datatracker issues.
>>>
> 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/ 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,
> and in the plain text as well, see Section 11.1.1 of
> 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
> ...

I had the same problem and reported it as
<https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/444>.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 25 Oct 2019 08:16:45 +0200

> <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/444>.

Henrik,

could you please let us know what the status is? Does it make sense to
retry now?

Best regards, Julian