Subject: [xml2rfc] Online converter does not detect "<" in attribute values

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 2 Feb 2011 17:18:44 -0500

I've been using the online XML2RFC converter at http://xml.resource.org/.

I've recently discovered that its checking of XML syntax is not rigid.  In particular, I can get it to accept documents that contain start tags with "<" in the attribute value.  Viz.:

    <section title="The <session-info> Element">

According to the XML specification, "<" is not allowed and must be encoded as "&lt;".  (">" is allowed.)

Has anyone run into this problem?  And how can I get it fixed?

Dale

---

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

On 02.02.2011 23:18, Worley, Dale R (Dale) wrote:
>      <section title="The<session-info>  Element">
>
> According to the XML specification, "<" is not allowed and must be encoded as"&lt;".  (">" is allowed.)
>
> ...

xml2rfc.tcl uses an in-lined unmaintained XML parser. That's a known 
problem.

Options:

- live with it
- fix it
- replace it with something else

All but the first option will require a lot of work.

Best regards, Julian

---

From: Tony Hansen <[email-masked]>
Date: Wed, 02 Feb 2011 18:09:26 -0500

Your wish is our command! :-)

I hadn't announced it here yet, but was planning on doing soon shortly, 
so this seems like a good time.

Please try out

     http://xml.resource.org/experimental.html

(There's a link to it from the page you've been using.)

Major new xml2rfc features include:

     * Support for the new <rfc> consensus= attribute.
     * Generate proper boilerplate for RFC generation (RFC 5741).
     * Support for new <?rfc text-list-symbols="o*+-"?> processing 
instruction. The default is "o*+-", but can be set to any list of 
characters.

Major new web features include:

     * New options in web form to generate ePub, Postscript, PDF and RTF.
     * New option in web form to show trace and warning messages.
     * New option in web form to do strict DTD checking.
     * New option to generate HTML using Julian Reschke's XSLT.

For this particular request, note the "strict DTD checking" option. 
Passing in an attribute with a "<" in it will generate this message:

     Unable to Validate File

     [Fatal Error] INPUT:12:17: The value of attribute "abbrev" 
associated with an element type "title" must not contain the '<' character.

Feedback would be appreciated before it goes live on the regular site.

One placed I'd definitely appreciate feedback on would be better 
terminology in picking between the type of output (text with fixed 
length pages, html, nroff, etc) and the format of that output (ASCII, 
PDF, ePub, RTF and Postscript). Right now I'm calling these "Output 
mode" and "Output format". Any alternatives that people can think of?

     Tony Hansen
     [email-masked]

PS. Thanks also go to Julian Reschke and Henrik for their help in 
getting this release out.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 03 Feb 2011 13:20:07 +1300

>     http://xml.resource.org/experimental.html

Cool, Tony. Thanks. Now a plea for help. With strict checking I get

[Error] INPUT:140:11: The content of element type "section" must match "((t|figure|texttable|iref)*,section*)".
[Error] INPUT:148:37: Attribute value "6to4" of type ID must be an NCName when namespaces are enabled.

on a certain input file. But these are pretty hard to understand, and without
strict checking the document is accepted and all is well.

It turns out that the first error is caused by a naked <list>
inside a section. Is one supposed to nest, like

  <t>blah<list><t>blah1</t><t>blah2</t></list></t> ?

The second error is caused by

  <section anchor="6to4" title="6to4">

and I don't really see why anchors can't start with a digit.

    Brian

---

From: Tony Hansen <[email-masked]>
Date: Wed, 02 Feb 2011 21:59:31 -0500

On 2/2/2011 7:20 PM, Brian E Carpenter wrote:
> It turns out that the first error is caused by a naked<list>

The DTD says:

<!ELEMENT middle      (section+)>
<!ELEMENT section     ((t|figure|texttable|iref)*,section*)>

This says that the only things allowed at the "top" level within a 
section are <t>, <figure>, <texttable> and <iref>.

The only place <list> is allowed is inside a <t>:

<!ELEMENT t           
(%TEXT;|list|figure|xref|eref|iref|cref|spanx|vspace)*>

(And the only thing allowed inside a <list> in turn is a <t>.)

So yes, you're supposed to list them like you showed

<t>blah<list><t>blah1</t><t>blah2</t></list></t>

However, your "blah" can be empty.

> and I don't really see why anchors can't start with a digit.

The DTD has this for the attributes of <section>:

<!ATTLIST section
           anchor      ID                 #IMPLIED
           title       %ATEXT;            #REQUIRED
           toc         (include|exclude|default)
                                          "default">

