Subject: [xml2rfc] testing xml2rfc (xml2rfc==2.2.3)

From: Miek Gieben <[email-masked]>
Date: Wed, 15 Feb 2012 11:26:40 +0100

Hello,

I just started playing with xml2rfc version 2, to see how
it works wrt version 1 and pandoc2rfc. Version two seems
to work OK, and creates a nice looking text file. I made
the following observations.

It seems the Roman list style isn't supported anymore --
this was a hidden feature in xml2rfc version 1:

    WARNING: No %c or %d found in list format string: format %i.

Or uppercase:

    WARNING: No %c or %d found in list format string: format %I.

Also non Roman uppercase letters don't work anymore:

    WARNING: No %c or %d found in list format string: format %C.

Also, lines like:

    <?xml version='1.0' encoding='UTF-8'?>

Halfway through the document, make the parsing fail. xml2rfc(1) handles
this OK (just skips it, I assume?) These lines are easily created when
cutting and pasting a reference into your doc.

xml2rfc(1) uses two parameters on the command line:

    xml2rfc <infile>.xml <outfile>.txt

xml2rfc(2) discards the second one and writes <infile>.txt

I'm not a fan of xml2rfc(1)'s behavior, but making xml2rfc(2)
behave different makes upgrading harder...

Things like: 

    <section title="section" anchor="section">
    <xref target="section"/>.

are expanded to "Section 2.1" in xml2rfc(1) and to see "[section]" 
in xml2rfc(2).

xml2rfc(1) add two spaces after a end-of-sentence dot, xml2rfc(2) one:

    1: "back" section of an RFC.  The easiest way is to create a template
    2: "back" section of an RFC. The easiest way is to create a template XML

In hanging paragraphs the same happens, two spaces for xml2rfc(1) and one
space for xml2rfc(2).

 grtz,

-- 
    Miek

---

From: Miek Gieben <[email-masked]>
Date: Wed, 15 Feb 2012 12:12:45 +0100

[ Quoting <[email-masked]> at 11:26 on Feb 15 in "[xml2rfc] testing xm..." ]
> the following observations.

I do get a weird error which I don't understand:

DISPLAY= sh xml-wrap template.xml draft.txt
Parsing file template.xml
WARNING: The include file at /home/miekg/src/pandoc2rfc/middle.xml contained an XML error and 
        was not expanded: Extra content at the end of the document, line 197, column 1
ERROR: Unable to validate the XML document: template.xml
  Line 51: Element middle content does not follow the DTD, expecting (section)+, got ()
make: *** [draft.txt] Error 1

Where in template.xml there is:

<middle>
<?rfc include="middle.xml"?>
</middle>

And in middle.xml on line 197 there is:

    .....
194   </t>
195 </section>
196 
197 <section title="Pandoc Constructs" anchor="pandoc-constructs">
198  
199   <t>
    .... 

Which is all perfectly find in xml2rfc version 1.

grtz Miek

---

From: Miek Gieben <[email-masked]>
Date: Wed, 15 Feb 2012 12:12:45 +0100

<middle>

    .....
194   </t>
195 </section>
196 

grtz Miek

---

From: Julian Reschke <[email-masked]>
Date: Wed, 15 Feb 2012 13:51:55 +0100

>      WARNING: No %c or %d found in list format string: format %C.

I would consider that a bug.

> cutting and pasting a reference into your doc.

That's a feature, caused by using a proper XML parser.

>      xml2rfc<infile>.xml<outfile>.txt
>
> xml2rfc(2) discards the second one and writes<infile>.txt
>

I don't think it makes a big difference; most people do not run local 
versions anyway right now.

> are expanded to "Section 2.1" in xml2rfc(1) and to see "[section]"

That's a bug.

>      2: "back" section of an RFC. The easiest way is to create a template XML

That's a bug.

> In hanging paragraphs the same happens, two spaces for xml2rfc(1) and one

I recommend opening tickets at 
<http://trac.tools.ietf.org/tools/xml2rfc/trac/>.

Best regards, Julian

---

From: Miek Gieben <[email-masked]>
Date: Wed, 15 Feb 2012 21:03:16 +0100

[ Quoting <[email-masked]> at 13:51 on Feb 15 in "Re: [xml2rfc] testin..." ]
> <http://trac.tools.ietf.org/tools/xml2rfc/trac/>.

done, but let me just say it was completely non-obvious how to create an account.

I rather use the mailing list for stuff like this.

grtz Miek

---

From: Miek Gieben <[email-masked]>
Date: Wed, 15 Feb 2012 21:03:16 +0100

grtz Miek

---

From: Julian Reschke <[email-masked]>
Date: Wed, 15 Feb 2012 21:12:38 +0100

On 2012-02-15 21:03, Miek Gieben wrote:
> [ Quoting<[email-masked]>  at 13:51 on Feb 15 in "Re: [xml2rfc] testin..." ]

Mailing lists work best when those you need to fix the bugs read the 
list :-)

---

From: Julian Reschke <[email-masked]>
Date: Wed, 15 Feb 2012 21:12:38 +0100

---

From: Miek Gieben <[email-masked]>
Date: Wed, 15 Feb 2012 21:45:44 +0100

[ Quoting <[email-masked]> at 21:12 on Feb 15 in "Re: [xml2rfc] testin..." ]
> Mailing lists work best when those you need to fix the bugs read the

uhmm, OK. The devs dealing with the tool are not subscribed to the
list about the tool...

grtz Miek

---

From: Miek Gieben <[email-masked]>
Date: Wed, 15 Feb 2012 21:45:44 +0100

grtz Miek

---

From: Mark Andrews <[email-masked]>
Date: Thu, 16 Feb 2012 09:50:17 +1100

In message <[email-masked]>, Miek Gieben writes:
> 
> [ Quoting <[email-masked]> at 21:12 on Feb 15 in "Re: [xml2rfc] test> in..." ]
> > >done, but let me just say it was completely non-obvious how to create an>  account.
> > >

Whether they read the list or not doesn't matter.  If you put a bug
into a tracking system it shouldn't get lost.  Sending it to a list
means that some, who could be fixing the bug, has to spend time
adding it to the tracking system. 

I know bugs can get overlooked with a tracking system but they are
still there for anyone to easily find.  In a list they are nearly
impossible to find.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Thu, 16 Feb 2012 09:50:17 +1100

---

From: Miek Gieben <[email-masked]>
Date: Thu, 16 Feb 2012 00:03:57 +0100

[ Quoting <[email-masked]> at 09:50 on Feb 16 in "Re: [xml2rfc] testin..." ]
> still there for anyone to easily find.  In a list they are nearly

True, but I think the logic should be reversed.

If someone is putting in time and effort into unconvering bugs, there 
shouldn't be extra hurdles to get the bug report in the right place.

Yes, this is difficult and yes there should be a central place where
all bugs are kept. But this should not be the burden of the bug reporter.

Note: I don't say it should be the burder of the developer either. I, for one,
are happy with bug reports via e-mail, twitter or a bug tracker. But with large
projects things could be different.

grtz Miek

---

From: Miek Gieben <[email-masked]>
Date: Thu, 16 Feb 2012 00:03:57 +0100

grtz Miek