Subject: [xml2rfc] #332 (Version 2 cli): Getting error at column 33851 ...

From: "xml2rfc issue tracker" <[email-masked]>
Date: Mon, 12 Jun 2017 16:45:04 -0000

#332: Getting error at column 33851 ...

 I’m trying to upload a document with is a cut down version from a previous
 one …

             I believe everything is ok, and can’t find the problem, but I
 get

             WARNING: Parsing Error: Opening and ending tag mismatch:
 section line 1 and middle, line 1, column 33851 (line 1)
             ERROR: Unable to parse the XML document: INPUT
              INPUT: Line 1: Opening and ending tag mismatch: section line
 1 and middle
              INPUT: Line 1: Opening and ending tag mismatch: section line
 1 and middle
              INPUT: Line 1: Opening and ending tag mismatch: middle line 1
 and rfc
              INPUT: Line 1: Premature end of data in tag rfc line 1

 I use Mac OS X BBEdit (before was TextWrangler), it seems to use x0D as
 line separator.

 Sample file with the problem (I deleted on extra  </section> at the end of
 the security section.

-- 
----------------------------------------+----------------------------------
 Reporter:  [email-masked]  |      Owner:  [email-masked]
     Type:  defect                      |     Status:  new
 Priority:  medium                      |  Milestone:
Component:  Version 2 cli               |    Version:  2.4.x
 Keywords:                              |
----------------------------------------+----------------------------------

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/332>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Mon, 12 Jun 2017 17:27:54 +0000

Using CR as the line separator is the root of the issue. The XML library we use would treat that as whitespace, but not a newline. That would definitely explain things.

	Tony

On 6/12/17, 12:45 PM, "xml2rfc on behalf of xml2rfc issue tracker" <[email-masked] on behalf of [email-masked]> wrote:

    

    

    Ticket URL: <https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.tools.ietf.org_tools_xml2rfc_trac_ticket_332&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Kz8VdgPVctDNSNPJ6PsBaw&m=kZ61yPPYfcLI5mDaZdksoJisP9JePMxeUURd07oLc-Y&s=tuVEa23BfoSDS2qz3-RdUrveQtKJGla8lK3U65u8pIc&e= >
    xml2rfc <https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org_tools_xml2rfc_&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Kz8VdgPVctDNSNPJ6PsBaw&m=kZ61yPPYfcLI5mDaZdksoJisP9JePMxeUURd07oLc-Y&s=gRP6s5EYd7XZZZd3sxsXiJ1Jlb0YfaR679WgKMh7wmk&e= >
    
    _______________________________________________
    xml2rfc mailing list
    [email-masked]
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_xml2rfc&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Kz8VdgPVctDNSNPJ6PsBaw&m=kZ61yPPYfcLI5mDaZdksoJisP9JePMxeUURd07oLc-Y&s=vO-MgLjvdVih4H7n7uosS9jj_ko_UhsbWUMeh7urF1Y&e=

---

From: Fred Baker <[email-masked]>
Date: Mon, 12 Jun 2017 10:31:35 -0700

> On Jun 12, 2017, at 10:27 AM, HANSEN, TONY L <[email-masked]> wrote:
> 

BBEdit should allow you to change the newline characters...

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 12 Jun 2017 19:33:15 +0200

I just realized that I got the original xml that I used to keep working on this document from the RFC editor, as I wasn’t the original author, so that may be the root of the problem.

I will find the way to replace CR with newline across all the document to avoid this problem in the future anyway.

Regards,
Jordi

-----Mensaje original-----
De: "HANSEN, TONY L" <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 12 de junio de 2017, 19:27
Para: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Asunto: Re: [xml2rfc] #332 (Version 2 cli): Getting error at column 33851 ...

    	Tony

        

        

        

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Mon, 12 Jun 2017 17:55:12 -0000

Comment (by [email-masked]):

 Thank you, Jordi.

 If I arrange things a bit differently internally in xml2rfc, in order to
 deal with the input file using MAC line endings, I get this error message
 instead; I hope that will help you proceed.  I'll run the changes through
 the test suite, and make this fix part of the next release, so we deal
 bettwer with MAC line endings.):

 {{{
 Parsing file tests/input/draft-palet-v6ops-rfc7084-bis-transition-00.xml
 WARNING: Parsing Error: Opening and ending tag mismatch: section line 299
 and middle, line 634, column 12 (line 634)
 ERROR: Unable to parse the XML document: tests/input/draft-palet-v6ops-
 rfc7084-bis-transition-00.xml
  /home/henrik/src/xml2rfc/trunk/cli/tests/input/draft-palet-v6ops-rfc7084
 -bis-transition-00.xml: Line 634: Opening and ending tag mismatch: section
 line 299 and middle
  /home/henrik/src/xml2rfc/trunk/cli/tests/input/draft-palet-v6ops-rfc7084
 -bis-transition-00.xml: Line 1: Document is empty
  /home/henrik/src/xml2rfc/trunk/cli/tests/input/draft-palet-v6ops-rfc7084
 -bis-transition-00.xml: Line 1: Start tag expected, '<' not found

 }}}

 FWIW, the error message above tells me that the section which starts on
 line 299 doesn't have a matching end tag; instead a </middle> end tag was
 found.