So anchor is an ID. According to

     http://www.w3.org/TR/xmlschema-2/

ID is derived from NCName, which is defined in 
http://www.w3.org/TR/1999/REC-xml-names-19990114/#NT-NCName as:

     [4]     NCName     ::=     (Letter | '_') (NCNameChar)*    /*     
An XML Name, minus the ":" */
     [5]     NCNameChar     ::=     Letter | Digit | '.' | '-' | '_' | 
CombiningChar | Extender

Hope this helps clarify why the strict validator is complaining.

     Tony Hansen

---

From: Julian Reschke <[email-masked]>
Date: Thu, 03 Feb 2011 10:05:23 +0100

Thanks, Tony.

One nit: what's relevant is the definition of ID from the XML spec (not 
XML Schema), but that of course doesn't change the actually allowed syntax:

"Values of type ID MUST match the Name production. A name MUST NOT 
appear more than once in an XML document as a value of this type; i.e., 
ID values MUST uniquely identify the elements which bear them." -- 
<http://www.w3.org/TR/REC-xml/#sec-attribute-types>

Best regards, Julian

---

From: "John R. Levine" <[email-masked]>
Date: 2 Feb 2011 18:05:20 -0500

> xml2rfc.tcl uses an in-lined unmaintained XML parser. That's a known problem.
>
> Options:
>
> - live with it
> - fix it

  - note that there's an RFP going out to rewrite the whole thing, which
    will presumably use a real XML parser

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Scott Brim <[email-masked]>
Date: Thu, 03 Feb 2011 11:16:46 -0500

> <t>blah<list><t>blah1</t><t>blah2</t></list></t>

and for lists within lists, <t><list><t><list><t>blah</t>...

I want to add my thanks, 'experimental' is a great step.

---

From: Scott Brim <[email-masked]>
Date: Thu, 03 Feb 2011 11:35:16 -0500

> mode" and "Output format". Any alternatives that people can think of?

I would think I understand the difference, but I don't understand your
examples so I probably don't.  What does it mean if I have nroff mode
and ePub format?  Am I viewing the raw nroff in ePub?  Isn't nroff a
format, i.e. a markup language as to how to display the text?

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 3 Feb 2011 12:10:22 -0500

> From: Tony Hansen [[email-masked]]
> 

That's very good.  But what are the "consensus" and
"text-list-symbols" attributes?  I must say, it's sort of comical
reading 'The default is "o*+-" ...' as if it's intuitive what that
means!

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 3 Feb 2011 12:12:29 -0500

If I enable "strict" checking, it finds the XML syntax violation I was concerned about.  Many thanks!

However, I've run into an odd bug:  Setting the file name, with HTML/ASCII/Strict/Show warnings, I get an error screen containing two frames(!) each containing a copy of the same message:

    Invalid filename (unwritable)

    Apache/2.2.16 (Debian) Server at xml.resource.org Port 80

If I change the output destination to Window, I get the HTML output.

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 3 Feb 2011 12:16:56 -0500

________________________________________
[Error] INPUT:140:11: The content of element type "section" must match "((t|figure|texttable|iref)*,section*)".
_______________________________________________

It's easier to understand than it looks:  The last part is a regexp showing what can go inside a "section" element.  In this case, either a sequence of zero or more section elements, or a mixed sequence of zero or more t, figure, texttable, and iref elements.  So you look at line 140, character 11, and see what it is.  It should be a start tag for an element that can't go in that location within its parent <section>.

Dale

---

From: Julian Reschke <[email-masked]>
Date: Thu, 03 Feb 2011 18:20:15 +0100

On 03.02.2011 18:10, Worley, Dale R (Dale) wrote:
>>       * Support for the new<rfc>  consensus= attribute.
>>       * Support for new<?rfc text-list-symbols="o*+-"?>  processing

<http://xml.resource.org/authoring/README-dev.html#attribute-consensus>

BR, Julian

---

From: Alice Hagens <[email-masked]>
Date: Thu, 3 Feb 2011 12:44:58 -0500

> <http://xml.resource.org/authoring/README-dev.html#attribute-consensus>

