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

Hi Henrik,

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

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