-- 
-----------------------------------------+---------------------------------
  Reporter:  [email-masked]  |      Owner:
      Type:  defect                      |  [email-masked]
  Priority:  medium                      |     Status:  new
 Component:  Version 2 cli               |  Milestone:
Resolution:                              |    Version:  2.4.x
                                         |   Keywords:
-----------------------------------------+---------------------------------

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/332#comment:1>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Mon, 12 Jun 2017 19:12:10 +0000

That error message looks really nice, Henrik.

	Tony

On 6/12/17, 1:55 PM, "xml2rfc on behalf of xml2rfc issue tracker" <[email-masked] on behalf of [email-masked]> wrote:

    
     Thank you, Jordi.

     {{{
    
     }}}

    
    Ticket URL: <https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.tools.ietf.org_tools_xml2rfc_trac_ticket_332-23comment-3A1&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=Kz8VdgPVctDNSNPJ6PsBaw&m=8pNIw9XD1fNO3qU_NFPrTCyrBT0_ogXYfe94Y4mAi1Y&s=JrURdt2DchyGsZptB-F5gNUImf7_8HIm1PNPPyQP6QY&e= >
    xml2rfc <https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org_tools_xml2rfc_&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=Kz8VdgPVctDNSNPJ6PsBaw&m=8pNIw9XD1fNO3qU_NFPrTCyrBT0_ogXYfe94Y4mAi1Y&s=3UJqdibNKrmZhCa69n8wd0JHPSNxf228-t7xU4Zwl-4&e= >
    
    _______________________________________________
    xml2rfc mailing list
    [email-masked]
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_xml2rfc&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=Kz8VdgPVctDNSNPJ6PsBaw&m=8pNIw9XD1fNO3qU_NFPrTCyrBT0_ogXYfe94Y4mAi1Y&s=lq0YspifGxE-OebH1dUs2OZLCwHRk-o5K3uJwoc8RIo&e=

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 12 Jun 2017 19:49:49 -0400

"HANSEN, TONY L" <[email-masked]> writes:
> Using CR as the line separator is the root of the issue. The XML
> library we use would treat that as whitespace, but not a newline. That
> would definitely explain things.

That's strange behavior, because the XML specification ("Extensible
Markup Language (XML) 1.0 (Fifth Edition)",
http://www.w3.org/TR/xml/#sec-white-space), section 2.11 says that a
naked CR must be translated into an NL:

    To simplify the tasks of applications, the XML processor MUST behave
    as if it normalized all line breaks in external parsed entities
    (including the document entity) on input, before parsing, by
    translating both the two-character sequence #xD #xA and any #xD that
    is not followed by #xA to a single #xA character.

Dale

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Tue, 13 Jun 2017 00:02:04 +0000

I won’t argue with you. And Henrik already has a fix prototyped that evidently treats the bare CRs better.

	Tony	

On 6/12/17, 7:49 PM, "Dale R. Worley" <[email-masked]> wrote:

    That's strange behavior, because the XML specification ("Extensible
    Markup Language (XML) 1.0 (Fifth Edition)", …), section 2.11 says that a
    naked CR must be translated into an NL:

    Dale

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Mon, 19 Jun 2017 13:32:02 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 Fixed in [2339]:

 Refactored the input file reading to accept files with Mac line endings,
 using python's Universal Newline support.  This should make xml2rfc deal
 correctly with input files following DOS, MAC and Linux line-ending
 conventions.

-- 
-----------------------------------------+---------------------------------
  Reporter:  [email-masked]  |      Owner:
      Type:  defect                      |  [email-masked]
  Priority:  medium                      |     Status:  closed
 Component:  Version 2 cli               |  Milestone:
Resolution:  fixed                       |    Version:  2.4.x
                                         |   Keywords:
-----------------------------------------+---------------------------------

Ticket URL: <https://tools.ietf.org/tools/xml2rfc/trac/ticket/332#comment:2>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>