AFAIK, the consensus attribute does not have any effect on the "Status of This Memo" in an Internet-Draft. It is used by the RFC Production Center as one of the inputs to generate the appropriate "Status of This Memo" text in an RFC. (The options defined by RFC 5741 are shown here: http://www.rfc-editor.org/rfc-style-guide/status-memos.txt.)

> 'The default is "o*+-" ...'

By default, a list element with style="symbols" contains items bulleted with "o" (in the text output). Nested lists contain items bulleted with "*", then "+", then "-" (as mentioned on http://xml.resource.org/xml2rfcFAQ.html#anchor21).

New feature: you can set the list of characters using the text-list-symbols PI. This seems useful for authors who like to use "-" as a symbol for bulleted lists.

Alice
RFC Production Center

On Feb 3, 2011, at 12:10 PM, Worley, Dale R (Dale) wrote:

> xml2rfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml2rfc
>

---

From: Tony Hansen <[email-masked]>
Date: Thu, 03 Feb 2011 14:54:55 -0500

> format, i.e. a markup language as to how to display the text?

The "Output mode" is what the output looks like: the text we all know 
and love, html format, the nroff equivalent of the xml, text formatted 
without page breaks, and xml with all of the XML entities and includes 
processed. Today these are all generated in ASCII. These are the same 
Output Modes that xml.resource.org has always generated. I kept the 
"Output mode" heading from the current web form.

The "Output format" is oriented towards the medium used to display the 
output. ASCII maps to what we've all used before, but now there are also 
options to generate PDF files, ePub files, RTF files, and Postscript files.

Now that I've explained further what their use maps into, are there 
better terms than "Output mode" and "Output format"? How about "Output 
media" for the latter instead of "format"?

     Tony

---

From: Tony Hansen <[email-masked]>
Date: Thu, 03 Feb 2011 15:30:56 -0500

> If I change the output destination to Window, I get the HTML output.

You should get the warnings and errors in the top frame and the 
generated text/HTML/nroff/whatever output in the bottom frame. The error 
message indicates that it can't find the temp file where the 
warning/error messages and html output were put.

Did you do a "reload" of the frames? Once the above displays the temp 
files, they are removed, so wouldn't be found a second time. You'd have 
to resubmit the input files to get the output generated again.

     Tony Hansen

---

From: Tony Hansen <[email-masked]>
Date: Thu, 03 Feb 2011 15:40:53 -0500

> reading 'The default is "o*+-" ...' as if it's intuitive what that

I've updated the web page to have a better description and the links 
offered by Julian and Alice.

     Tony Hansen

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 04 Feb 2011 15:48:54 +0900

>    <t>blah<list><t>blah1</t><t>blah2</t></list></t>  ?

While I think it's not worth to fiddle around with changes in allowed 
markup, I think getting rid of the requirement for t-list-t-list would 
really help a lot and would be well worth doing. For people comming from 
other kinds of XML/markup formats, it's quite surprising.

Regards,   Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Fri, 04 Feb 2011 09:21:15 +0100

> other kinds of XML/markup formats, it's quite surprising.

Actually, HTML has the same restriction: <P> contains "inline" elements, 
and the list elements aren't part of that (or am I reading this wrong?).

A much more important problem (IMHO) that needs to be addressed is that 
we can't have list items that span multiple paragraphs without resorting 
to <vspace> hacks...

BR, Julian

---

From: Thomas Morin <[email-masked]>
Date: Fri, 04 Feb 2011 09:55:35 +0100

Hi Tony,

Tony Hansen a écrit :
> output. ASCII maps to what we've all used before, but now there are 
> also options to generate PDF files, ePub files, RTF files, and 
> Postscript files.
>

Well, if I may, I would actually suggest a different solution: instead 
of the two parameters, for which not all the combinations make sense 
(e.g. HTML as ASCII, xml as PDF/ePUB/PS, txt as RTF) or even work (eg. 
HTML/RTF doesn't seem to), why not consider a flat list containing only 
the working and most relevant combinations ?

-Thomas

---

From: Elwyn Davies <[email-masked]>
Date: Fri, 04 Feb 2011 09:30:01 +0000

> we can't have list items that span multiple paragraphs without resorting 
+1

This problem has been discussed previously starting at
http://www.ietf.org/mail-archive/web/xml2rfc/current/msg02010.html
and rewarmed at
http://www.ietf.org/mail-archive/web/xml2rfc/current/msg02033.html.

The proposal for <lt> seemed good to me at the time - and the ability to
have anchors that John Klensin proposed also seemed like a good idea,
although we never got to a view of how such an anchor would be
referenced in an <xref>.

According to 
http://www.ietf.org/mail-archive/web/xml2rfc/current/msg02073.html
Bill had some code but it doesn't seem to have made it into the running
tool.  Julian also claimed some work in the xslt processor.

/E

---

From: Julian Reschke <[email-masked]>
Date: Fri, 04 Feb 2011 10:45:35 +0100

On 04.02.2011 10:30, Elwyn Davies wrote:
>> to<vspace>  hacks...
> The proposal for<lt>  seemed good to me at the time - and the ability to
> referenced in an<xref>.

You wouldn't be able to rely on autogenerated link text, but at least 
you'd get hyperlinks in HTML, and would be able to use the anchor in the 
URI.

> tool.  Julian also claimed some work in the xslt processor.

<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#ext.element.lt>. 
I use it all the time.

When pre-processing for xml2rfc.tcl 
(<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#clean-for-dtd>), 
the x:lt elements get combined into a single <t> with <vspace> as separator.

Best regards, Julian

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 4 Feb 2011 09:48:23 -0000

> we can't have list items that span multiple paragraphs without resorting 

I'd generalise that to wanting to be able to either group items together,
or have some sort of "keep with next" attribute more widely. Tables can
get split and captions detached from figures to name but two.

(Of course I realise how much easier it is to want something than it
is for someone to do it. And at least the vspace hacks work even if
they need ripping out and re-entering each time a document is
significantly changed.)

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 4 Feb 2011 09:41:10 -0500

Did you do a "reload" of the frames? Once the above displays the temp
files, they are removed, so wouldn't be found a second time. You'd have
to resubmit the input files to get the output generated again.
_________________________________________

I just tried it again, and got two frames of:

    File is gone -- did you click reload?

I strongly suspect the problem is that there are no (reported) errors in the document, and that has caused the system to not create the errors file, but the output options I selected were to only show errors...

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 4 Feb 2011 09:54:25 -0500

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Tony Hansen [[email-masked]]

I find this discussion confusing.

I understand what text is, both as a file format and the implied formatting of the document.

Similarly with HTML, I know what an HTML file is and the expected non-paginated format that it will contain.

But what does it mean to select "text" *and* "PDF"?  Do I get a text file?  Do I get a PDF file?  Or (shudder) do I get a PDF file which when I display it shows me lines of fixed-width characters?  (The latter being a total waste, using a complex format to deliver the functionality of a simple format, while also making it difficult to manipulate the data -- if I wanted paginated lines of fixed-width characters, I would have selected "text".)

And I can't guess what it means to select "HTML" and "Postscript" together -- a Postscript file which when displayed shows me the HTML tags that would cause the document to be rendered?

Perhaps what you mean is that one control is for the way the output is to ultimately appear, of which the choices are "paginated, fixed-width font", "unpaginated, with pretty formatting like the traditional HTML format", and possibly others; and the other control is the format that will be generated (and whose facilities will be used to produce the selected appearance): text, nroff, HTML.

Dale

---

From: Scott Brim <[email-masked]>
Date: Fri, 04 Feb 2011 11:39:29 -0500

> the working and most relevant combinations ?

like MIME types?  text/rtf, text/html, text/xml, application/epub,
application/postscript ... ?

Maybe it's better not to go through those arguments yet again? :-p

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 07 Feb 2011 20:26:42 +0900

> the working and most relevant combinations ?

A very strong +1 for this proposal. It solves the question of what 
labels to use, it makes the selection a one-step process, and it reduces 
frustration (and possibly error-handling code) when combinations are not 
available.

Regards,   Martin.

---

From: Tony Hansen <[email-masked]>
Date: Mon, 07 Feb 2011 10:56:58 -0500

On 2/7/2011 6:26 AM, "Martin J. Dürst" wrote:
> labels to use, it makes the selection a one-step process, and it 
> reduces frustration (and possibly error-handling code) when 
> combinations are not available.

Well, out of that 6x5 matrix, there are exactly two combinations that 
don't work: HTML and HTMLxslt as RTF.  A flat list of the 28 remaining 
possibilities is *not* feasible.

Part of this exercise (for me) is to find out what people find useful. 
If no one thinks particular combinations are useful, then they can be 
eliminated.

So the next question becomes: which are the most relevant and useful?

On possibility is to eliminate RTF entirely: no one's asked for it. The 
only reason it's there is that the software underlying non-HTML => XYZ 
conversion supported RTF as an output format, so tossing it in was cheap.

Another possibility is to eliminate Postscript: no one's asked for it 
either. However, PS needed to be generated as an intermediate step in 
achieving PDF in most of the output formats, so generating the PS 
version was cheap.

That leaves ASCII, PDF and ePub, or 18 combinations.

You can argue that it doesn't make sense to represent nroff or XML 
output using PDF or ePub.  (And I'd mostly agree.)

Removing those two as PDF and ePub still leaves 14 combinations.

If you look at the PDF files that are in the RFC repository, you'll find 
that some of them look like the text format and some look fancier. So 
I'd suggest keeping both text and HTML in PDF.

I don't have enough information yet on what makes a good ePub document.

*Do* people agree that Postscript should be eliminated?
*Do* people agree that RTF should be eliminated?
*Do* people agree that it doesn't make sense to represent nroff or XML 
output using PDF or ePub?

With the above eliminations, we wind up with this set:

ASCII:    Text (paginated and unpaginated), HTML (via xml2rfc and via 
xslt), nroff and XML
PDF:      Text (paginated and unpaginated), HTML (via xml2rfc and via xslt)
ePub:    Text (paginated and unpaginated), HTML (via xml2rfc and via xslt)

Is this the right thing to do?

     Tony Hansen
     [email-masked]

---

From: Tony Hansen <[email-masked]>
Date: Mon, 07 Feb 2011 10:59:11 -0500

> get split and captions detached from figures to name but two.

Hmmm.

This is related to the general issue of widow and orphan control, which 
is something that we could definitely use when getting to the end of the 
production cycle.

> they need ripping out and re-entering each time a document is

Yup, that's always the hard part.

     Tony Hansen
     [email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Mon, 07 Feb 2011 17:30:57 +0100

> Is this the right thing to do?

Let's eliminate some more

- ePub: Text(*)
- PDF: Text(paginated)

The remaining complexity is just caused by us having two ways to get to 
HTML, right?

BR, Julian

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 7 Feb 2011 12:20:44 -0500

Hmmm.

The underlying problem is that the children of <list> are <t>, which implies that the elements of a list *must* be paragraphs.  That problem would have been solved by using the method that HTML does, where there is a special "list element" element.  But that would require that in most lists, the elements would be <li><t>...</t></li>.  Given where we stand now, perhaps a good solution would be to create a <list-item> element that is also allowed to be a child of <list>, whose children are <t>, and those <t>'s are separated by paragraph-breakage in the normal way.

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 7 Feb 2011 12:30:51 -0500

I don't see what you mean by many of these combinations.  What is "PDF: HTML"?  Is it a PDF file or an HTML file?  Or do you mean "a PDF file which, when rendered, looks very much like the HTML output"  ("an application/pdf, which when printed, looks as if you printed a text/html")?

You seem to be naming output formats based on what they *look* like when they are rendered, as opposed to the actual file format generated.  I suppose that's not a bad thing, but a more clear terminology would help this discussion along.

Dale

---

From: Tony Hansen <[email-masked]>
Date: Mon, 07 Feb 2011 13:25:50 -0500

Which gets back to my original questions, which boil down to: what would 
be clearer terminology?

Using the current terms, the "output mode" is what it will look like 
when it is rendered, and the "output format" is the file format generated.

So "HTML as PDF" in the form (or "PDF: HTML" in the above email message) 
means an application/pdf that when viewed or printed, looks like what 
the HTML would look like in a browser.

The existing xml.resource.org form uses the term "Output mode" in the 
same manner -- it's what the output looks like.

Another way to look at it the current combinations would be:

     Mode                Format
     Text (paginated)    text/plain, application/pdf, application/ePub
     Text (unpaginated)  text/plain, application/pdf, application/ePub
     HTML (via xml2rfc)  text/html, application/pdf, application/ePub
     HTML (via xslt)     text/html, application/pdf, application/ePub
     nroff               text/plain
     XML                 text/xml

Does that help?

     Tony Hansen

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 7 Feb 2011 16:02:30 -0500

> same manner -- it's what the output looks like.

That's not what I see.  I see it as offering two output formats, HTML
(= text/html) and text (= text/plain).  Either can be outputted into a
file, or you can have your browser display it.  (As a programmer, I
see the output file format as the primary matter, as that determines
what further programs it can be input to.  The visual format is a
secondary question.  xml2rfc is above all a program that transforms
one file into another.)

>      HTML (via xslt)     text/html, application/pdf, application/ePub

How about:

      Visual format       File format
      -------------       -----------
      Fixed-width text (paginated)
                          text/plain, application/pdf, application/ePub
      Fixed-width text (unpaginated)  
			  text/plain, application/pdf, application/ePub
      Like a web page (formatted via xml2rfc)
                          text/html, application/pdf, application/ePub
      Like a web page (formatted via xslt)     
			  text/html, application/pdf, application/ePub
      nroff input         text/plain
      XML                 text/xml

(Speaking of formatting, that table requires a fixed-width font to display correctly.)

That starts to get us away from using "HTML" as the name of a visual
appearance.

Presumably the "XML" output is the identity operation?

Dale

---

From: Julian Reschke <[email-masked]>
Date: Mon, 07 Feb 2011 22:19:04 +0100

>        Visual format       File format

Doesn't really make sense for ePub. ePub *is* HTML.

> 			  text/plain, application/pdf, application/ePub

Doesn't really make sense for ePub. ePub *is* HTML.

Also: what does unpaginated text in PDF even mean? What is it for?

> Presumably the "XML" output is the identity operation?

...with inclusions inlined, creating a standalone document.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 8 Feb 2011 10:28:18 -0000

> is something that we could definitely use when getting to the end of
the 

Special case of that (typically solved by keep with next
styles in a word processor) is headings. I find the case
where the heading is at the foot of a page, but the text
on the next as looking poor.

However I haven't seen it recently. Maybe it's already
fixed, or I've been lucky.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 08 Feb 2011 19:40:29 +0900

> Doesn't really make sense for ePub. ePub *is* HTML.

Well, yes, but as e.g. http://tools.ietf.org/html/rfc2629 shows, it's 
perfectly possible to have fixed-width paginated text in HTML. Actually, 
I have to say that I often prefer this kind of HTML to e.g. 
http://xml.resource.org/public/rfc/html/rfc2629.html. The former look 
like the "real thing" that we have been used for a long time (you may 
call me old-fashioned) and is as good as typewriter typography goes; the 
later is an ad-hoc style (no offence to Marshall, but I guess he would 
be the first to admit) that could definitely be improved (I'm not a 
designer, so don't ask me to do it, but I'll gladly point out some of 
the current problems if we want to go down that rathole).

> Doesn't really make sense for ePub. ePub *is* HTML.

See above.

> Also: what does unpaginated text in PDF even mean? What is it for?

I tend to agree. The fixed-width unpaginated plain text may be very 
helpful for diffs, but I don't see too much of a point for PDF and ePub 
here.

Regards,   Martin.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 08 Feb 2011 11:52:22 +0100

> the current problems if we want to go down that rathole).

Understood.

I'm not going to work on xml2rfc's HTML output, but if you have 
suggestions for rcf2629.xslt's, please go ahead.

Best regards, Julian

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 8 Feb 2011 10:56:26 -0000

> helpful for diffs, but I don't see too much of a point for PDF and ePub 

Don't know about ePub, but the PDF of the fixed-width font allows
proper paginated printing of the definitive version of the document,
while the text often doesn't print correctly. (My trick to printing
the text correctly is to load it into Word, which works but isn't
exactly what should be recommended.)

---

From: Julian Reschke <[email-masked]>
Date: Tue, 08 Feb 2011 12:00:28 +0100

> exactly what should be recommended.)

You can also directly print the HTML version generated by rfcmarkup on 
tools.ietf.org.

BR, Julian

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 8 Feb 2011 11:10:39 -0000

Not exactly the same when I do that - extra header and footer
and bold subheadings on the one page I tried out from a
random RFC. I'd guess there may be other things I haven't seen.

That may in some ways be better (not the header and footer,
but that may be a browser thing - itself an issue) but it is
different.

Still of the opinion there's value in the fixed format PDF.
Not critical value, but value.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Communications and Networks Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: 08 February 2011 11:00
To: Dearlove, Christopher (UK)
Cc: "Martin J. Dürst"; [email-masked]
Subject: Re: [xml2rfc] Online converter does not detect"<" in attribute values

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.

BR, Julian

---

From: Tony Hansen <[email-masked]>
Date: Thu, 17 Feb 2011 14:10:48 -0500

> suggestions for rcf2629.xslt's, please go ahead.

I'd be interested in hearing suggestions to the HTML output generated by 
xml2rfc.

     Tony Hansen
     [email-masked]

---

From: Tony Hansen <[email-masked]>
Date: Thu, 17 Feb 2011 14:13:31 -0500

I've updated the xml.resource.org/experimental.html page based on 
feedback here.

Hopefully this version is more easily understood. I'm not suggesting 
that it's perfect -- more feedback is welcome.

I'd like to get this pushed out to the public site sometime next week. 
So keep those cards and letters coming.

     Tony Hansen
     [email-masked]