Subject: [Tools-discuss] new xml2rfc tool

From: Ernesto Revilla Derksen <[email-masked]>
Date: Wed, 23 Feb 2011 09:08:46 +0100

Hello.

We wanted to present a bid for the RFP of a new xml2rfc tool.

As I see, the there could be two approaches:
 * using some sort of what currently xml2rfc does, i.e. xml -> nroff ->
plain text, html
 * using xhtml -> nroff, plain text, html

It seems that:
http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html
offers guidance for the second approach.

What is currently the favorite method? Are outputs equivalent +/-?

Regards.

Erny

Yaco Sistemas
Spain.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 23 Feb 2011 09:28:27 +0100

On 23.02.2011 09:08, Ernesto Revilla Derksen wrote:
> ...

The output of the XSLT is supposed to be equivalent. There are a few 
things it doesn't do, such as the PI-based inclusion (which would 
require a preprocessing step), and the alternate format elements on 
references (which I believe are useless and are not used for RFC 
production).

So my advice is to seriously consider the second option.

Best regards, Julian

---

From: Ernesto Revilla Derksen <[email-masked]>
Date: Wed, 23 Feb 2011 10:22:47 +0100

Hi again.

2011/2/23 Julian Reschke <[email-masked]>

> The output of the XSLT is supposed to be equivalent. There are a few things
> it doesn't do, such as the PI-based inclusion (which would require a
> preprocessing step), and the alternate format elements on references (which
> I believe are useless and are not used for RFC production).
>

I've had a quick superficial look at xml2rfc.tcl. It's something like 17.900
lines. We'll make an estimate about how much time would it take to translate
this to something more modern and maintainable.

I don't know how much lines is the xslt. We'll have a look.

Best regards.
Erny

---

From: Julian Reschke <[email-masked]>
Date: Wed, 23 Feb 2011 10:43:01 +0100

On 23.02.2011 10:22, Ernesto Revilla Derksen wrote:
> ...
> I've had a quick superficial look at xml2rfc.tcl. It's something like
> 17.900 lines. We'll make an estimate about how much time would it take
> to translate this to something more modern and maintainable.
> ...

That's misleading as the TCL code contains an XML parser you don't want 
to re-do :-)

> I don't know how much lines is the xslt. We'll have a look.

The XSLT code is ~7000 lines, but XSLT is kind of chatty.

That being said, I don't think the size of the XSLT code matters; what 
you should consider is using it as-is, and writing a backend processors 
that formats the XHTML output as plain text or NROFF.

Best regards, Julian

---

From: Tony Hansen <[email-masked]>
Date: Wed, 23 Feb 2011 09:44:35 -0500

On 2/23/2011 3:08 AM, Ernesto Revilla Derksen wrote:
>  * using some sort of what currently xml2rfc does, i.e. xml -> nroff 
> -> plain text, html

Note, this is a mistaken impression: xml2rfc.tcl does not *use* nroff at 
all.

Internally, xml2rfc.tcl has multiple passes. In the first pass, it 
decides how the individual lines in the text output need to be 
generated. For example, it figures out exactly how long each text line 
should be in the final output and what the indentation needs to be. That 
is, the canonical format internally is essentially fixed length lines of 
text.

In a subsequent pass it converts that internal version of the text to 
the final format, such as figuring out the pagination and emitting nroff 
or html directives.

     Tony Hansen

---

From: Ernesto Revilla Derksen <[email-masked]>
Date: Wed, 23 Feb 2011 18:50:06 +0100

Hello.

2011/2/23 Tony Hansen <[email-masked]>

> Note, this is a mistaken impression: xml2rfc.tcl does not *use* nroff at
Well, I tihink that my look was too superficial.

> Internally, xml2rfc.tcl has multiple passes. In the first pass, it decides
> how the individual lines in the text output need to be generated. For
> example, it figures out exactly how long each text line should be in the
> final output and what the indentation needs to be. That is, the canonical
> format internally is essentially fixed length lines of text.
>
> In a subsequent pass it converts that internal version of the text to the
> final format, such as figuring out the pagination and emitting nroff or html
> directives.
>

Thank you for your explanation. This changes my view about future
approaches.

Would it be feasible to do: XML -> nroff -> plain text / xhtml instead? (we
would use groff).

Of course, an alternative would be what Julian Reschke proposed:
xml -> html / plain text / nroff.

Regards.
Erny

---

From: Scott W Brim <[email-masked]>
Date: Wed, 23 Feb 2011 12:55:01 -0500

> Would it be feasible to do: XML -> nroff -> plain text / xhtml instead? (we

I don't see the point of running it through *roff.

---

From: Tony Hansen <[email-masked]>
Date: Wed, 23 Feb 2011 13:27:30 -0500

On 2/23/2011 12:50 PM, Ernesto Revilla Derksen wrote:
> Hello.
>
> 2011/2/23 Tony Hansen <[email-masked] <mailto:[email-masked]>>
>
>          * using some sort of what currently xml2rfc does, i.e. xml ->
>         nroff -> plain text, html
>
>
>     Note, this is a mistaken impression: xml2rfc.tcl does not *use*
>     nroff at all.
>
>     generated. For example, it figures out exactly how long each text
>     line should be in the final output and what the indentation needs
>     to be. That is, the canonical format internally is essentially
>     fixed length lines of text.
>
>     In a subsequent pass it converts that internal version of the text
>     to the final format, such as figuring out the pagination and
>     emitting nroff or html directives.
>
>
> Would it be feasible to do: XML -> nroff -> plain text / xhtml 
> instead? (we would use groff).

I personally think that generating nroff as an intermediate form and 
using groff would be the wrong thing to do, but you'll have to make that 
determination yourself.

> xml -> html / plain text / nroff.

That's what the current xml2rfc.tcl does. I think you meant xml -> xhtml 
-> nroff/text/xml/html.

     Tony Hansen

---

From: Julian Reschke <[email-masked]>
Date: Wed, 23 Feb 2011 19:41:36 +0100

> That's what the current xml2rfc.tcl does. I think you meant xml -> xhtml

Well, there's rfc2629.xslt (producing HTML 4.01) and rfc2629toXhtml.xslt 
(producing XHTML) (*). So HTML and XHTML can be generated directly.

 From the XHTML, plain text and nroff could be produced. Most of the 
information should be available in the XHTML output; if something is 
missing, it could be added easily (**).

Just to mention another option, there's also rfc2629toFo.xslt which 
produces an XSL-FO (Formatting Object) file, which probably could be 
used by a backend as well.

Best regards, Julian

(*) And yes, the second one is autogenerated from the first one.
(**) For instance, headers and footers currently are inlined into the 
generated CSS and may be hard to extract without a fullblown CSS parser.