Subject: [xml2rfc] <note> Element Placement
From: [email-masked] (Hollenbeck, Scott)
Date: Wed, 26 Nov 2003 09:15:14 -0500

I just encountered something new when given author's 48-hour review notice
for a soon-to-be-published RFC: the RFC Editor moved a "Conventions Used In
This Document" note (which I had placed in the document using a <note>
element within the <front> element, after the abstract) to a place within my
introduction (part of the <middle>).  While writing a different document I
tried to insert a <note> in an introductory <section> under the <middle>.
With <?rfc strict="yes"?> this <note> element produces an error from
xml2rfc:

"not expecting <note> around line 57"

With <?rfc strict="no"?> there's no error from xml2rfc.  It might be worth
considering allowing <note> elements within the <middle> sections if the RFC
Editor is now placing notes in places other than the <front> section of the
document.

-Scott-

From: [email-masked] (Graham Klyne)
Date: Fri, 21 Nov 2003 18:31:53 +0000
Subject: [xml2rfc] Coding up "difficult" references
Message-ID: <[email-masked]>

This is a real reference from RFC 3629:

[[
[UNICODE]   The Unicode Consortium, "The Unicode Standard -- Version
                4.0",  defined by The Unicode Standard, Version 4.0
                (Boston, MA, Addison-Wesley, 2003.  ISBN 0-321-18578-1),
                April 2003, <http://www.unicode.org/unicode/standard/
                versions/enumeratedversions.html#Unicode_4_0_0>.
]]

What's the best way to code this as an XML2RFC <reference>?  (I can't find 
this in the bibliography library.)  This is my initial stab:
[[
   <reference anchor="ref-Unicode"
    target="http://www.unicode.org/unicode/standard/versions/enumeratedversions.html#Unicode_4_0_0">
     <front>
       <title>The Unicode Standard, Version 4.0</title>
       <author>
         <organization>The Unicode Consortium</organization>
       </author>
       <date month="April" year="2003"/>
     </front>
     <seriesInfo name="Addison-Wesley, Boston, MA." value="ISBN 
0-321-18578-1"/>
   </reference>
]]

Also, here's another to chew on from the same source:
[[
[ISO.10646] International Organization for Standardization,
                "Information Technology - Universal Multiple-octet coded
                Character Set (UCS)", ISO/IEC Standard 10646,  comprised
                of ISO/IEC 10646-1:2000, "Information technology --
                Universal Multiple-Octet Coded Character Set (UCS) --
                Part 1: Architecture and Basic Multilingual Plane",
                ISO/IEC 10646-2:2001, "Information technology --
                Universal Multiple-Octet Coded Character Set (UCS) --
                Part 2:  Supplementary Planes" and ISO/IEC 10646-
                1:2000/Amd 1:2002, "Mathematical symbols and other
                characters".
]]

But for this there is a (much simplified) version in the library.

#g

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

From: [email-masked] (Michael Richardson)
Date: Thu, 20 Nov 2003 14:45:33 -0500
Subject: [xml2rfc] How to review xml2rfc drafts
In-Reply-To: Your message of "Thu, 20 Nov 2003 12:40:55 +0100." <[email-masked]>
Message-ID: <[email-masked]>

I have:
  http://www.sandelman.ca/SSW/freeswan/oeid/change-bars.pl

It takes two copies of a document (.txt), and puts | in front of
lines that were changed. This still isn't what the poster asked for.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

From: [email-masked] (Henrik Levkowetz)
Date: Thu, 20 Nov 2003 17:28:06 +0100
Subject: [xml2rfc] How to review xml2rfc drafts
In-Reply-To: <[email-masked]>
References: <009201c3a96e$42546630$1d848182@DFNJGL21> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

--Signature=_Thu__20_Nov_2003_17_28_06_+0100_bgwKCTBRV8MXptzn
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

> > Note that both this script and Marshall's one mentioned above
> > do diffs of .txt files, they aren't really an answer to the
> > requested xmldiff tool.
> 
> even so, rfcdiff is very, very cool.

Thanks :-)  

Pekka Savola discovered that some older versions of wdiff does not work
well with rfcdiff v0.35; I've tested what is currently downloadable from
http://www.gnu.org/directory/wdiff.html , and that version works. The
version distributed with debian also works fine. 

I'll add a version check on wdiff to the next distributed version of
rfcdiff, to try to avoid broken wdiffs.

	Henrik

--Signature=_Thu__20_Nov_2003_17_28_06_+0100_bgwKCTBRV8MXptzn
Content-Type: application/pgp-signature

--Signature=_Thu__20_Nov_2003_17_28_06_+0100_bgwKCTBRV8MXptzn--

From: [email-masked] (Marshall Rose)
Date: Thu, 20 Nov 2003 08:06:35 -0800
Subject: [xml2rfc] How to review xml2rfc drafts
In-Reply-To: <[email-masked]>
References: <009201c3a96e$42546630$1d848182@DFNJGL21> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> 
> Note that both this script and Marshall's one mentioned above
> do diffs of .txt files, they aren't really an answer to the
> requested xmldiff tool.

even so, rfcdiff is very, very cool.

/mtr

From: [email-masked] (Henrik Levkowetz)
Date: Thu, 20 Nov 2003 12:40:55 +0100
Subject: [xml2rfc] How to review xml2rfc drafts
In-Reply-To: <[email-masked]>
References: <009201c3a96e$42546630$1d848182@DFNJGL21> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

--Signature=_Thu__20_Nov_2003_12_40_55_+0100_=pzFEtvugKzsU1uj
Content-Type: multipart/mixed;
 boundary="Multipart=_Thu__20_Nov_2003_12_40_55_+0100_kwoWJXhTGrUbYsUJ"

--Multipart=_Thu__20_Nov_2003_12_40_55_+0100_kwoWJXhTGrUbYsUJ
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

On Saturday, 15 Nov 2003, Marshall wrote:

> > > I just confused Bob Braden by sending a review for an .xml file that I
> > > had just typed text into - people can see diffs in the text, but it's
> > > not pretty, and it would be nice to have a <review reviewer=spencer>
> > > brilliant observation </review> tag to use in this situation. How do
> > > other people do this, with non-XML-literate participants?
> > 
> > 1. send a diff of the old and new txt files
> > 
> > 2. find an xmldiff tool that produces xml
> 
> attached is htmlwdiff.sh, which uses the wdiff program you can find on most
> systems... (or at ftp://gnu.org/gnu/wdiff)
> 
> 	./htmlwdiff.sh oldfile.txt newfile.txt > diffs.html
> 
> /mtr
> 

Or if you'd like a side-by-side html diff you might use the
attached rfcdiff script. It uses awk and diff to do much of
the processing, and also wdiff if it can find it. Try

	./rfcdiff --browse draft-xxx-00.txt draft-xxx-01.txt
or
	./rfcdiff --help

Note that both this script and Marshall's one mentioned above
do diffs of .txt files, they aren't really an answer to the
requested xmldiff tool.

	Henrik

--Multipart=_Thu__20_Nov_2003_12_40_55_+0100_kwoWJXhTGrUbYsUJ
Content-Type: application/octet-stream;
 name="rfcdiff"
Content-Disposition: attachment;
 filename="rfcdiff"
Content-Transfer-Encoding: base64

--Multipart=_Thu__20_Nov_2003_12_40_55_+0100_kwoWJXhTGrUbYsUJ--

--Signature=_Thu__20_Nov_2003_12_40_55_+0100_=pzFEtvugKzsU1uj
Content-Type: application/pgp-signature

--Signature=_Thu__20_Nov_2003_12_40_55_+0100_=pzFEtvugKzsU1uj--

From: [email-masked] (Fred Baker)
Date: Wed, 19 Nov 2003 18:08:01 -0800
Subject: [xml2rfc] URL/URI in references
In-Reply-To: <[email-masked]. ca.us>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked] >

At 03:38 PM 11/19/2003, Marshall Rose wrote:
>the .txt/.nr versions don't do anything with the target attribute in
><format/> element. however, they do do something with the target
>attribute in the <reference/> element, i.e.,
>
>     <reference anchor="FOO1" target="http://...">

great. Thanks. 

From: [email-masked] (Marshall Rose)
Date: Wed, 19 Nov 2003 15:38:09 -0800
Subject: [xml2rfc] URL/URI in references
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> At the moment, I am including the URL in the title to get it to show up in 
> the .txt output.
> 
> I feel I must be missing something. Care to clue me in as to what?

the .txt/.nr versions don't do anything with the target attribute in
<format/> element. however, they do do something with the target
attribute in the <reference/> element, i.e.,
    
    <reference anchor="FOO1" target="http://...">
        <front> ... </front>
	<seriesInfo ... />
        ...
        <format ... />
        ...
    </reference>
    
/mtr

From: [email-masked] (Fred Baker)
Date: Wed, 19 Nov 2003 13:39:50 -0800
Subject: [xml2rfc] URL/URI in references
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked] >

I have sme URLs I would like to point people to in a draft. In the 
<reference> sectio, I have a <format> and a <uri> clause. The former causes 
the HTML version to emit a hyperlink, which is wonderful. No URL shows in 
the .txt version, however, which makes for an issue.

At the moment, I am including the URL in the title to get it to show up in 
the .txt output.

I feel I must be missing something. Care to clue me in as to what?

From: [email-masked] (Julian Reschke)
Date: Mon, 17 Nov 2003 12:08:03 +0100
Subject: [xml2rfc] ANN: conversions to CHM and PDF (via XSL-FO), documentation
Message-ID: <[email-masked]>

Hi,

I finally got around to clean up the documentation for rfc2629.xslt, and 
also to release experimental versions of XSLTs that

- create Microsoft CHM (Compiled Windows Help) and
- PDF (through XSL-FO).

The complete distribution is available from

<http://greenbytes.de/tech/webdav/rfc2629xslt.zip>

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Clive D.W. Feather)
Date: Mon, 17 Nov 2003 07:53:37 +0000
Subject: [xml2rfc] ToC style: nested?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Pekka Savola said:
> Is there an option to generate a nested ToC?  I didn't find one myself.

Related to this, can I once again request something I've asked before? That
is, a way to omit a section from the ToC.

We have a *lot* of sections in our document (NNTP) and the table of
contents is ridiculously large. Because of the way it's organised, I can't
just truncate the ToC at a given level. So I've added an "intoc" attribute
to <section>, defaulting to "true".  Every time there's a new release
of xml2rfc I hack this feature in - it's only about 3 lines of code - so it
would be really nice to have as official.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646

From: [email-masked] (Marshall Rose)
Date: Sun, 16 Nov 2003 20:57:53 -0800
Subject: [xml2rfc] location of references in I-D
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> rfc2223bis states that appendices should precede references, which 
> should directly precede the author's address. I've tried to follow 
> this by arranging my XML as follows:
    
your mistake is in using 2223bis as the baseline -- it hasn't been
approved yet.
    
you want
    
    <back>
    <references/>
    <references/>
    <section/>
    <section/>
    ...
    </back>

From: [email-masked] (Peter Saint-Andre)
Date: Sun, 16 Nov 2003 21:57:02 -0600
Subject: [xml2rfc] location of references in I-D
Message-ID: <[email-masked]>

Hi,

rfc2223bis states that appendices should precede references, which 
should directly precede the author's address. I've tried to follow 
this by arranging my XML as follows:

   <back>
     <section>Appendix A</section>
     <section>Appendix B</section>
     <section>
       <section>Appendix C.1</section>
       <section>Appendix C.2</section>
     </section>
     <references>
       <reference>ref1</reference>
       <reference>ref2</reference>
     </references>
   </back>

I get the following results:

   a. The author's address appears after the last section of the
      <middle> but before the appendices.

   b. In the text, the references appear after the last section of 
      the <middle> but before the appendices; however, in the table
      of contents, the references appear between the penultimate
      and ultimate subsections of the final appendix.

Suggestions would be most welcome.

Thanks!

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.php

From: [email-masked] (Julian Reschke)
Date: Sun, 16 Nov 2003 19:57:03 +0100
Subject: [xml2rfc] figures inside lists
Message-ID: <[email-masked]>

Hi,

for a change, here's an issue with *existing* functionality that I'd 
like to see resolved.

The updated DTD allows <figure>s inside <t>ext, however discourages it 
(says it's deprecated). This makes complete sense as figures are usually 
float inside the page. And in fact, xml2rfc produces (probably 
unintenionally) different results for TXT and HTML output:

- when generating HTML, an inline HTML <img> element is created, and 
this indents just like the surrounding text

- when producing TXT, the figure is left-aligned.

I don't have a problem with deprecating usage of <figure> inside <t>. 
However, I think we need sort of a replacement where a paragraph or a 
list contains text that is supposed to show up as monospaced, with 
whitespace being significant.

For instance, consider the following text from RFC3253, section 4.4:

    Marshalling:

       If a request body is included, it MUST be a DAV:checkin XML
       element.

       <!ELEMENT checkin ANY>
       ANY value: A sequence of elements with at most one
       DAV:keep-checked-out element and at most one DAV:fork-ok element.

       <!ELEMENT keep-checked-out EMPTY>
       <!ELEMENT fork-ok EMPTY>

       If a response body for a successful request is included, it MUST
       be a DAV:checkin-response XML element.

       <!ELEMENT checkin-response ANY>

       The response MUST include a Cache-Control:no-cache header.

The DTD fragments can not be produced using simple <t> elements as

- the position of newlines is significant (in some other cases spaces 
may be significant, too) and
- when producing anything but TXT, you want a monospaced font.

I'm not sure what the best way to accomplish this would be. One option 
that comes to mind is to allow <artwork> inside lists (or more generally 
to allow <artwork> representing mono-spaced text in which whitespace is 
relevant anywhere where <t> is allowed).

Feedback appreciated,

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Marshall Rose)
Date: Sat, 15 Nov 2003 18:27:52 -0600
Subject: [xml2rfc] How to review xml2rfc drafts
In-Reply-To: <[email-masked]>
References: <009201c3a96e$42546630$1d848182@DFNJGL21> <[email-masked]>
Message-ID: <[email-masked]>

This is a multi-part message in MIME format.

--Multipart_Sat__15_Nov_2003_18:27:52_-0600_096bcc00
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

> > I just confused Bob Braden by sending a review for an .xml file that I
> > had just typed text into - people can see diffs in the text, but it's
> > not pretty, and it would be nice to have a <review reviewer=spencer>
> > brilliant observation </review> tag to use in this situation. How do
> > other people do this, with non-XML-literate participants?
> 
> 1. send a diff of the old and new txt files
> 
> 2. find an xmldiff tool that produces xml

attached is htmlwdiff.sh, which uses the wdiff program you can find on most
systems... (or at ftp://gnu.org/gnu/wdiff)

	./htmlwdiff.sh oldfile.txt newfile.txt > diffs.html

/mtr

--Multipart_Sat__15_Nov_2003_18:27:52_-0600_096bcc00
Content-Type: application/x-sh;
 name="htmlwdiff.sh"
Content-Disposition: attachment;
 filename="htmlwdiff.sh"
Content-Transfer-Encoding: base64

ICRhMQpybSAtZiAkYTIK

--Multipart_Sat__15_Nov_2003_18:27:52_-0600_096bcc00--

From: [email-masked] (Marshall Rose)
Date: Sat, 15 Nov 2003 16:57:46 -0600
Subject: [xml2rfc] ToC style: nested?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> >    1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
> >    2.   The BEEP Core  . . . . . . . . . . . . . . . . . . . . . . .   5
> >      2.1   Roles  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
> 
> At least the leaders should be aligned, IMHO.

good catch!
    
/mtr

From: [email-masked] (Aaron Falk)
Date: Sat, 15 Nov 2003 12:23:15 -0800
Subject: [xml2rfc] RFC editor accepting XML?
Message-ID: <[email-masked]>

Yep.  The RFC Editor will accept xml2rfc-generated nroff or xml.  At 
this time the editing is still being done in nroff and the generated 
nroff is tidy enough that it's a time saver for us.

Note that the text produced by submitted nroff/xml should produce a 
null diff when compared to the published Internet draft.

--aaron

On Nov 14, 2003, at 12:58 PM, Graham Klyne wrote:

> According to this informal note by Spencer Dawkins concerning the IETF
> plenaries:
> [[
> - RFC Editor Report - Joyce Reynolds
>    Mark Crispin - can I have nroff source back?
>      Yes, and we are also accepting XML - don't start over!
> ]]
>
> Is it true that the RFC editor is now accepting XML2RFC?
>
> #g
>
>
> ------------
> Graham Klyne
> For email:
> http://www.ninebynine.org/#Contact
>
>
> --__--__--

From: [email-masked] (Henrik Levkowetz)
Date: Sat, 15 Nov 2003 15:35:28 +0100
Subject: [xml2rfc] ToC style: nested?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

--Signature=_Sat__15_Nov_2003_15_35_28_+0100_.vLZax4qTq7aebcS
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Friday 14 November 2003, Pekka wrote:
> On Fri, 14 Nov 2003, Henrik Levkowetz wrote:
> >    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
> >    2.  The BEEP Core  . . . . . . . . . . . . . . . . . . . . . . . .  5
> >        2.1  Roles   . . . . . . . . . . . . . . . . . . . . . . . . .  6
> >             2.1.1  Exchange Styles  . . . . . . . . . . . . . . . . .  6
> 
> 
> .. might have problems with header lengths.

Occationally I've had to wrap them. I don't mind, really.

> Another thing: if the subsection number is at least 10, could be 
> problematic.

Not really. But you might need to choose different indentations than the
exact numbers I mentioned earlier. Here are two examples. The first is
taken directly from the current EAP draft, and uses the solution I
currently have in the awk postprocessing script:
   7.    Security Considerations  . . . . . . . . . . . . . . . . . . 41
         7.1   Threat model . . . . . . . . . . . . . . . . . . . . . 42
         7.2   Security claims  . . . . . . . . . . . . . . . . . . . 43
               7.2.1 Security claims terminology for EAP methods  . . 44
         7.3   Identity protection  . . . . . . . . . . . . . . . . . 46
         7.4   Man-in-the-middle attacks  . . . . . . . . . . . . . . 46
         7.5   Packet modification attacks  . . . . . . . . . . . . . 47
         7.6   Dictionary attacks . . . . . . . . . . . . . . . . . . 49
         7.7   Connection to an untrusted network . . . . . . . . . . 49
         7.8   Negotiation attacks  . . . . . . . . . . . . . . . . . 49
         7.9   Implementation idiosyncrasies  . . . . . . . . . . . . 50
         7.10  Key derivation . . . . . . . . . . . . . . . . . . . . 50
         7.11  Weak ciphersuites  . . . . . . . . . . . . . . . . . . 52
         7.12  Link layer . . . . . . . . . . . . . . . . . . . . . . 53
         7.13  Separation of authenticator and backend authentication
         server . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
         7.14  Cleartext Passwords  . . . . . . . . . . . . . . . . . 55

Or you could just bump the indentation when you reach 10:
   7.    Security Considerations  . . . . . . . . . . . . . . . . . . 41
         7.1  Threat model . . . . . . . . . . . . . . . . . . . . . 42
         7.2  Security claims  . . . . . . . . . . . . . . . . . . . 43
              7.2.1 Security claims terminology for EAP methods  . . 44
         7.3  Identity protection  . . . . . . . . . . . . . . . . . 46
         7.4  Man-in-the-middle attacks  . . . . . . . . . . . . . . 46
         7.5  Packet modification attacks  . . . . . . . . . . . . . 47
         7.6  Dictionary attacks . . . . . . . . . . . . . . . . . . 49
         7.7  Connection to an untrusted network . . . . . . . . . . 49
         7.8  Negotiation attacks  . . . . . . . . . . . . . . . . . 49
         7.9  Implementation idiosyncrasies  . . . . . . . . . . . . 50
         7.10  Key derivation . . . . . . . . . . . . . . . . . . . . 50
         7.11  Weak ciphersuites  . . . . . . . . . . . . . . . . . . 52
         7.12  Link layer . . . . . . . . . . . . . . . . . . . . . . 53
         7.13  Separation of authenticator and backend authentication
         server . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
         7.14  Cleartext Passwords  . . . . . . . . . . . . . . . . . 55

I'm sure there are other ways, too.

	Henrik

--Signature=_Sat__15_Nov_2003_15_35_28_+0100_.vLZax4qTq7aebcS
Content-Type: application/pgp-signature

--Signature=_Sat__15_Nov_2003_15_35_28_+0100_.vLZax4qTq7aebcS--

From: [email-masked] (Florian Weimer)
Date: Sat, 15 Nov 2003 10:54:17 +0100
Subject: [xml2rfc] ToC style: nested?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:

>    1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
>    2.   The BEEP Core  . . . . . . . . . . . . . . . . . . . . . . .   5
>      2.1   Roles  . . . . . . . . . . . . . . . . . . . . . . . . . .  6

At least the leaders should be aligned, IMHO.

From: [email-masked] (Graham Klyne)
Date: Fri, 14 Nov 2003 20:58:48 +0000
Subject: [xml2rfc] RFC editor accepting XML?
Message-ID: <[email-masked]>

According to this informal note by Spencer Dawkins concerning the IETF 
plenaries:
[[
- RFC Editor Report - Joyce Reynolds
   Mark Crispin - can I have nroff source back?
     Yes, and we are also accepting XML - don't start over!
]]

Is it true that the RFC editor is now accepting XML2RFC?

#g

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

From: [email-masked] (Pekka Savola)
Date: Fri, 14 Nov 2003 20:11:22 +0200 (EET)
Subject: [xml2rfc] ToC style: nested?
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

On Fri, 14 Nov 2003, Henrik Levkowetz wrote:
>    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
>    2.  The BEEP Core  . . . . . . . . . . . . . . . . . . . . . . . .  5
>        2.1  Roles   . . . . . . . . . . . . . . . . . . . . . . . . .  6
>             2.1.1  Exchange Styles  . . . . . . . . . . . . . . . . .  6

.. might have problems with header lengths.

Another thing: if the subsection number is at least 10, could be 
problematic.

IMHO,  very simple indentation is enough, but YMMV.
-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From: [email-masked] (Henrik Levkowetz)
Date: Fri, 14 Nov 2003 18:41:51 +0100
Subject: [xml2rfc] ToC style: nested?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Friday 14 November 2003, Marshall wrote:
> would you prefer this:
>     
> Table of Contents
> 
>    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
>    2.  The BEEP Core  . . . . . . . . . . . . . . . . . . . . . . . .  5
>      2.1  Roles  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
>        2.1.1  Exchange Styles  . . . . . . . . . . . . . . . . . . .   6
>      2.2  Messages and Frames  . . . . . . . . . . . . . . . . . . .   7
>        2.2.1  Frame Syntax . . . . . . . . . . . . . . . . . . . . .   8
>        2.2.2  Frame Semantics  . . . . . . . . . . . . . . . . . . .  14
>      2.3  Channel Management . . . . . . . . . . . . . . . . . . . .  15
>        2.3.1  Message Semantics  . . . . . . . . . . . . . . . . . .  16
>      2.4  Session Establishment and Release  . . . . . . . . . . . .  25
>      2.5  Transport Mappings . . . . . . . . . . . . . . . . . . . .  27

On my part, I'd prefer this:

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  The BEEP Core  . . . . . . . . . . . . . . . . . . . . . . . .  5
       2.1  Roles   . . . . . . . . . . . . . . . . . . . . . . . . .  6
            2.1.1  Exchange Styles  . . . . . . . . . . . . . . . . .  6
       2.2  Messages and Frames   . . . . . . . . . . . . . . . . . .  7
            2.2.1  Frame Syntax   . . . . . . . . . . . . . . . . . .  8
            2.2.2  Frame Semantics  . . . . . . . . . . . . . . . . . 14
       2.3  Channel Management  . . . . . . . . . . . . . . . . . . . 15
            2.3.1  Message Semantics  . . . . . . . . . . . . . . . . 16
       2.4  Session Establishment and Release . . . . . . . . . . . . 25
       2.5  Transport Mappings. . . . . . . . . . . . . . . . . . . . 27

i.e., for each new indentation level, I'd like the section numbers to line
up with the start of the section title of the previous level. This would
have been trivial if indentation was a fixed number of spaces times the
indentation level, but here the indentation instead follows the pattern

	level	indentation
	1	3
	2	3 +4
	3	3 +4+5
	4	3 +4+5+7
	5	3 +4+5+7+9

etc.

To me, this sure looks nice, though...

	Henrik

From: [email-masked] (Marshall Rose)
Date: Fri, 14 Nov 2003 08:57:49 -0600
Subject: [xml2rfc] ToC style: nested?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Btw, was the different level level of indentation for different depts of
> nesting intentional?  The third level should also have 2 spaces (for
> clarity, 1 is a tad too little), I guess?

would you prefer this:
    
Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  The BEEP Core  . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1  Roles  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
       2.1.1  Exchange Styles  . . . . . . . . . . . . . . . . . . .   6
     2.2  Messages and Frames  . . . . . . . . . . . . . . . . . . .   7
       2.2.1  Frame Syntax . . . . . . . . . . . . . . . . . . . . .   8
       2.2.2  Frame Semantics  . . . . . . . . . . . . . . . . . . .  14
     2.3  Channel Management . . . . . . . . . . . . . . . . . . . .  15
       2.3.1  Message Semantics  . . . . . . . . . . . . . . . . . .  16
     2.4  Session Establishment and Release  . . . . . . . . . . . .  25
     2.5  Transport Mappings . . . . . . . . . . . . . . . . . . . .  27
       2.5.1  Session Management . . . . . . . . . . . . . . . . . .  27
       2.5.2  Message Exchange . . . . . . . . . . . . . . . . . . .  27
     2.6  Asynchrony . . . . . . . . . . . . . . . . . . . . . . . .  28
       2.6.1  Within a Single Channel  . . . . . . . . . . . . . . .  28
       2.6.2  Between Different Channels . . . . . . . . . . . . . .  28
       2.6.3  Pre-emptive Replies  . . . . . . . . . . . . . . . . .  29
       2.6.4  Interference . . . . . . . . . . . . . . . . . . . . .  29
     2.7  Peer-to-Peer Behavior  . . . . . . . . . . . . . . . . . .  30
   3.  Transport Security . . . . . . . . . . . . . . . . . . . . . . 31
     3.1  The TLS Transport Security Profile . . . . . . . . . . . .  34
       3.1.1  Profile Identification and Initialization  . . . . . .  34
       3.1.2  Message Syntax . . . . . . . . . . . . . . . . . . . .  35
       3.1.3  Message Semantics  . . . . . . . . . . . . . . . . . .  36
   4.  User Authentication  . . . . . . . . . . . . . . . . . . . . . 37
     4.1  The SASL Family of Profiles  . . . . . . . . . . . . . . .  38
       4.1.1  Profile Identification and Initialization  . . . . . .  39
       4.1.2  Message Syntax . . . . . . . . . . . . . . . . . . . .  41
       4.1.3  Message Semantics  . . . . . . . . . . . . . . . . . .  42
   5.  Registration Templates . . . . . . . . . . . . . . . . . . . . 43
     5.1  Profile Registration Template  . . . . . . . . . . . . . .  43
     5.2  Feature Registration Template  . . . . . . . . . . . . . .  43
   6.  Initial Registrations  . . . . . . . . . . . . . . . . . . . . 44
     6.1  Registration: BEEP Channel Management  . . . . . . . . . .  44
     6.2  Registration: TLS Transport Security Profile . . . . . . .  44
     6.3  Registration: SASL Family of Profiles and assorted
          things for a really, really long, section title and, i
          really do mean really, really, really long, got that?  . .  45
     6.4  Registration: application/beep+xml . . . . . . . . . . . .  46
   7.  DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
     7.1  BEEP Channel Management DTD  . . . . . . . . . . . . . . .  47
     7.2  TLS Transport Security Profile DTD . . . . . . . . . . . .  49
     7.3  SASL Family of Profiles DTD  . . . . . . . . . . . . . . .  50
   8.  Reply Codes  . . . . . . . . . . . . . . . . . . . . . . . . . 51
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 52
       References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 54
   A.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 55
   B.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 56
       Intellectual Property and Copyright Statements . . . . . . . . 57

From: [email-masked] (Alex Rousskov)
Date: Thu, 13 Nov 2003 16:37:26 -0700 (MST)
Subject: [xml2rfc] feature request for tagging publication related information
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <20031112215912.GH2596@sbrim-w2k01> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Fri, 14 Nov 2003, Julian Reschke wrote:

> Marshall Rose wrote:
> >>Although I like Alex' suggestions, my original proposal was IMHO a bit
> >>more focused on just the publication workflow step -- so maybe it makes
> >>sense to concentrate on that.
> >
> >
> > so, are you suggesting something different than alex's write-up? if so, what is
> > the concise description?
>
> What I wanted to suggest is that if you're uncomfortable integrating
> issue tracking/markup (only in that case :-), it may make sense to
> go back to my original proposal, because it was somewhat simpler:
>
> <http://lists.xml.resource.org/pipermail/xml2rfc/2003-November/000908.html>

Hm. In other words, both Jualian and I prefer (or at least have no big
problems with) the following summary:

	http://lists.xml.resource.org/pipermail/xml2rfc/2003-November/000928.html

but if you would rather go back to Jualian's original suggestion that
morphs together issue tracking and not-for-publication semantics, it
is summarized here:

	http://lists.xml.resource.org/pipermail/xml2rfc/2003-November/000908.html

Alex.

From: [email-masked] (Pekka Savola)
Date: Fri, 14 Nov 2003 01:26:13 +0200 (EET)
Subject: [xml2rfc] ToC style: nested?
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

On Thu, 13 Nov 2003, Marshall Rose wrote:
> this is doable, although i think of it more as indentation than nesting, sine
> it lets you select the nesting depth now...
>     
> take a look at the example below. i think it implements the algorithm
> you described it match your expectations?
> 
>    1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
>    2.   The BEEP Core  . . . . . . . . . . . . . . . . . . . . . . .   5
>      2.1   Roles  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
>       2.1.1   Exchange Styles  . . . . . . . . . . . . . . . . . . .   6

Yep, I don't know about the right terminology, indentation seems best
though, but this seems like the thing I wanted, thanks!

Btw, was the different level level of indentation for different depts of
nesting intentional?  The third level should also have 2 spaces (for
clarity, 1 is a tad too little), I guess?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From: [email-masked] (Julian Reschke)
Date: Fri, 14 Nov 2003 00:18:34 +0100
Subject: [xml2rfc] feature request for tagging publication related information
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<20031112215912.GH2596@sbrim-w2k01>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:
>>Although I like Alex' suggestions, my original proposal was IMHO a bit 
>>more focused on just the publication workflow step -- so maybe it makes 
>>sense to concentrate on that.
> 
> 
> so, are you suggesting something different than alex's write-up? if so, what is
> the concise description?

Hm.

What I wanted to suggest is that if you're uncomfortable integrating 
issue tracking/markup (only in that case :-), it may make sense to go 
back to my original proposal, because it was somewhat simpler:

<http://lists.xml.resource.org/pipermail/xml2rfc/2003-November/000908.html>

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Marshall Rose)
Date: Thu, 13 Nov 2003 16:08:36 -0600
Subject: [xml2rfc] feature request for tagging publication related information
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <20031112215912.GH2596@sbrim-w2k01> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Although I like Alex' suggestions, my original proposal was IMHO a bit 
> more focused on just the publication workflow step -- so maybe it makes 
> sense to concentrate on that.

so, are you suggesting something different than alex's write-up? if so, what is
the concise description?

/mtr

From: [email-masked] (Marshall Rose)
Date: Thu, 13 Nov 2003 16:06:01 -0600
Subject: [xml2rfc] ToC style: nested?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> ...

this is doable, although i think of it more as indentation than nesting, sine
it lets you select the nesting depth now...
    
take a look at the example below. i think it implements the algorithm
you described it match your expectations?

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.   The BEEP Core  . . . . . . . . . . . . . . . . . . . . . . .   5
     2.1   Roles  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
      2.1.1   Exchange Styles  . . . . . . . . . . . . . . . . . . .   6
     2.2   Messages and Frames  . . . . . . . . . . . . . . . . . . .  7
      2.2.1   Frame Syntax . . . . . . . . . . . . . . . . . . . . .   8
      2.2.2   Frame Semantics  . . . . . . . . . . . . . . . . . . .  14
     2.3   Channel Management . . . . . . . . . . . . . . . . . . . . 15
      2.3.1   Message Semantics  . . . . . . . . . . . . . . . . . .  16
     2.4   Session Establishment and Release  . . . . . . . . . . . . 25
     2.5   Transport Mappings . . . . . . . . . . . . . . . . . . . . 27
      2.5.1   Session Management . . . . . . . . . . . . . . . . . .  27
      2.5.2   Message Exchange . . . . . . . . . . . . . . . . . . .  27
     2.6   Asynchrony . . . . . . . . . . . . . . . . . . . . . . . . 28
      2.6.1   Within a Single Channel  . . . . . . . . . . . . . . .  28
      2.6.2   Between Different Channels . . . . . . . . . . . . . .  28
      2.6.3   Pre-emptive Replies  . . . . . . . . . . . . . . . . .  29
      2.6.4   Interference . . . . . . . . . . . . . . . . . . . . .  29
     2.7   Peer-to-Peer Behavior  . . . . . . . . . . . . . . . . . . 30
   3.   Transport Security . . . . . . . . . . . . . . . . . . . . .  31
     3.1   The TLS Transport Security Profile . . . . . . . . . . . . 34
      3.1.1   Profile Identification and Initialization  . . . . . .  34
      3.1.2   Message Syntax . . . . . . . . . . . . . . . . . . . .  35
      3.1.3   Message Semantics  . . . . . . . . . . . . . . . . . .  36
   4.   User Authentication  . . . . . . . . . . . . . . . . . . . .  37
     4.1   The SASL Family of Profiles  . . . . . . . . . . . . . . . 38
      4.1.1   Profile Identification and Initialization  . . . . . .  39
      4.1.2   Message Syntax . . . . . . . . . . . . . . . . . . . .  41
      4.1.3   Message Semantics  . . . . . . . . . . . . . . . . . .  42
   5.   Registration Templates . . . . . . . . . . . . . . . . . . .  43
     5.1   Profile Registration Template  . . . . . . . . . . . . . . 43
     5.2   Feature Registration Template  . . . . . . . . . . . . . . 43
   6.   Initial Registrations  . . . . . . . . . . . . . . . . . . .  44
     6.1   Registration: BEEP Channel Management  . . . . . . . . . . 44
     6.2   Registration: TLS Transport Security Profile . . . . . . . 44
     6.3   Registration: SASL Family of Profiles and assorted
           things for a really, really long, section title and, i
           really do mean really, really, really long, got that?  . . 45
     6.4   Registration: application/beep+xml . . . . . . . . . . . . 46
   7.   DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . . .  47
     7.1   BEEP Channel Management DTD  . . . . . . . . . . . . . . . 47
     7.2   TLS Transport Security Profile DTD . . . . . . . . . . . . 49
     7.3   SASL Family of Profiles DTD  . . . . . . . . . . . . . . . 50
   8.   Reply Codes  . . . . . . . . . . . . . . . . . . . . . . . .  51
   9.   Security Considerations  . . . . . . . . . . . . . . . . . .  52
        References . . . . . . . . . . . . . . . . . . . . . . . . .  53
        Author's Address . . . . . . . . . . . . . . . . . . . . . .  54
   A.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  55
   B.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  56
        Intellectual Property and Copyright Statements . . . . . . .  57
    
thanks!

/mtr

From: [email-masked] (Julian Reschke)
Date: Thu, 13 Nov 2003 10:20:24 +0100
Subject: [xml2rfc] feature request for tagging publication related information
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<20031112215912.GH2596@sbrim-w2k01>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:

>>Re: issue tracking. I think this is useful as well, and my rfc2629.xslt 
>>already supports some kind of "poor man's change and issue" tracking. 
>>Those who haven't seen that yet may want to check out the XML and HTML 
>>examples on <http://greenbytes.de/tech/webdav/>.
> 
> 
> can you point to one representative file?

Sure:

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-acl-latest.xml>
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-acl-latest.html>
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-acl-latest.txt>

Basically I have

1) issue tracking: ed:issue (with entry and resolution sub-elemenents) and
2) change tracking: ed:ins/ed:del (with an ed:replace container)

Issues have hrefs (for instance, mailing list entry), identifiers, 
dates...; changes keep track of when, why (link to issue), who entered it...

The format works for me but probably is hard to handle for those who 
don't spend as much time with XML as I do. It's greatest benefits are:

- issues and change tracking embedded
- when releasing a new I-D, I can automatically remove all ed:del 
artifacts and all closed issues
- I can generate an appendix summarizing open and closed issues for this 
draft
- automatical generation of stand-alone issues document, such as 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-acl-issues.html>

I am mentioning this to illustrate that it may make sense to implement 
this kind of stuff outside of xml2rfc (with a conversion option to 
"plain" xml2rfc format). This allows playing around with the format 
without having to worry too much about backwards compatibility...

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Henrik Levkowetz)
Date: Thu, 13 Nov 2003 04:32:27 +0100
Subject: [xml2rfc] ToC style: nested?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

This is a multi-part message in MIME format.

--Multipart=_Thu__13_Nov_2003_04_32_27_+0100_duAW=3/dD+mX+D=b
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Thursday 13 November 2003, Pekka wrote:
> Is there an option to generate a nested ToC?  I didn't find one myself.

I would like that. I would like it enough that I currently post-process
xml2rfc output through an awk script (attached) to generate nested ToC.

	Henrik

--Multipart=_Thu__13_Nov_2003_04_32_27_+0100_duAW=3/dD+mX+D=b
Content-Type: application/octet-stream;
 name="rfctocfix"
Content-Disposition: attachment;
 filename="rfctocfix"
Content-Transfer-Encoding: base64

--Multipart=_Thu__13_Nov_2003_04_32_27_+0100_duAW=3/dD+mX+D=b--

From: [email-masked] (Henrik Levkowetz)
Date: Thu, 13 Nov 2003 04:13:02 +0100
Subject: [xml2rfc] How to review xml2rfc drafts
In-Reply-To: <009201c3a96e$42546630$1d848182@DFNJGL21>
References: <009201c3a96e$42546630$1d848182@DFNJGL21>
Message-ID: <[email-masked]>

Hi Spencer,

Wednesday 12 November 2003, Spencer wrote:
> I just confused Bob Braden by sending a review for an .xml file that I
> had just typed text into - people can see diffs in the text, but it's
> not pretty, and it would be nice to have a <review reviewer=spencer>
> brilliant observation </review> tag to use in this situation. How do
> other people do this, with non-XML-literate participants?

While happily using .xml and xml2rfc to produce drafts, I find it works
best to do reviews on the .txt form.

I generally use a comment format which can be automatically marked up as
html with colour coding of comments for easier consumption; there's a
sample here:

 Plain text:
  http://levkowetz.com/pub/ietf/reviews/review-ietf-mobileip-rfc3012bis-05.txt

 Marked up:
  http://www.levkowetz.com/ietf/rfcmarkup.cgi?url=http://levkowetz.com/pub/ietf/reviews/review-ietf-mobileip-rfc3012bis-05.txt&comments=HENRIK

	Regards,
		Henrik

From: [email-masked] (Pekka Savola)
Date: Thu, 13 Nov 2003 05:12:51 +0200 (EET)
Subject: [xml2rfc] ToC style: nested?
Message-ID: <[email-masked]>

Hi,

Is there an option to generate a nested ToC?  I didn't find one myself.

That is, instead of:

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Different Ways to Implement Ingress Filtering  . . . . . . . .  4
   2.1 Ingress Access Lists . . . . . . . . . . . . . . . . . . . . .  4
   2.2 Strict Reverse Path Forwarding . . . . . . . . . . . . . . . .  4

.. I'd like:

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Different Ways to Implement Ingress Filtering  . . . . . . . .  4
      2.1 Ingress Access Lists . . . . . . . . . . . . . . . . . . . . 4
      2.2 Strict Reverse Path Forwarding . . . . . . . . . . . . . . . 4

.. i.e., make it a 2/3 spaces per the level of nesting.  This actually 
improves the readability of the ToCs a *lot* ?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From: [email-masked] (Alex Rousskov)
Date: Wed, 12 Nov 2003 16:34:03 -0700 (MST)
Subject: [xml2rfc] How to review xml2rfc drafts
In-Reply-To: <009201c3a96e$42546630$1d848182@DFNJGL21>
References: <009201c3a96e$42546630$1d848182@DFNJGL21>
Message-ID: <[email-masked]>

On Wed, 12 Nov 2003, Spencer Dawkins wrote:

> I'm a very happy xml2rfc author, and a very confused reviewer.
>
> I just confused Bob Braden by sending a review for an .xml file that
> I had just typed text into - people can see diffs in the text, but
> it's not pretty, and it would be nice to have a <review
> reviewer=spencer> brilliant observation </review> tag to use in this
> situation. How do other people do this, with non-XML-literate
> participants?

For non-XML-literate participants, using the plain text version for
review works the best for me. Moreover, I prefer to _receive_ plain
text reviews as well, after spending too much time applying
Word-tracked changes submitted by a reviewer to my XML sources :-).

The biggest disadvantage of plain text reviews is that they cannot
review original XML markup, I guess. That does not sound like a big
deal for now, but may become a problem long-term.

For XML-literate participants, the proposed <issue> element would be
useful here, especially if an author and/or role attributes are added
to it. A dedicate <review> element has its advantages as well, as
usual.

Alex.

From: [email-masked] (Marshall Rose)
Date: Wed, 12 Nov 2003 17:27:43 -0600
Subject: [xml2rfc] How to review xml2rfc drafts
In-Reply-To: <009201c3a96e$42546630$1d848182@DFNJGL21>
References: <009201c3a96e$42546630$1d848182@DFNJGL21>
Message-ID: <[email-masked]>

> I just confused Bob Braden by sending a review for an .xml file that I
> had just typed text into - people can see diffs in the text, but it's
> not pretty, and it would be nice to have a <review reviewer=spencer>
> brilliant observation </review> tag to use in this situation. How do
> other people do this, with non-XML-literate participants?

1. send a diff of the old and new txt files

2. find an xmldiff tool that produces xml
    
/mtr

From: [email-masked] (Marshall Rose)
Date: Wed, 12 Nov 2003 17:26:15 -0600
Subject: [xml2rfc] feature request for tagging publication related information
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <20031112215912.GH2596@sbrim-w2k01> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Re: issue tracking. I think this is useful as well, and my rfc2629.xslt 
> already supports some kind of "poor man's change and issue" tracking. 
> Those who haven't seen that yet may want to check out the XML and HTML 
> examples on <http://greenbytes.de/tech/webdav/>.

can you point to one representative file?

/mtr

From: [email-masked] (Julian Reschke)
Date: Thu, 13 Nov 2003 00:21:01 +0100
Subject: [xml2rfc] feature request for tagging publication related information
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<20031112215912.GH2596@sbrim-w2k01>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:

>>Given the objections to a simpler onPublication interface, I suspect
>>that a more general and complex interface above will be rejected.
> 
> 
> good call...

:-)

Although I like Alex' suggestions, my original proposal was IMHO a bit 
more focused on just the publication workflow step -- so maybe it makes 
sense to concentrate on that.

Re: issue tracking. I think this is useful as well, and my rfc2629.xslt 
already supports some kind of "poor man's change and issue" tracking. 
Those who haven't seen that yet may want to check out the XML and HTML 
examples on <http://greenbytes.de/tech/webdav/>.

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Marshall Rose)
Date: Wed, 12 Nov 2003 17:10:06 -0600
Subject: [xml2rfc] feature request for tagging publication related information
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <20031112215912.GH2596@sbrim-w2k01> <[email-masked]>
Message-ID: <[email-masked]>

> Given the objections to a simpler onPublication interface, I suspect
> that a more general and complex interface above will be rejected.

good call...

/mtr

From: Spencer Dawkins" <[email-masked] (Spencer Dawkins)
Date: Wed, 12 Nov 2003 16:42:26 -0600
Subject: [xml2rfc] How to review xml2rfc drafts
Message-ID: <009201c3a96e$42546630$1d848182@DFNJGL21>

Dear all,

I'm a very happy xml2rfc author, and a very confused reviewer.

I just confused Bob Braden by sending a review for an .xml file that I
had just typed text into - people can see diffs in the text, but it's
not pretty, and it would be nice to have a <review reviewer=spencer>
brilliant observation </review> tag to use in this situation. How do
other people do this, with non-XML-literate participants?

Thanks for any clues you may have,

Spencer

From: [email-masked] (Alex Rousskov)
Date: Wed, 12 Nov 2003 15:20:20 -0700 (MST)
Subject: [xml2rfc] feature request for tagging publication related information
In-Reply-To: <20031112215912.GH2596@sbrim-w2k01>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <20031112215912.GH2596@sbrim-w2k01>
Message-ID: <[email-masked]>

On Wed, 12 Nov 2003, Scott W Brim wrote:

> On Tue, Nov 11, 2003 03:44:46PM -0700, Alex Rousskov allegedly wrote:
> >     A new optional attribute called "onPublication" is added to
> >     <section> and <appendix> elements. Possible values are "include"
> >     (default) and "exclude". onPublication name is not ideal because
> >     drafts are published as well. onApproval, forRFC, or whileDraft
> >     are possible alternatives.
>
> Why not have conditional sections.  <conditional "tag">
> </conditional>, where you can turn "tag" on and off at the top of
> the file, or if you're rfc-editor, in an include (or even on a
> command line).  This generalizes the above.

... but once the interface is generalized, it becomes impossible to
generate a "This section is to be deleted upon final publication"
warning statement because such statements are not general but specific
to onPublication. Thus, we would be loosing 50% of the benefit. We
could define a few well-known tag/attribute values that will cause
statement generation. Is that something you are after?

Also, while a <conditional> element is probably to heavy of a
solution, we could have a general "ignore_class" attribute, controlled
from a "ignore" PI or from a command line:

	<?rfc ignore="todo" ?>
	<?rfc ignore="log" ?>
	...
	<section ignore_class="todo">...
	<t ignore_class="issue">...

or something like that. This allows the user to selectively ignore
arbitrary specification pieces when generating text or HTML. The above
caveat about generating warning statements still applies, of course.

Given the objections to a simpler onPublication interface, I suspect
that a more general and complex interface above will be rejected.

Alex.

From: [email-masked] (Scott W Brim)
Date: Wed, 12 Nov 2003 15:59:12 -0600
Subject: [xml2rfc] feature request for tagging publication related information
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <20031112215912.GH2596@sbrim-w2k01>

On Tue, Nov 11, 2003 03:44:46PM -0700, Alex Rousskov allegedly wrote:
>     A new optional attribute called "onPublication" is added to
>     <section> and <appendix> elements. Possible values are "include"
>     (default) and "exclude". onPublication name is not ideal because
>     drafts are published as well. onApproval, forRFC, or whileDraft
>     are possible alternatives.

Why not have conditional sections.  <conditional "tag"> </conditional>,
where you can turn "tag" on and off at the top of the file, or if you're
rfc-editor, in an include (or even on a command line).  This generalizes
the above.

From: [email-masked] (Alex Rousskov)
Date: Wed, 12 Nov 2003 06:50:29 -0700 (MST)
Subject: [xml2rfc] feature request for tagging publication related information
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 12 Nov 2003, Clive D.W. Feather wrote:

> I would like to support this as well. I use a preprocessor before
> xml2rfc, and one thing I quickly found essential was a
> <issue>...</issue> element. I expand it to:
>
>   <t>
>   <list style="none">
>   <t>OPEN ISSUE</t>
>   contents go here
>   </list>
>   </t>

I prefer an inlined (spanx-like) behavior because some issues comment
on specific phrase inside a paragraph or a table cell. I can manually
make it a separate paragraph if I need to (the reverse would not be
possible)  thought that would make automatic stripping for publication
impossible (an empty <t></t> would be left behind).

Alex.

From: [email-masked] (Clive D.W. Feather)
Date: Wed, 12 Nov 2003 08:17:57 +0000
Subject: [xml2rfc] feature request for tagging publication related information
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke said:
>> Julian proposed two changes. I attached his original e-mail at the
>> end. I can summarize with the edits based on my interpretation of the
>> discussion that followed. Julian please correct me if needed.

> I support Alex' extended version of my original proposal.

I would like to support this as well. I use a preprocessor before xml2rfc,
and one thing I quickly found essential was a <issue>...</issue> element.
I expand it to:

  <t>
  <list style="none">
  <t>OPEN ISSUE</t>
  contents go here
  </list>
  </t>

(Do I mean "none"? I don't recall. Anyway, the style that just indents the
enclosed text.)

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646

From: [email-masked] (Julian Reschke)
Date: Wed, 12 Nov 2003 02:10:30 +0100
Subject: [xml2rfc] feature request for tagging publication related information
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Alex Rousskov wrote:

> On Tue, 11 Nov 2003, Marshall Rose wrote:
> 
> 
>>would someone be so kind as to reply with a concise email explaining
>>the syntax of the proposed change?
> 
> 
> Julian proposed two changes. I attached his original e-mail at the
> end. I can summarize with the edits based on my interpretation of the
> discussion that followed. Julian please correct me if needed.
> 
> ...

I support Alex' extended version of my original proposal.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Julian Reschke)
Date: Wed, 12 Nov 2003 02:06:09 +0100
Subject: [xml2rfc] checking RFC references
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:

>>attached is a simple XSLT script that will check all RFC-series 
>>references using the rfc-index.xml file published by the RFC Editor 
>>(file is huge and must be in the same directory). For instance:
>>
>>saxon rfc2774.xml check-ietf-references.xslt
>>
>>yields:
>>...
> 
>     
> cool. why not email the rfc editor and ask whether they want a copy. i
> can put a copy on xml.resource.org if they don't want to make a copy
> available... 

In a perfect world, the RFC Editor would be subscribing to this mailing 
list :-)

Yes, I'll forward a copy.

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Julian Reschke)
Date: Wed, 12 Nov 2003 02:01:13 +0100
Subject: [xml2rfc] feature request for tagging publication related information
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Pekka Savola wrote:

> I maintain just one version, naturally.
> 
> When a document is submitted to the IESG, it certainly should no longer 
> have open issues to be mentioned.

But if - for instance - you maintain change log information (like 
changes from the previous I-D), they will still be in, and *somebody* 
needs to be aware of the fact that they need to be removed prior to 
publication.

> [...]
> 
> My point was that this mechanism seems like an awfully complex way to 
> write one or a couple of times in the draft, manually:
> 
> [ NOTE: RFC-editor, please remove from final publication! ]

I don't see why it's complex. Actually, it's simpler because the rfc2629 
processor will do that writing for you.

> .. is this really, really needed?  Much easier to write it yourself..
> 
> (I'm not against the idea, but somehow this just seems like overloading 
> xml2rfc with a lot of cruft that is just something reasonable document 
> editing / submission guidelines aren't tackling..)

If something can *easily* be automated that otherwise needs manual 
intervention (that can go wrong), why not do that?

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Alex Rousskov)
Date: Tue, 11 Nov 2003 15:44:46 -0700 (MST)
Subject: [xml2rfc] feature request for tagging publication related information
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Tue, 11 Nov 2003, Marshall Rose wrote:

> would someone be so kind as to reply with a concise email explaining
> the syntax of the proposed change?

Julian proposed two changes. I attached his original e-mail at the
end. I can summarize with the edits based on my interpretation of the
discussion that followed. Julian please correct me if needed.

Feature 1: a "to be removed by RFC Editor before publication" mark
---------

    A new optional attribute called "onPublication" is added to
    <section> and <appendix> elements. Possible values are "include"
    (default) and "exclude". onPublication name is not ideal because
    drafts are published as well. onApproval, forRFC, or whileDraft
    are possible alternatives.

    A <section> or <appendix> element with the above attribute set to
    "exclude" are rendered by prepending their "normal" body with the
    following paragraph.

        <t>This ... is to be removed from the final
        publication.</t>

    or whatever seems appropriate to Marshall.

    xml2rfc is to have a PI or command line option to filter all
    excluded elements out.

    Ideally, xml2rfc would warn if a reference is made from included
    text to excluded text.

    In the future, onPublication scope may be extended to <t> or other
    elements, but there are visual scope problems with <t>. Where does
    it end in a rendered draft? Parens or other explicit marks may be
    required to mark onPublication scope end when it is used with <t>.

Feature 2: an "open issue" mark
---------

    A new element <ed> or <issue> is added that can appear in any
    context where spanx can.

        <issue>Houston, we have a problem</issue>

    is replaced with

        (XXX: Houston, we have a problem)

    possibly with background color changes in HTML versions, or
    whatever seems appropriate to Marshall.

    Ideally, the <ed> or <issue> tag will accept the above mentioned
    onPublication attribute with "exclude" meaning as the default.

HTH,

Alex.

----------- Julian's original proposal -----------------

1) Mark a section/paragraph as "to be removed by RFC Editor before
publication" (such as change logs). Having an explicit way to express
this would help to ensure that this information is indeed removed. For
instance, when /rfc/@number gets set, an RFC2629 processor could
automatically exclude these sections from rendering.

2) Similarily: mark a section/paragraph as "to be resolved before
publication". The RFC2629 could signal an error when an attempt is
made to process a document as RFC that still has these kinds of
sections.

Syntax: possibly a new attribute on sections and paragraphs (<t>),
called "onPublication", possible values "none" (default), "exclude"
and "error".

From: [email-masked] (Marshall Rose)
Date: Tue, 11 Nov 2003 16:17:50 -0600
Subject: [xml2rfc] feature request for tagging publication related information
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> ...    
> I am against feature creap, and I consider this feature worth
> supporting. It is impossible to draw a formal line to identify
> essential features from needless cruft, of course. Individual author
> and editor needs vary. I hope this thread has enough pro- and cons-
> arguments from xml2rfc users for Marshall to decide.

thanks.
    
would someone be so kind as to reply with a concise email explaining
the syntax of the proposed change?
    
/mtr

From: [email-masked] (Alex Rousskov)
Date: Tue, 11 Nov 2003 15:02:36 -0700 (MST)
Subject: [xml2rfc] feature request for tagging publication related information
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Tue, 11 Nov 2003, Pekka Savola wrote:

> When a document is submitted to the IESG, it certainly should no
> longer have open issues to be mentioned.

Why not? If those open issues are not for the public to see, I do not
see any harm and can think of a few useful cases. For example, (XXX:
if IESG finds FOO wrong, we will do BAR instead) or (XXX: Make sure WG
XYZ knows about this requirement once this document is published!).

Not to mention preserving change log in case the document is returned
for more edits... Do you delete the change log and then put it back if
your document is returned for a revision? Or do you never have
documents rejected by IESG? :-)

> My point was that this mechanism seems like an awfully complex way to
> write one or a couple of times in the draft, manually:
>
> [ NOTE: RFC-editor, please remove from final publication! ]

I look at it differently. The proposed mechanism is a simple and
reliable way for RFC-editor to filter the above text from the final
publication.

> .. is this really, really needed?  Much easier to write it yourself..

Well, it is not "really, really needed". Xml2rfc itself is not
"really, really needed"! And no, it is not much easier for me to write
the above sentence than use an XML tag.

I am against feature creap, and I consider this feature worth
supporting. It is impossible to draw a formal line to identify
essential features from needless cruft, of course. Individual author
and editor needs vary. I hope this thread has enough pro- and cons-
arguments from xml2rfc users for Marshall to decide.

Thank you,

Alex.

From: [email-masked] (Pekka Savola)
Date: Tue, 11 Nov 2003 23:39:10 +0200 (EET)
Subject: [xml2rfc] feature request for tagging publication related information
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

On Tue, 11 Nov 2003, Alex Rousskov wrote:
> You seem to either assume that an author is maintaining two versions
> of the draft (one for the WG/self and one for IESG) or that the
> submitted version is the final one in document life. Both assumptions
> may be wrong, in my experience.

I maintain just one version, naturally.

When a document is submitted to the IESG, it certainly should no longer 
have open issues to be mentioned.
 
> When I submit a draft to IESG, I do not want to delete the change log,
> the to-do list, or the issues list. While I am optimistic about the
> draft eventual approval, I am both (a) not certain it will be approved
> in its current form and (b) may need to maintain the document after it
> is approved. Thus, I cannot assume the draft reaches the final state
> upon submission. And it is an extra pain to manually maintain two
> versions of the same draft, of course.
[...]

My point was that this mechanism seems like an awfully complex way to 
write one or a couple of times in the draft, manually:

[ NOTE: RFC-editor, please remove from final publication! ]

.. is this really, really needed?  Much easier to write it yourself..

(I'm not against the idea, but somehow this just seems like overloading 
xml2rfc with a lot of cruft that is just something reasonable document 
editing / submission guidelines aren't tackling..)
 
-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From: [email-masked] (Marshall Rose)
Date: Tue, 11 Nov 2003 14:11:30 -0600
Subject: [xml2rfc] checking RFC references
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> attached is a simple XSLT script that will check all RFC-series 
> references using the rfc-index.xml file published by the RFC Editor 
> (file is huge and must be in the same directory). For instance:
> 
> saxon rfc2774.xml check-ietf-references.xslt
> 
> yields:
> ...
    
cool. why not email the rfc editor and ask whether they want a copy. i
can put a copy on xml.resource.org if they don't want to make a copy
available... 
    
/mtr

From: [email-masked] (Alex Rousskov)
Date: Tue, 11 Nov 2003 13:11:23 -0700 (MST)
Subject: [xml2rfc] feature request for tagging publication related information
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Tue, 11 Nov 2003, Pekka Savola wrote:

> On Tue, 11 Nov 2003 [email-masked] wrote:
>
> > I have to agree. Text that isn't supposed to appear in the final
> > version of the specification is quite common, and as an area
> > director I often see cases where it isn't clearly marked as such
> > and where documents are submitted for approval with open issues
> > still listed in the text.
>
> Isn't that a problem of the document improvement process?  Seems
> like someone didn't read the document before submitting it to the
> IESG..

You seem to either assume that an author is maintaining two versions
of the draft (one for the WG/self and one for IESG) or that the
submitted version is the final one in document life. Both assumptions
may be wrong, in my experience.

When I submit a draft to IESG, I do not want to delete the change log,
the to-do list, or the issues list. While I am optimistic about the
draft eventual approval, I am both (a) not certain it will be approved
in its current form and (b) may need to maintain the document after it
is approved. Thus, I cannot assume the draft reaches the final state
upon submission. And it is an extra pain to manually maintain two
versions of the same draft, of course.

The proposed feature would make two-version maintenance overhead
optional for those who prefer automated means.

Finally, what may be a clearly marked not-for-publication text to one
author may be normative text for a reviewer or specification user.
Standardization and automation reduces such ambiguities.

IMHO, the xml2rfc tool should facilitate "document improvement
process".

Alex.

From: [email-masked] (Pekka Savola)
Date: Tue, 11 Nov 2003 21:04:04 +0200 (EET)
Subject: [xml2rfc] feature request for tagging publication related information
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

On Tue, 11 Nov 2003 [email-masked] wrote:
> I have to agree. Text that isn't supposed to appear in the final version of the
> specification is quite common, and as an area director I often see cases where
> it isn't clearly marked as such and where documents are submitted for approval
> with open issues still listed in the text.

Isn't that a problem of the document improvement process?  Seems like 
someone didn't read the document before submitting it to the IESG..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From: [email-masked] ([email-masked])
Date: Tue, 11 Nov 2003 09:07:28 -0800 (PST)
Subject: [xml2rfc] feature request for tagging publication related information
In-Reply-To: "Your message dated Mon, 10 Nov 2003 12:00:19 -0700 (MST)" <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On Mon, 10 Nov 2003, Pekka Savola wrote:

> > On Mon, 10 Nov 2003, Julian Reschke wrote:
> >
> > > Here's something that could be useful when an I-D get's published
> > > as RFC: [...]
> >
> > Is xml2rfc _really_ so bug-free etc. already that we have to start
> > overengineering it because we have nothing else to do? :-)

> Overengineering? That's debatable. All drafts I work with have text
> that is not supposed to be published and text that reflects open
> issues.

I have to agree. Text that isn't supposed to appear in the final version of the
specification is quite common, and as an area director I often see cases where
it isn't clearly marked as such and where documents are submitted for approval
with open issues still listed in the text.

> I spend considerable time tracking issues and often do not
> have enough time to document unpublishable text. For me, Julian
> proposal is actually "underengineered".

Well, I wouldn't go that far. I think what was proposed is about right.

				Ned

From: [email-masked] (Julian Reschke)
Date: Tue, 11 Nov 2003 14:27:47 +0100
Subject: [xml2rfc] checking RFC references
Message-ID: <[email-masked]>

Hi,

attached is a simple XSLT script that will check all RFC-series 
references using the rfc-index.xml file published by the RFC Editor 
(file is huge and must be in the same directory). For instance:

saxon rfc2774.xml check-ietf-references.xslt

yields:

RFC0822: obsoleted by RFC2822
RFC1945: ok
RFC2026: ok
RFC2046: ok
RFC2068: obsoleted by RFC2616
RFC2119: ok
RFC2324: ok
RFC2396: ok

Regards, Julian

--

<xsl:transform xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                 version="1.0"
                 xmlns:rfced="http://www.rfc-editor.org/rfc-index"
 >

<xsl:output method="text" encoding="UTF-8"/>

<xsl:template match="/">
   <xsl:for-each select="//reference[seriesInfo/@name='RFC']">
     <xsl:variable name="no" select="seriesInfo[@name='RFC']/@value" />
     <xsl:variable name="id" 
select="concat('RFC',substring('000',string-length($no)),$no)" />
     <xsl:value-of select="$id" />
     <xsl:text>: </xsl:text>
     <xsl:variable name="stat" 
select="document('rfc-index.xml')/*/rfced:rfc-entry[rfced:doc-id=$id]" 
/>
     <xsl:choose>
       <xsl:when test="$stat/rfced:obsoleted-by">
         <xsl:text>obsoleted by </xsl:text>
         <xsl:for-each select="$stat/rfced:obsoleted-by/rfced:doc-id">
           <xsl:value-of select="."/>
           <xsl:text> </xsl:text>
         </xsl:for-each>
       </xsl:when>
       <xsl:otherwise>ok</xsl:otherwise>
     </xsl:choose>
     <xsl:text>&#10;</xsl:text>
   </xsl:for-each>
</xsl:template>

</xsl:transform>

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Julian Reschke)
Date: Tue, 11 Nov 2003 10:15:08 +0100
Subject: [xml2rfc] xref formatting
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:
>>>    <xref format='none' target='RFC2629'>original specification</xef
>>
>>TXT: .... original specification ...
>>HTML: .... <a href="#RFC2629">original specification</a> ....
> 
>     
> ok.
> 
>     
> 
>>>    <xref format='none' target='RFC2629' />
>>
>>This would be an error, or alternatively an empty replacement.
> 
> 
> how about the latter?

That would be consistent. In rfc2629.xslt, I'd probably emit a warning.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Marshall Rose)
Date: Mon, 10 Nov 2003 21:33:30 -0600
Subject: [xml2rfc] xref formatting
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> >     <xref format='none' target='RFC2629'>original specification</xef
> TXT: .... original specification ...
> HTML: .... <a href="#RFC2629">original specification</a> ....
    
ok.

> >     <xref format='none' target='RFC2629' />
> 
> This would be an error, or alternatively an empty replacement.

how about the latter?
    
/mtr

From: [email-masked] (Julian Reschke)
Date: Mon, 10 Nov 2003 21:39:16 +0100
Subject: [xml2rfc] xref formatting
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:

>>Wouldn't it make sense to introduce a new value for the xref format 
>>attribute, called "none", that explicitly instructs the application 
>>*not* to add any additional text. For TXT output this would turn the 
>>xref into a no-op, while when producing HTML/PDF..., it could be 
>>rendered as link.
> 
> 
> give me an example as to how these two exmples would be rendered for
> both txt and html:
>     
>     <xref format='none' target='RFC2629'>original specification</xef
>     
>     <xref format='none' target='RFC2629' />
>     
> thanks!

1)

TXT: .... original specification ...
HTML: .... <a href="#RFC2629">original specification</a> ....

2)

This would be an error, or alternatively an empty replacement.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Marshall Rose)
Date: Mon, 10 Nov 2003 14:31:03 -0600
Subject: [xml2rfc] xref formatting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> Wouldn't it make sense to introduce a new value for the xref format 
> attribute, called "none", that explicitly instructs the application 
> *not* to add any additional text. For TXT output this would turn the 
> xref into a no-op, while when producing HTML/PDF..., it could be 
> rendered as link.

give me an example as to how these two exmples would be rendered for
both txt and html:
    
    <xref format='none' target='RFC2629'>original specification</xef
    
    <xref format='none' target='RFC2629' />
    
thanks!
    
/mtr

From: [email-masked] (John C Klensin)
Date: Mon, 10 Nov 2003 15:26:23 -0500
Subject: [xml2rfc] Re: feature request for tagging publication related information
In-Reply-To: <[email-masked]>
References: <[email-masked] .ca.us>
Message-ID: <[email-masked]>

Julian wrote:

> Here's something that could be useful when an I-D get's
> published as RFC:
> 
> 1) Mark a section/paragraph as "to be removed by RFC Editor
> before  publication" (such as change logs). Having an explicit
> way to express  this would help to ensure that this
> information is indeed removed. For  instance, when
> /rfc/@number gets set, an RFC2629 processor could 
> automatically exclude these sections from rendering.
> 
> 2) Similarily: mark a section/paragraph as "to be resolved
> before  publication". The RFC2629 could signal an error when
> an attempt is made  to process a document as RFC that still
> has these kinds of sections.
> 
> Syntax: possibly a new attribute on sections and paragraphs
> (<t>),  called "onPublication", possible values "none"
> (default), "exclude" and  "error".

Julian, Alex,

Let me add one two more things to the class of items in this
"I-Ds only; bad if still there when something goes to RFC":

(1) A "note in draft" that explicitly flags a discussion note by
an editor that is to be removed.   This case is similar to (2),
but, IMO, a little different.

(2) A deliberately incomplete reference.  It is often useful to
write a document and circulate it as an early draft without
filling in all of the references.  These should take anchors, so
it is possible to use an xref from the text to point to them,
etc.   I would imagine either an alternate syntax for
<reference>, e.g.,
    <reference onPublication="error">
      <t> Author-supplied free text as placeholder </t>
    </reference>
or equivalent (such as a different/alternate element subsidiary
to <references>).

It would also be really handy to have a directive or equivalent
that would build a list and index to these things as, e.g., a
temporary "Loose Ends" section.

      john

From: [email-masked] (Alex Rousskov)
Date: Mon, 10 Nov 2003 12:00:19 -0700 (MST)
Subject: [xml2rfc] feature request for tagging publication related information
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 10 Nov 2003, Pekka Savola wrote:

> On Mon, 10 Nov 2003, Julian Reschke wrote:
>
> > Here's something that could be useful when an I-D get's published
> > as RFC: [...]
>
> Is xml2rfc _really_ so bug-free etc. already that we have to start
> overengineering it because we have nothing else to do? :-)

Overengineering? That's debatable. All drafts I work with have text
that is not supposed to be published and text that reflects open
issues. I spend considerable time tracking issues and often do not
have enough time to document unpublishable text. For me, Julian
proposal is actually "underengineered".

For me, issue management should be a standard feature of a mature
document management tool. I believe xml2rfc is mature enough. The
sheer number of non-for-publication text in IDs make the first feature
Julian asked for worth adding as well. YMMV.

Alex.

From: [email-masked] (Julian Reschke)
Date: Mon, 10 Nov 2003 19:36:56 +0100
Subject: [xml2rfc] feature request for tagging publication related information
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Pekka Savola wrote:

> On Mon, 10 Nov 2003, Julian Reschke wrote:
> 
>>Here's something that could be useful when an I-D get's published as RFC:
> 
> [...]
> 
> Is xml2rfc _really_ so bug-free etc. already that we have to start
> overengineering it because we have nothing else to do? :-)

Bug-free? No. Robust? Yes.

The thing I proposed seemed to be useful bit of metadata that can be 
used to avoid that temporary sections (like change logs) end up in a 
published RFC. I'm not sure whether this happened yet, but it seems to 
make sense to have a machine-readable way to specify this, so it *can't* 
happen.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Pekka Savola)
Date: Mon, 10 Nov 2003 20:32:49 +0200 (EET)
Subject: [xml2rfc] feature request for tagging publication related information
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 10 Nov 2003, Julian Reschke wrote:
> Here's something that could be useful when an I-D get's published as RFC:
[...]

Is xml2rfc _really_ so bug-free etc. already that we have to start
overengineering it because we have nothing else to do? :-)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From: [email-masked] (Alex Rousskov)
Date: Mon, 10 Nov 2003 11:29:19 -0700 (MST)
Subject: [xml2rfc] feature request for tagging publication related information
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 10 Nov 2003, Julian Reschke wrote:

> > It may be tricky to render (1) though. Temporary <section> and
> > <appendix> can be rendered by starting them with
> >
> > 	<t>This ... is to be removed when publishing as an RFC.</t>
>
> or by adding "(to be removed...)" to the section title.

A more-detailed and explicit text may be less confusing to readers
than a necessarily-brief tag in the title.

A useful related feature would be to issue warnings when a permanent
text is referencing a temporary text. This is not strictly necessary
since I assume xml2rfc would have a flag/instruction to strip all
temporary text; that mode can be used to check references (though
nobody would use it until it is too late, of course).

> > but <t> boundaries are often unclear.
>
> Correct. So maybe we should first focus on the simple case
> (sections), maybe that's enough.

Indeed. Sections and appendices should be sufficient for most needs.

Thanks,

Alex.

From: [email-masked] (Julian Reschke)
Date: Mon, 10 Nov 2003 19:13:15 +0100
Subject: [xml2rfc] feature request for tagging publication related information
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Alex Rousskov wrote:

> Julian,
> 
> 	I find both features useful, but have some
> additional/different requirements.
> 
> First of all, both features must be visible (rather than being used
> exclusively by XML processors to strip or detect text).

Yes.

> It may be tricky to render (1) though. Temporary <section> and
> <appendix> can be rendered by starting them with
> 
> 	<t>This ... is to be removed when publishing as an RFC.</t>

or by adding "(to be removed...)" to the section title.

> generated paragraph. The <t> can be rendered by starting it with
> 
> 	This paragraph is to be removed when publishing as an RFC.
> 
> generated text, but <t> boundaries are often unclear.

Correct. So maybe we should first focus on the simple case (sections), 
maybe that's enough.

> ...

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Alex Rousskov)
Date: Mon, 10 Nov 2003 10:58:54 -0700 (MST)
Subject: [xml2rfc] feature request for tagging publication related information
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Julian,

	I find both features useful, but have some
additional/different requirements.

First of all, both features must be visible (rather than being used
exclusively by XML processors to strip or detect text).

It may be tricky to render (1) though. Temporary <section> and
<appendix> can be rendered by starting them with

	<t>This ... is to be removed when publishing as an RFC.</t>

generated paragraph. The <t> can be rendered by starting it with

	This paragraph is to be removed when publishing as an RFC.

generated text, but <t> boundaries are often unclear.

For (2), it would be nice if the "to be resolved" feature is _not_
called "error" but rather something more neutral like "XXX", "issue",
or "TBD" since many of those things are not errors but rather
questions or to-do items. Currently, I render (2) as

	(XXX: issue text goes here)

Note that (2) should be available as a part of any text, not just <t>
or <section>! Thus, it probably can be tagged as

	<spanx class="issue">issue text goes here</spanx>

unless a dedicated <issue> element is more appropriate. The two
features have different enough semantics to deserve different
element/attribute names, IMO. For example, there are RFCs published
with open issues.

$0.02,

Alex.

On Mon, 10 Nov 2003, Julian Reschke wrote:

> Hi.
>
> Here's something that could be useful when an I-D get's published as
> RFC:
>
> 1) Mark a section/paragraph as "to be removed by RFC Editor before
> publication" (such as change logs). Having an explicit way to
> express this would help to ensure that this information is indeed
> removed. For instance, when /rfc/@number gets set, an RFC2629
> processor could automatically exclude these sections from rendering.
>
> 2) Similarily: mark a section/paragraph as "to be resolved before
> publication". The RFC2629 could signal an error when an attempt is
> made to process a document as RFC that still has these kinds of
> sections.
>
> Syntax: possibly a new attribute on sections and paragraphs (<t>),
> called "onPublication", possible values "none" (default), "exclude"
> and "error".
>
>
> Regards, Julian
>
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
>
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>

From: [email-masked] (Julian Reschke)
Date: Mon, 10 Nov 2003 18:07:50 +0100
Subject: [xml2rfc] feature request for tagging publication related information
Message-ID: <[email-masked]>

Hi.

Here's something that could be useful when an I-D get's published as RFC:

1) Mark a section/paragraph as "to be removed by RFC Editor before 
publication" (such as change logs). Having an explicit way to express 
this would help to ensure that this information is indeed removed. For 
instance, when /rfc/@number gets set, an RFC2629 processor could 
automatically exclude these sections from rendering.

2) Similarily: mark a section/paragraph as "to be resolved before 
publication". The RFC2629 could signal an error when an attempt is made 
to process a document as RFC that still has these kinds of sections.

Syntax: possibly a new attribute on sections and paragraphs (<t>), 
called "onPublication", possible values "none" (default), "exclude" and 
"error".

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Marshall Rose)
Date: Fri, 7 Nov 2003 11:48:58 -0800
Subject: [xml2rfc] tables spanning pages in TXT output mode
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> I've got a texttable that spans multiple pages. Right now, xml2rfc 
> doesn't seem to repeat table headers on subsequent pages. Any chance 
> this get's changed/fixed?

in brief: no. this would require a major rewrite of the internal architecture.

/mtr

From: [email-masked] (Marshall Rose)
Date: Fri, 7 Nov 2003 11:48:11 -0800
Subject: [xml2rfc] eref rendering
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> At least in those cases where <eref> is empty (that is no replacement 
> text is given), I'd prefer it just to generate an in-line URI (in angle 
> brackets), and *not* to add anything to the end of the document.
> 
> Is this possible right now using a PI I'm not aware of?

no. but it sounds like that would be better behavior. so, i'll put that
in the next release.
    
/mtr

From: [email-masked] (Marshall Rose)
Date: Fri, 7 Nov 2003 10:06:15 -0800
Subject: [xml2rfc] upper/lower case for "section"
In-Reply-To: <20031107125626.GD2680@sbrim-w2k01>
References: <[email-masked]> <20031107125626.GD2680@sbrim-w2k01>
Message-ID: <[email-masked]>

> That's what I was taught.  In references use Section, Figure, Table.

What i was taught is this:

    Use capitalization when referring to an actual section, such as
    Section 1. The same goes for tables, figures, diagrams, and so on.

/mtr

From: [email-masked] (Alex Rousskov)
Date: Fri, 7 Nov 2003 08:29:00 -0700 (MST)
Subject: [xml2rfc] xref formatting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

        I was going to ask for exactly the same xref feature!

        My use case is linking from protocol message names to message
definitions. Since message names are used a lot in the spec, having
"Section X.Y" after each message name is quickly getting annoying for
the reader of the text version. On the other hand, having textless
links in HTML version is very convenient and not intrusive at all.

        Another use case is tables where explicit "Section X.Y" links
just do not fit.

        Since there is no textual difference, I think it is acceptable
to have a link in HTML and nothing in plain text versions. We already
have such links for table of contents, for example.

        I hope a better attribute name than "none" can be found :-).
Perhaps something like "textless" or "implicit" would work better?

Thank you,

Alex.

On Fri, 7 Nov 2003, Julian Reschke wrote:

> Hi,
>
> another question/suggestion regarding xref formatting.
>
> Sometimes a text fragment lends itself to be marked up as
> intra-document link, however I *don't* want xml2rfc to add any
> additional text. For instance because
>
> - the RFC that I'm marking up already has been published and I want
> to avoid differences in the TXT version or
>
> - the text appears in a place where additional text is disturbing
> (such as in a tight table column)
>
> Wouldn't it make sense to introduce a new value for the xref format
> attribute, called "none", that explicitly instructs the application
> *not* to add any additional text. For TXT output this would turn the
> xref into a no-op, while when producing HTML/PDF..., it could be
> rendered as link.
>
> Julian

From: [email-masked] (Julian Reschke)
Date: Fri, 07 Nov 2003 14:57:22 +0100
Subject: [xml2rfc] xref formatting
Message-ID: <[email-masked]>

Hi,

another question/suggestion regarding xref formatting.

Sometimes a text fragment lends itself to be marked up as intra-document 
link, however I *don't* want xml2rfc to add any additional text. For 
instance because

- the RFC that I'm marking up already has been published and I want to 
avoid differences in the TXT version or

- the text appears in a place where additional text is disturbing (such 
as in a tight table column)

Wouldn't it make sense to introduce a new value for the xref format 
attribute, called "none", that explicitly instructs the application 
*not* to add any additional text. For TXT output this would turn the 
xref into a no-op, while when producing HTML/PDF..., it could be 
rendered as link.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Scott W Brim)
Date: Fri, 7 Nov 2003 07:56:26 -0500
Subject: [xml2rfc] upper/lower case for "section"
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <20031107125626.GD2680@sbrim-w2k01>

On Fri, Nov 07, 2003 01:35:59PM +0100, Julian Reschke allegedly wrote:
> Hi,
> 
> I notice that xml2rfc (when resolving xref's to section anchors) always 
> produce an uppercase "Section". RFC2629.xslt however makes an attempt to 
> only upper-case the word if it's the start of a sentence.
> 
> What's the right behavior (as I am not a native speaker of English, I 
> just don't know). If for some reason it's actually expected that 
> "Section" stays uppercase inside sentences, I'd gladly remove all the 
> special case code from rfc2629.xslt....

That's what I was taught.  In references use Section, Figure, Table.

From: [email-masked] (Julian Reschke)
Date: Fri, 07 Nov 2003 13:49:34 +0100
Subject: [xml2rfc] tables spanning pages in TXT output mode
Message-ID: <[email-masked]>

Hi,

I've got a texttable that spans multiple pages. Right now, xml2rfc 
doesn't seem to repeat table headers on subsequent pages. Any chance 
this get's changed/fixed?

(rfc2629.xslt btw *does* produce the necessary CSS2 code so that if the 
HTML gets printed from a browser, table headers *will* appear on 
subsequent pages).

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Julian Reschke)
Date: Fri, 07 Nov 2003 13:35:59 +0100
Subject: [xml2rfc] upper/lower case for "section"
Message-ID: <[email-masked]>

Hi,

I notice that xml2rfc (when resolving xref's to section anchors) always 
produce an uppercase "Section". RFC2629.xslt however makes an attempt to 
only upper-case the word if it's the start of a sentence.

What's the right behavior (as I am not a native speaker of English, I 
just don't know). If for some reason it's actually expected that 
"Section" stays uppercase inside sentences, I'd gladly remove all the 
special case code from rfc2629.xslt....

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Julian Reschke)
Date: Fri, 07 Nov 2003 13:31:56 +0100
Subject: [xml2rfc] eref rendering
Message-ID: <[email-masked]>

Hi,

when rendering things like

	Other related documents can be found at
         <eref target="http://www.example.com/acl/"/>

xml2rfc behaves differently depending on the output mode:

- when producing HTML, it just generates an HTML anchor (rfc2629.xslt 
does the same)
- when producing TXT, it generates a numbered reference to a URI at the 
end of the document

At least in those cases where <eref> is empty (that is no replacement 
text is given), I'd prefer it just to generate an in-line URI (in angle 
brackets), and *not* to add anything to the end of the document.

Is this possible right now using a PI I'm not aware of?

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Alex Rousskov)
Date: Thu, 6 Nov 2003 12:00:20 -0700 (MST)
Subject: [xml2rfc] <?rfc ideal='yes' ?>
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thu, 6 Nov 2003, Marshall Rose wrote:

> > I am probably missing something here, but isn't the _default_
> > combination supposed to be the "ideal"? That would be my
> > expectation/preference anyway.
>
> some people do not prefer the default values that i prefer. if
> enough of them can reach a consensus, i will add an option to make
> it easier for them.

And I was under impression you are against featurism in xml2rfc! :-)

Alex.

From: [email-masked] (Marshall Rose)
Date: Thu, 6 Nov 2003 10:46:18 -0800
Subject: [xml2rfc] <?rfc ideal='yes' ?>
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> I am probably missing something here, but isn't the _default_
> combination supposed to be the "ideal"? That would be my
> expectation/preference anyway.

some people do not prefer the default values that i prefer. if enough of them
can reach a consensus, i will add an option to make it easier for them.

/mtr

From: [email-masked] (Alex Rousskov)
Date: Thu, 6 Nov 2003 11:28:36 -0700 (MST)
Subject: [xml2rfc] <?rfc ideal='yes' ?>
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Thu, 6 Nov 2003, Marshall Rose wrote:

> some time ago, i suggested that someone come up with a consensus
> position on what is the "ideal" combination of xml2rfc PIs, so i
> could implement a single PI that would set everything accordingly.

I am probably missing something here, but isn't the _default_
combination supposed to be the "ideal"? That would be my
expectation/preference anyway.

If one starts fiddling with defaults, it is their responsibility to
get all of them in sync, of course.

Is there some backward compatibility issue here that prevents you from
doing "ideal" be default?

Thanks,

Alex.

From: [email-masked] (Marshall Rose)
Date: Thu, 6 Nov 2003 10:04:23 -0800
Subject: [xml2rfc] <?rfc ideal='yes' ?>
Message-ID: <[email-masked]>

some time ago, i suggested that someone come up with a consensus position on
what is the "ideal" combination of xml2rfc PIs, so i could implement a single PI
that would set everything accordingly.

has anyone given any thought to this?

thanks,

/mtr

From: [email-masked] (Marshall Rose)
Date: Tue, 4 Nov 2003 11:18:44 -0800
Subject: [xml2rfc] Small problem with texttables
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> (This isn't a big deal... I ended up using <figure>.  But as a matter of 
> general principle, I think it was Tufte in one of his books on graphical 
> presentation who makes the point that less ink is generally better, if the 
> required information is conveyed.)

agreed. knuth says the same thing.

/mtr

From: [email-masked] (Graham Klyne)
Date: Tue, 04 Nov 2003 12:11:57 +0000
Subject: [xml2rfc] Another item for the wish-list
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Thanks, I tried that.  (I get unknown PI: rfc-ext 
parse-xml-in-artwork="yes", but it seems to work OK.)

On my system, the spanx 'verb' looks just the same as the spanx 
'emph'.  I'll check the generated source...

[[
<p>
This is <span class="emph">default</span>.

</p>
<p>
This is <span class="emph">emph(asized)</span>.

</p>
<p>
This is <span class="strong">strong</span>.

</p>
<p>

This is <span class="verb">verb(atim)</span>.
]]

Aha!  It appears that all I need to do is provide an alternative CSS 
stylesheet?

The style generated by XMl2RFC is:
[[
     span.verb { font-style: oblique; }
]]

Now, how do I do this?  Hacking xml2rfc seems easiest.

It turns out to be simple in the extreme.
Adding just one line gives me just what I wanted:

In the stylesheet following:
[[
set htmlstyle \
   :
]]
add
[[
     span.code { font-family: monospace; font-size: 150%; }
]]

(This affects only the HTML version, but since txt and nr output is already 
viewed with monospace font, this seems OK.)

#g
--

At 11:38 04/11/03 +0100, Julian Reschke wrote:
>Graham Klyne wrote:
>
>>At 17:08 03/11/03 +0100, Julian Reschke wrote:
>>
>>>Graham Klyne wrote:
>>>
>>>>Background:  I use XML2RFC to create non-RFC documents for distribution 
>>>>as HTML.  It does most of the things I want, that many HTML tools 
>>>>don't.  (Table of contents generation and the bibliography library are 
>>>>two big wins.)
>>>>Simple case:  I'd like a 'spanx' option that renders text in a font 
>>>>similar to that used for <artwork> in a <figure>;  e.g. using the HTML 
>>>><code>...</code> tags.
>>>
>>>
>>>I think spanx/verb should do that (do you have the latest version of 
>>>xml2rf?).
>>
>>I'm using that at the moment, and it appears to simply apply an italic font.
>>Using version 1.21, which I think is up-to-date.
>
>Works for me. Testcase attached.
>
>Julian
>
>
>--
><green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
>
><?xml version="1.0" encoding="utf-8"?>
><?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
><?rfc toc="yes"?>
><?rfc symrefs="yes"?>
><?rfc-ext parse-xml-in-artwork="yes" ?>
><?rfc private="RFC2629 test cases"?>
><!DOCTYPE rfc
>   SYSTEM "rfc2629.dtd">
><rfc>
>         <front>
>         <title>Test cases for RFC2629 formatting</title>
>
>                         <author initials="J. F." surname="Reschke" 
> fullname="Julian F. Reschke">
>                                 <organization 
> abbrev="greenbytes">greenbytes GmbH</organization>
>         <address>
>                 <postal>
>                 <street>Salzmannstrasse 152</street>
>             <city>Muenster</city><region>NW</region><code>48159</code>
>                 <country>Germany</country>
>                 </postal>
>                   <phone>+49 251 2807760</phone>
>                         <facsimile>+49 251 2807761</facsimile>
> 
><email>[email-masked]</email>
> 
><uri>http://greenbytes.de/tech/webdav/</uri>
>                                 </address>
>                         </author>
>
>     <date month="June" year="2003"/>
>     <keyword>RFC2629</keyword>
>     <keyword>test case</keyword>
>     <keyword>xml2rfc</keyword>
>         </front>
>
>         <middle>
>
><section title="Lists" anchor="lists">
><section title="hanging list">
><t><list style="hanging">
>   <t hangText="Name:">timeout</t>
>   <t hangText="Namespace:">DAV:</t>
>   <t hangText="Purpose:">The timeout associated with a lock</t>
>   <t hangText="Value:">TimeType ;Defined in section 9.8</t>
></list></t></section>
>
><section title="numbered list">
><t>
>A numbered list:
><list style="numbers">
>   <t>one</t>
>   <t>two</t>
>   <t>three</t>
></list>
></t></section>
>
><section title="no explicit counters">
><t>
>   Example for numbered list with user-defined-format:
>   <list style="format R%d:">
>     <t>R1</t>
>     <t>R2</t>
>   </list>
></t>
><t>
>   Another list:
>   <list style="format S%d:">
>     <t>S1</t>
>     <t>S2</t>
>   </list>
></t>
><t>
>   Next list should continue counting R's:
>   <list style="format R%d:">
>     <t>R3</t>
>     <t>R4</t>
>   </list>
></t>
><t>
>   Same with character-based numbering:
>   <list style="format c-%c:">
>     <t>c-a</t>
>     <t>c-b</t>
>   </list>
></t>
></section>
>
><section title="with explicit counters">
><t>
>   A few requirements:
>   <list style="format R%d:" counter="requirements">
>     <t>req R1</t>
>     <t>req R2</t>
>   </list>
></t>
><t>
>   More requirements:
>   <list style="format R%d:" counter="requirements">
>     <t>req R3</t>
>     <t>req R4</t>
>   </list>
></t>
><t>
>   A few rules:
>   <list style="format R%d:" counter="rules">
>     <t>rule R1</t>
>     <t>rule R2</t>
>     <t>rule R3</t>
>   </list>
></t>
><t>
>   Explicit counter with name matching it's format string:
>   <list style="format c-%c:" counter="c-%c:">
>     <t>c-c</t>
>     <t>c-d</t>
>   </list>
></t>
><t>
>   Same, without counter:
>   <list style="format c-%c:">
>     <t>c-e</t>
>     <t>c-f</t>
>   </list>
>  </t>
></section>
>
></section>
>
><section title="spanx">
><t>
>This is <spanx>default</spanx>.
></t>
><t>
>This is <spanx style="emph">emph(asized)</spanx>.
></t>
><t>
>This is <spanx style="strong">strong</spanx>.
></t>
><t>
>This is <spanx style="verb">verb(atim)</spanx>.
></t>
></section>
>
><section title="Tables">
><texttable>
><preamble>The list of valid keywords are:</preamble>
><ttcol width="20%" align="right">keyword</ttcol>
><ttcol width="20%" align="center">default</ttcol>
><ttcol align="left">meaning</ttcol>
><ttcol>not aligned</ttcol>
>
><c>strict</c>
><c>no</c>
><c>try to enforce the ID-nits conventions and DTD validity</c>
><c>a</c>
>
><c>iprnotified</c>
><c>no</c>
><c>include boilerplate from Section 10.4(d) of <xref target="RFC2026"/></c>
><c>bb bb</c>
>
><c>compact</c>
><c>no</c>
><c>when producing a txt/nroff file, try to conserve vertical whitespace</c>
><c>ccc ccc ccc</c>
>
><c>subcompact</c>
><c>compact</c>
><c>if compact is "yes", then setting this to "no" will make things a 
>little less
>compact</c>
><c>dddd dddd dddd dddd</c>
>
><!--
>     ...                                                          ...
>
>   -->
>
><c>needLines</c>
><c>n/a</c>
><c>an integer hint indicating how many contiguous lines are needed at this 
>point
>in the output</c>
><c>eeeee eeeee eeeee eeeee eeeee </c>
><postamble>Remember,
>that as with everything else in XML,
>keywords and values are case-sensitive.</postamble>
></texttable>
></section>
>
><section title="Figures">
><figure>
>   <preamble>with preamble, no title...</preamble>
>   <artwork>
>   +--+
>   |  |
>   +--+
></artwork>
></figure>
>
><figure title="another figure" anchor="testfig">
>   <artwork>
>   +--+
>   |  |
>   +--+
></artwork>
><postamble>with postamble and title...</postamble>
></figure>
><t>
>   The figure above has the title "<xref target="testfig" format="title" />".
></t>
>
></section>
>
><section title="References" anchor="refs">
>
><section title="xref with no content">
><t>
>We are in <xref target="refs" />.
></t>
></section>
>
><section title="xref with no content">
><t>
><xref target="refs" /> is the parent section.
></t>
></section>
>
><section title="xref with no auto-formatting">
><t>
>So far we have sections <xref target="lists" format="counter" /> ("<xref 
>target="lists" format="title" />") through <xref target="refs" 
>format="counter"/>
>("<xref target="refs" format="title"/>").
></t>
></section>
>
><section title="eref with no content">
><t>
>See also <eref target="http://greenbytes.de/tech/webdav" />.
></t>
></section>
>
><section title="eref with content">
><t>
>See also <eref target="http://greenbytes.de/tech/webdav">greenbytes WebDAV 
>resources</eref>.
></t>
></section>
>
>
></section>
>
>     </middle>
>
>         <back>
>   <references>
>   <reference anchor='RFC2026'>
>
><front>
><title abbrev='Internet Standards Process'>The Internet Standards Process 
>-- Revision 3</title>
><author initials='S.' surname='Bradner' fullname='Scott O. Bradner'>
><organization>Harvard University</organization>
><address>
><postal>
><street>1350 Mass. Ave.</street>
><city>Cambridge</city>
><region>MA</region>
><code>02138</code>
><country>US</country></postal>
><phone>+1 617 495 3864</phone>
><email>[email-masked]</email></address></author>
><date month='October' year='1996' />
><abstract>
><t>This memo documents the process used by the Internet community for the 
>standardization of protocols and procedures.  It defines the stages in the 
>standardization process, the requirements for moving a document between 
>stages and the types of documents used during this process.  It also 
>addresses the intellectual property rights and copyright issues associated 
>with the standards process.</t></abstract></front>
>
><seriesInfo name='BCP' value='9' />
><seriesInfo name='RFC' value='2026' />
><format type='TXT' octets='86731' 
>target='ftp://ftp.isi.edu/in-notes/rfc2026.txt' />
></reference>
>
><reference anchor="RFC2396">
>
><front>
><title abbrev="URI Generic Syntax">Uniform Resource Identifiers (URI): 
>Generic Syntax</title>
><author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
><organization>World Wide Web Consortium</organization>
><address>
><postal>
><street>MIT Laboratory for Computer Science, NE43-356</street>
><street>545 Technology Square</street>
><city>Cambridge</city>
><region>MA</region>
><code>02139</code></postal>
><facsimile>+1(617)258-8682</facsimile>
><email>[email-masked]</email></address></author>
><author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
><organization>Department of Information and Computer Science</organization>
><address>
><postal>
><street>University of California, Irvine</street>
><city>Irvine</city>
><region>CA</region>
><code>92697-3425</code></postal>
><facsimile>+1(949)824-1715</facsimile>
><email>[email-masked]</email></address></author>
><author initials="L." surname="Masinter" fullname="Larry Masinter">
><organization>Xerox PARC</organization>
><address>
><postal>
><street>3333 Coyote Hill Road</street>
><city>Palo Alto</city>
><region>CA</region>
><code>94034</code></postal>
><facsimile>+1(415)812-4333</facsimile>
><email>[email-masked]</email></address></author>
><date month="August" year="1998"/>
><area>Applications</area>
><keyword>uniform resource</keyword>
><keyword>URI</keyword>
></front>
><seriesInfo name="RFC" value="2396"/>
><annotation>
>   This RFC will soon be updated, check
>   <eref 
> target="http://cvs.apache.org/viewcvs.cgi/*checkout*/ietf-uri/rev-2002/rfc2396bis.html" 
> /> for the latest draft.
></annotation>
><annotation>
>   The issues list is at <eref 
> target="http://cvs.apache.org/viewcvs.cgi/*checkout*/ietf-uri/rev-2002/issues.html" 
> />.
></annotation>
>
></reference>
>
>   </references>
>   </back>
></rfc>

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

From: [email-masked] (Julian Reschke)
Date: Tue, 04 Nov 2003 11:41:03 +0100
Subject: [xml2rfc] Another item for the wish-list
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Graham Klyne wrote:

> Well, in an all-singing, all-dancing world, I'm sure you're right.
> 
> One of the interesting things about XML2RFC is it's balance of 
> simplicity and functionality.  I'm sure that everyone whom uses it finds 
> something that isn't just how they'd choose it to be.  I waited until 
> I'd encountered my little niggle several times before suggesting it.
> 
> OTOH, when generating [X]HTML, being able to apply arbitrary classes via 
> spanx might be an escape hatch that is cheap to implement, and just 
> manages to steer clear of actually embodying display markup into the 
> XML2RFC source.  If one supplies one's own stylesheets.
> 
> BTW, didn't Carl Malamud say something a few months ago about doing a 
> new styling framework to make it easier to use one's own CSS stylesheets 
> with XML2RFC HTML output?  Did anything some of that?

I did some tests with RFC2629.xslt and alternate stylesheets. However, 
to make this truly useful we'll need to synchronize xml2rfc and 
rfc2629.xslt so that they case identical class names (otherwise the CSS 
code will not be interchangeable).

One interesting thing I tried was having a very simply CSS that uses 
just a fixed-width font and thus creates an HTML rendering that is very 
close to xml2rfc's text output.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Julian Reschke)
Date: Tue, 04 Nov 2003 11:38:16 +0100
Subject: [xml2rfc] Another item for the wish-list
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

This is a multi-part message in MIME format.
--------------020900080202080302040902
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Graham Klyne wrote:

> At 17:08 03/11/03 +0100, Julian Reschke wrote:
> 
>> Graham Klyne wrote:
>>
>>> Background:  I use XML2RFC to create non-RFC documents for 
>>> distribution as HTML.  It does most of the things I want, that many 
>>> HTML tools don't.  (Table of contents generation and the bibliography 
>>> library are two big wins.)
>>> Simple case:  I'd like a 'spanx' option that renders text in a font 
>>> similar to that used for <artwork> in a <figure>;  e.g. using the 
>>> HTML <code>...</code> tags.
>>
>>
>> I think spanx/verb should do that (do you have the latest version of 
>> xml2rf?).
> 
> 
> I'm using that at the moment, and it appears to simply apply an italic 
> font.
> 
> Using version 1.21, which I think is up-to-date.

Works for me. Testcase attached.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

--------------020900080202080302040902
Content-Type: text/xml;
 name="testcase.xml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="testcase.xml"

<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc-ext parse-xml-in-artwork="yes" ?>
<?rfc private="RFC2629 test cases"?>
<!DOCTYPE rfc
  SYSTEM "rfc2629.dtd">
<rfc>
	<front>
    	<title>Test cases for RFC2629 formatting</title>

			<author initials="J. F." surname="Reschke" fullname="Julian F. Reschke">
				<organization abbrev="greenbytes">greenbytes GmbH</organization>
        <address>
        	<postal>
          	<street>Salzmannstrasse 152</street>
            <city>Muenster</city><region>NW</region><code>48159</code>
           	<country>Germany</country>
         	</postal>
    		  <phone>+49 251 2807760</phone>	
		    	<facsimile>+49 251 2807761</facsimile>	
				  <email>[email-masked]</email>	
				  <uri>http://greenbytes.de/tech/webdav/</uri>	
				</address>
			</author>
      
    <date month="June" year="2003"/>
    <keyword>RFC2629</keyword>
    <keyword>test case</keyword>
    <keyword>xml2rfc</keyword>
	</front>

	<middle>

<section title="Lists" anchor="lists">
<section title="hanging list">
<t><list style="hanging">
  <t hangText="Name:">timeout</t>
  <t hangText="Namespace:">DAV:</t>
  <t hangText="Purpose:">The timeout associated with a lock</t>
  <t hangText="Value:">TimeType ;Defined in section 9.8</t>
</list></t></section>

<section title="numbered list">
<t>
A numbered list:
<list style="numbers">
  <t>one</t>
  <t>two</t>
  <t>three</t>
</list>
</t></section>

<section title="no explicit counters">
<t>
  Example for numbered list with user-defined-format:
  <list style="format R%d:">
    <t>R1</t>
    <t>R2</t>
  </list>
</t>
<t>
  Another list:
  <list style="format S%d:">
    <t>S1</t>
    <t>S2</t>
  </list>
</t>
<t>
  Next list should continue counting R's:
  <list style="format R%d:">
    <t>R3</t>
    <t>R4</t>
  </list>
</t>
<t>
  Same with character-based numbering:
  <list style="format c-%c:">
    <t>c-a</t>
    <t>c-b</t>
  </list>
</t>
</section>

<section title="with explicit counters">
<t>
  A few requirements:
  <list style="format R%d:" counter="requirements">
    <t>req R1</t>
    <t>req R2</t>
  </list>
</t>
<t>
  More requirements:
  <list style="format R%d:" counter="requirements">
    <t>req R3</t>
    <t>req R4</t>
  </list>
</t>
<t>
  A few rules:
  <list style="format R%d:" counter="rules">
    <t>rule R1</t>
    <t>rule R2</t>
    <t>rule R3</t>
  </list> 
</t>
<t>
  Explicit counter with name matching it's format string:
  <list style="format c-%c:" counter="c-%c:">
    <t>c-c</t>
    <t>c-d</t>
  </list>
</t>
<t>
  Same, without counter:
  <list style="format c-%c:">
    <t>c-e</t>
    <t>c-f</t>
  </list>
 </t>
</section>

</section>

<section title="spanx">
<t>
This is <spanx>default</spanx>.
</t>
<t>
This is <spanx style="emph">emph(asized)</spanx>.
</t>
<t>
This is <spanx style="strong">strong</spanx>.
</t>
<t>
This is <spanx style="verb">verb(atim)</spanx>.
</t>
</section>

<section title="Tables">
<texttable>
<preamble>The list of valid keywords are:</preamble>
<ttcol width="20%" align="right">keyword</ttcol>
<ttcol width="20%" align="center">default</ttcol>
<ttcol align="left">meaning</ttcol>
<ttcol>not aligned</ttcol>

<c>strict</c>
<c>no</c>
<c>try to enforce the ID-nits conventions and DTD validity</c>
<c>a</c>

<c>iprnotified</c>
<c>no</c>
<c>include boilerplate from Section 10.4(d) of <xref target="RFC2026"/></c>
<c>bb bb</c>

<c>compact</c>
<c>no</c>
<c>when producing a txt/nroff file, try to conserve vertical whitespace</c>
<c>ccc ccc ccc</c>
    
<c>subcompact</c>
<c>compact</c>
<c>if compact is "yes", then setting this to "no" will make things a little less
compact</c>
<c>dddd dddd dddd dddd</c>
    
<!--
    ...                                                          ...
    
  -->
    
<c>needLines</c>
<c>n/a</c>
<c>an integer hint indicating how many contiguous lines are needed at this point
in the output</c>
<c>eeeee eeeee eeeee eeeee eeeee </c>
<postamble>Remember,
that as with everything else in XML,
keywords and values are case-sensitive.</postamble>
</texttable>
</section>

<section title="Figures">
<figure>
  <preamble>with preamble, no title...</preamble>
  <artwork>
  +--+
  |  |
  +--+
</artwork>
</figure>

<figure title="another figure" anchor="testfig">
  <artwork>
  +--+
  |  |
  +--+
</artwork>
<postamble>with postamble and title...</postamble>
</figure>
<t>
  The figure above has the title "<xref target="testfig" format="title" />".
</t>

</section>

<section title="References" anchor="refs">

<section title="xref with no content">
<t>
We are in <xref target="refs" />.
</t>
</section>

<section title="xref with no content">
<t>
<xref target="refs" /> is the parent section.
</t>
</section>

<section title="xref with no auto-formatting">
<t>
So far we have sections <xref target="lists" format="counter" /> ("<xref target="lists" format="title" />") through <xref target="refs" format="counter"/>
("<xref target="refs" format="title"/>").
</t>
</section>

<section title="eref with no content">
<t>
See also <eref target="http://greenbytes.de/tech/webdav" />.
</t>
</section>

<section title="eref with content">
<t>
See also <eref target="http://greenbytes.de/tech/webdav">greenbytes WebDAV resources</eref>.
</t>
</section>

</section>

    </middle>

	<back>
  <references>
  <reference anchor='RFC2026'>

<front>
<title abbrev='Internet Standards Process'>The Internet Standards Process -- Revision 3</title>
<author initials='S.' surname='Bradner' fullname='Scott O. Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country></postal>
<phone>+1 617 495 3864</phone>
<email>[email-masked]</email></address></author>
<date month='October' year='1996' />
<abstract>
<t>This memo documents the process used by the Internet community for the standardization of protocols and procedures.  It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process.  It also addresses the intellectual property rights and copyright issues associated with the standards process.</t></abstract></front>

<seriesInfo name='BCP' value='9' />
<seriesInfo name='RFC' value='2026' />
<format type='TXT' octets='86731' target='ftp://ftp.isi.edu/in-notes/rfc2026.txt' />
</reference>

<reference anchor="RFC2396">

<front>
<title abbrev="URI Generic Syntax">Uniform Resource Identifiers (URI): Generic Syntax</title>
<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
<organization>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>[email-masked]</email></address></author>
<author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
<organization>Department of Information and Computer Science</organization>
<address>
<postal>
<street>University of California, Irvine</street>
<city>Irvine</city>
<region>CA</region>
<code>92697-3425</code></postal>
<facsimile>+1(949)824-1715</facsimile>
<email>[email-masked]</email></address></author>
<author initials="L." surname="Masinter" fullname="Larry Masinter">
<organization>Xerox PARC</organization>
<address>
<postal>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94034</code></postal>
<facsimile>+1(415)812-4333</facsimile>
<email>[email-masked]</email></address></author>
<date month="August" year="1998"/>
<area>Applications</area>
<keyword>uniform resource</keyword>
<keyword>URI</keyword>
</front>
<seriesInfo name="RFC" value="2396"/>
<annotation>
  This RFC will soon be updated, check
  <eref target="http://cvs.apache.org/viewcvs.cgi/*checkout*/ietf-uri/rev-2002/rfc2396bis.html" /> for the latest draft.
</annotation>
<annotation>
  The issues list is at <eref target="http://cvs.apache.org/viewcvs.cgi/*checkout*/ietf-uri/rev-2002/issues.html" />.
</annotation>

</reference>

  </references>
  </back>
</rfc>
--------------020900080202080302040902--

From: [email-masked] (Graham Klyne)
Date: Mon, 03 Nov 2003 23:58:55 +0000
Subject: [xml2rfc] Small problem with texttables
In-Reply-To: <[email-masked]. ca.us>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

At 12:05 03/11/03 -0800, Marshall Rose wrote:
> > BTW, when tables were discussed, there was some discussion of options to
> > suppress the borders.  Was that ever done?  I see nothing in the
> > documentation.
>
>
>did you try
>
>     <?rfc compact='yes'?>

Yes, but I also have:
[[
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
]]

as part of my standard prelude.

(This isn't a big deal... I ended up using <figure>.  But as a matter of 
general principle, I think it was Tufte in one of his books on graphical 
presentation who makes the point that less ink is generally better, if the 
required information is conveyed.)

#g
--

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

From: [email-masked] (Graham Klyne)
Date: Mon, 03 Nov 2003 23:55:59 +0000
Subject: [xml2rfc] Another item for the wish-list
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Well, in an all-singing, all-dancing world, I'm sure you're right.

One of the interesting things about XML2RFC is it's balance of simplicity 
and functionality.  I'm sure that everyone whom uses it finds something 
that isn't just how they'd choose it to be.  I waited until I'd encountered 
my little niggle several times before suggesting it.

OTOH, when generating [X]HTML, being able to apply arbitrary classes via 
spanx might be an escape hatch that is cheap to implement, and just manages 
to steer clear of actually embodying display markup into the XML2RFC 
source.  If one supplies one's own stylesheets.

BTW, didn't Carl Malamud say something a few months ago about doing a new 
styling framework to make it easier to use one's own CSS stylesheets with 
XML2RFC HTML output?  Did anything some of that?

#g
--

At 09:41 03/11/03 -0700, Alex Rousskov wrote:

>Graham,
>
>         An arguably better solution for your needs could be an
>addition of a class attribute to spanx rather than "overloading" of
>the style attribute. Spanx.style would never be able to capture all
>user-defined needs. Spanx.class with user-defined classes would let
>you do whatever you want. Note that xml2rfc already uses CSS in HTML.
>What's missing is support for user-defined CSS entries in <head>.
>
>         Thinking a step further, if user-defined CSS entries in <head>
>are supported, then every xml2rfc element should have a class
>attribute!
>
>         A counter-argument would be that user-defined CSS would make
>RFCs look different depending on author's preference. Also, it would
>make some HTML RFCs a lot different from their plain text versions
>(recall that CSS can be used to generate text runtime!). There is a
>trade-off between trying to accommodate hundreds of style needs and
>keeping RFC looks consistent.
>
>$0.02,
>
>Alex.
>
>
>On Mon, 3 Nov 2003, Graham Klyne wrote:
>
> > Background:  I use XML2RFC to create non-RFC documents for distribution as
> > HTML.  It does most of the things I want, that many HTML tools
> > don't.  (Table of contents generation and the bibliography library are two
> > big wins.)
> >
> > Simple case:  I'd like a 'spanx' option that renders text in a font similar
> > to that used for <artwork> in a <figure>;  e.g. using the HTML
> > <code>...</code> tags.
> >
> > And a slightly more complex case:  A spanx option that combines the effects
> > of style='verb' and the above, for meta-variables in text that is otherwise
> > presented as <code>...</code>.
> >
> > #g
> >
> > ------------
> > Graham Klyne
> > For email:
> > http://www.ninebynine.org/#Contact

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

From: [email-masked] (Graham Klyne)
Date: Mon, 03 Nov 2003 23:49:50 +0000
Subject: [xml2rfc] Another item for the wish-list
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

At 17:08 03/11/03 +0100, Julian Reschke wrote:
>Graham Klyne wrote:
>>Background:  I use XML2RFC to create non-RFC documents for distribution 
>>as HTML.  It does most of the things I want, that many HTML tools 
>>don't.  (Table of contents generation and the bibliography library are 
>>two big wins.)
>>Simple case:  I'd like a 'spanx' option that renders text in a font 
>>similar to that used for <artwork> in a <figure>;  e.g. using the HTML 
>><code>...</code> tags.
>
>I think spanx/verb should do that (do you have the latest version of xml2rf?).

I'm using that at the moment, and it appears to simply apply an italic font.

Using version 1.21, which I think is up-to-date.

#g

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

From: [email-masked] (Marshall Rose)
Date: Mon, 3 Nov 2003 12:05:15 -0800
Subject: [xml2rfc] Small problem with texttables
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> BTW, when tables were discussed, there was some discussion of options to 
> suppress the borders.  Was that ever done?  I see nothing in the
> documentation.

did you try
    
    <?rfc compact='yes'?>
    
/mtr

From: [email-masked] (Alex Rousskov)
Date: Mon, 3 Nov 2003 09:41:09 -0700 (MST)
Subject: [xml2rfc] Another item for the wish-list
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Graham,

	An arguably better solution for your needs could be an
addition of a class attribute to spanx rather than "overloading" of
the style attribute. Spanx.style would never be able to capture all
user-defined needs. Spanx.class with user-defined classes would let
you do whatever you want. Note that xml2rfc already uses CSS in HTML.
What's missing is support for user-defined CSS entries in <head>.

	Thinking a step further, if user-defined CSS entries in <head>
are supported, then every xml2rfc element should have a class
attribute!

	A counter-argument would be that user-defined CSS would make
RFCs look different depending on author's preference. Also, it would
make some HTML RFCs a lot different from their plain text versions
(recall that CSS can be used to generate text runtime!). There is a
trade-off between trying to accommodate hundreds of style needs and
keeping RFC looks consistent.

$0.02,

Alex.

On Mon, 3 Nov 2003, Graham Klyne wrote:

> Background:  I use XML2RFC to create non-RFC documents for distribution as
> HTML.  It does most of the things I want, that many HTML tools
> don't.  (Table of contents generation and the bibliography library are two
> big wins.)
>
> Simple case:  I'd like a 'spanx' option that renders text in a font similar
> to that used for <artwork> in a <figure>;  e.g. using the HTML
> <code>...</code> tags.
>
> And a slightly more complex case:  A spanx option that combines the effects
> of style='verb' and the above, for meta-variables in text that is otherwise
> presented as <code>...</code>.
>
> #g
>
> ------------
> Graham Klyne
> For email:
> http://www.ninebynine.org/#Contact

From: [email-masked] (Julian Reschke)
Date: Mon, 03 Nov 2003 17:08:54 +0100
Subject: [xml2rfc] Another item for the wish-list
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Graham Klyne wrote:
> Background:  I use XML2RFC to create non-RFC documents for distribution 
> as HTML.  It does most of the things I want, that many HTML tools 
> don't.  (Table of contents generation and the bibliography library are 
> two big wins.)
> 
> Simple case:  I'd like a 'spanx' option that renders text in a font 
> similar to that used for <artwork> in a <figure>;  e.g. using the HTML 
> <code>...</code> tags.

I think spanx/verb should do that (do you have the latest version of 
xml2rf?).

> And a slightly more complex case:  A spanx option that combines the 
> effects of style='verb' and the above, for meta-variables in text that 
> is otherwise presented as <code>...</code>.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Alex Rousskov)
Date: Mon, 3 Nov 2003 08:53:08 -0700 (MST)
Subject: [xml2rfc] xref inside a texttable
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Miguel,

	Glad it works for you. I am rather certain that I have
identified the problem correctly because commenting out an xref from
the table cell "solves" the problem and because setting rfc.strict to
"no", as suggested by Marshall, solves the problem as well.

	There could be some document-specific things that make a
difference between our cases, of course. I do not claim to have
narrowed all the dependencies to a minimum. I assume Marshall knows
what is going on, but am happy to provide a test case if needed.

Thanks,

Alex.

On Mon, 3 Nov 2003, Miguel A. Garcia wrote:

> This is strange. I've written a draft with references in the text
> table, and I never had a problem.
>
> I have just checked the conversion to both .txt and .html, with both
> strict='yes' and strict='no', and I don't get any problem. The
> conversion is always brilliant.
>
> This is how my reference looks like (pretty normal):
>
> <c><xref target="UAR"/></c>
>
> So I suspect that Alex may have another overlapped problem...
> or....?
>
> /Miguel
>
> Marshall Rose wrote:
>
> >>	I am getting a "not expecting <xref> around line 2637" error
> >>when I do
> >>
> >>	<c><xref target="foo" /></c>
> >>
> >>inside a texttable.
> >
> >
> > yep, that's a bug. i'll put up a new version after the IETF. in the
> > interim, use
> >
> > 	<?rfc strict='no'?>
> >
> > and that will turn off structural checking...
> >
> > /mtr
> >
> > _______________________________________________
> > xml2rfc mailing list
> > [email-masked]
> > http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> >
>
> --
> Miguel-Angel Garcia                     Oy LM Ericsson AB
>                                          Jorvas, Finland
> mailto:[email-masked]     Phone:  +358 9 299 3553
> mailto:[email-masked]        Mobile: +358 40 514 0002
>
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>

From: [email-masked] (Miguel A. Garcia)
Date: Mon, 03 Nov 2003 16:58:50 +0200
Subject: [xml2rfc] xref inside a texttable
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

This is strange. I've written a draft with references in the text table, 
and I never had a problem.

I have just checked the conversion to both .txt and .html, with both 
strict='yes' and strict='no', and I don't get any problem. The 
conversion is always brilliant.

This is how my reference looks like (pretty normal):

<c><xref target="UAR"/></c>

So I suspect that Alex may have another overlapped problem... or....?

/Miguel

Marshall Rose wrote:

>>	I am getting a "not expecting <xref> around line 2637" error
>>when I do
>>
>>	<c><xref target="foo" /></c>
>>
>>inside a texttable.
> 
> 
> yep, that's a bug. i'll put up a new version after the IETF. in the
> interim, use
>     
> 	<?rfc strict='no'?>
>     
> and that will turn off structural checking...
>     
> /mtr
>     
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                         Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 514 0002

From: [email-masked] (Graham Klyne)
Date: Mon, 03 Nov 2003 11:48:51 +0000
Subject: [xml2rfc] Small problem with texttables
Message-ID: <[email-masked]>

I noticed a small problem with texttables recently (using version 1.21, I 
think -- I recently upgraded and may have observed this using an older 
version, possibly 1.18)

I wanted to create a table without column headings, so I assumed that if 
all the <ttcol> elements were empty then the column headings (and 
associated horizontal rule) would be suppressed.  Not so, instead I 
got:  no column heading text, but double horizontal rules at the top of the 
table, instead of just one.  (This was observed with both HTML and text.)

BTW, when tables were discussed, there was some discussion of options to 
suppress the borders.  Was that ever done?  I see nothing in the documentation.

#g

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

From: [email-masked] (Graham Klyne)
Date: Mon, 03 Nov 2003 11:36:56 +0000
Subject: [xml2rfc] Another item for the wish-list
Message-ID: <[email-masked]>

Background:  I use XML2RFC to create non-RFC documents for distribution as 
HTML.  It does most of the things I want, that many HTML tools 
don't.  (Table of contents generation and the bibliography library are two 
big wins.)

Simple case:  I'd like a 'spanx' option that renders text in a font similar 
to that used for <artwork> in a <figure>;  e.g. using the HTML 
<code>...</code> tags.

And a slightly more complex case:  A spanx option that combines the effects 
of style='verb' and the above, for meta-variables in text that is otherwise 
presented as <code>...</code>.

#g

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

From: [email-masked] (Marshall Rose)
Date: Sun, 2 Nov 2003 15:28:57 -0800
Subject: [xml2rfc] xref inside a texttable
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> 	I am getting a "not expecting <xref> around line 2637" error
> when I do
> 
> 	<c><xref target="foo" /></c>
> 
> inside a texttable.

yep, that's a bug. i'll put up a new version after the IETF. in the
interim, use
    
	<?rfc strict='no'?>
    
and that will turn off structural checking...
    
/mtr

From: [email-masked] (Fred Baker)
Date: Sun, 02 Nov 2003 16:55:21 -0500
Subject: [xml2rfc] editing RFC2629-xml with Word 2003
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked] >

At 11:48 AM 11/2/2003, Leif Johansson wrote:
>Pgsml in xemacs does it very smoothly: When you right-click in the
>element the possible attributes pop-up. Simple and easy to understand.

I use XML Spy, which does pretty much the above. It's not whatcha call 
WYSIWYG, though...

I'd be in the market for a WYSIWYG editor that would literally allow me to 
see the text in something like internet draft format. Doesn't have to add 
the boilerplate - I'm happy to post-process to get that. But it would be 
really nice to hit a carriage return (aka "paragraph mark") and have the 
result be "</t><t>", and at any point be able to right-click and see all my 
legal options and be able to select one.

XML Spy, apart from WYSIWYGness, does most of that, and is a pretty nice 
tool. But you see and deal with all the formatting whatsits. 

From: [email-masked] (Eric Burger)
Date: Sun, 2 Nov 2003 15:18:47 -0500
Subject: [xml2rfc] editing RFC2629-xml with Word 2003
Message-ID: <[email-masked]>

I've been rather happy with XMLSPY.  It understands DTDs, and also does XSD conversions.

> -----Original Message-----
> From: Julian Reschke [mailto:[email-masked]]
> Sent: Sun, November 02, 2003 8:07 AM
> To: [email-masked]
> Subject: [xml2rfc] editing RFC2629-xml with Word 2003
> 
> 
> Hi.
> 
> 
> Today I finally decided to give it a try. Word 2003 is supposed to
> 
> i) act as a simple XML editor and
> ii) round-trip XSLT-formatted XML through the WYSIWYG editor.
> 
> The latter option sounds really interesting, but unfortunately it 
> requires writing an XSLT that maps from and to WordML markup.
> 
> Therefore I decided to try the first option.
> 
> Word doesn't support DTDs, so the first step is to generate an 
> equivalent XML Schema. Fortunately, this is easy using James Clark's 
> excellent "Trang" conversion tool (XSD is attached).
> 
> After some frustrating point&clicking I discovered how to add 
> an XSD to 
> the schema library, and how to associate it with an open document. 
> However, after associating RFC2396.xml to that schema, Word 
> is extremely 
> confused, keeping the structure but mixing up all elements 
> (for instance 
> it claims that the document element is "preamble").
> 
> Second try - create a new document. This works better, however Word's 
> assistance in actually generating a valid document isn't that 
> great. For 
> instance, it correctly diagnoses that I can't leave <rfc> 
> empty and also 
> suggests what to put in. After adding a <title>, it also asks for an 
> <author> element. However, when I add that it appears at the cursor 
> position, not at the position specified by the grammar.
> 
> Editing attributes is a pain, because you need to open a dialogue (I 
> think other XML editors have similar problems with 
> attributes, though).
> 
> Summary: I'll keep using HTML-Kit for now (it has 
> wellformed-ness checks 
> and DTD validation as plug-ins, and I can quickly preview in 
> IE/Mozilla 
> using XSLT).
> 
> Did others have more luck getting Word to co-operate?
> 
> Regards, Julian
> 
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 

From: [email-masked] (Alex Rousskov)
Date: Sun, 2 Nov 2003 12:32:58 -0700 (MST)
Subject: [xml2rfc] xref inside a texttable
Message-ID: <[email-masked]>

Hi,

	I am getting a "not expecting <xref> around line 2637" error
when I do

	<c><xref target="foo" /></c>

inside a texttable. Without the xref element, the table compiles fine.
I looked at the DTD and it seems to allow references in c elements:

	<!ELEMENT c           (%TEXT;|xref|eref|iref|spanx)*>

I assume that tables were meant to support xrefs because many RFC
contain "summary" tables of things like protocol messages, pointing
back to sections where each "thing" is defined.

What am I doing wrong?

Thanks,

Alex.

P.S. This problem was tested with online interface and xml2rfc 1.21.

From: [email-masked] (Leif Johansson)
Date: Sun, 02 Nov 2003 14:48:36 +0100
Subject: [xml2rfc] editing RFC2629-xml with Word 2003
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

|
| Editing attributes is a pain, because you need to open a dialogue (I
| think other XML editors have similar problems with attributes, though).

Pgsml in xemacs does it very smoothly: When you right-click in the
element the possible attributes pop-up. Simple and easy to understand.

	Cheers Leif

From: [email-masked] (Julian Reschke)
Date: Sun, 02 Nov 2003 14:07:26 +0100
Subject: [xml2rfc] editing RFC2629-xml with Word 2003
Message-ID: <[email-masked]>

This is a multi-part message in MIME format.
--------------030003050405000503090808
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi.

Today I finally decided to give it a try. Word 2003 is supposed to

i) act as a simple XML editor and
ii) round-trip XSLT-formatted XML through the WYSIWYG editor.

The latter option sounds really interesting, but unfortunately it 
requires writing an XSLT that maps from and to WordML markup.

Therefore I decided to try the first option.

Word doesn't support DTDs, so the first step is to generate an 
equivalent XML Schema. Fortunately, this is easy using James Clark's 
excellent "Trang" conversion tool (XSD is attached).

After some frustrating point&clicking I discovered how to add an XSD to 
the schema library, and how to associate it with an open document. 
However, after associating RFC2396.xml to that schema, Word is extremely 
confused, keeping the structure but mixing up all elements (for instance 
it claims that the document element is "preamble").

Second try - create a new document. This works better, however Word's 
assistance in actually generating a valid document isn't that great. For 
instance, it correctly diagnoses that I can't leave <rfc> empty and also 
suggests what to put in. After adding a <title>, it also asks for an 
<author> element. However, when I add that it appears at the cursor 
position, not at the position specified by the grammar.

Editing attributes is a pain, because you need to open a dialogue (I 
think other XML editors have similar problems with attributes, though).

Summary: I'll keep using HTML-Kit for now (it has wellformed-ness checks 
and DTD validation as plug-ins, and I can quickly preview in IE/Mozilla 
using XSLT).

Did others have more luck getting Word to co-operate?

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

--------------030003050405000503090808
Content-Type: text/xml;
 name="rfc2629.xsd"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="rfc2629.xsd"

<?xml version="1.0" encoding="UTF-8"?>
<!-- revised DTD for the RFC document series, draft of 2002-07-13 -->
<!--
  Contents
  
    DTD data types
  
    The top-level
  
    Front matter
  
    The Body
  
    Back matter
-->
<!--
  DTD data types:
  
        entity        description
        ======        ===============================================
        NUMBER        [0-9]+
        NUMBERS       a comma-separated list of NUMBER
  
        DAY           the day of the month, e.g., "1"
        MONTH         the month of the year, e.g., "January"
        YEAR          a four-digit year, e.g., "1999"
  
        URI           e.g., "http://invisible.net/"
  
        ATEXT/CTEXT   printable ASCII text (no line-terminators)
  
        TEXT          character data
-->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
  <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="xml.xsd"/>
  <xs:simpleType name="NUMBER">
    <xs:restriction base="xs:string"/>
  </xs:simpleType>
  <xs:simpleType name="NUMBERS">
    <xs:restriction base="xs:string"/>
  </xs:simpleType>
  <xs:simpleType name="DAY">
    <xs:restriction base="xs:string"/>
  </xs:simpleType>
  <xs:simpleType name="MONTH">
    <xs:restriction base="xs:string"/>
  </xs:simpleType>
  <xs:simpleType name="YEAR">
    <xs:restriction base="xs:string"/>
  </xs:simpleType>
  <xs:simpleType name="URI">
    <xs:restriction base="xs:string"/>
  </xs:simpleType>
  <xs:simpleType name="ATEXT">
    <xs:restriction base="xs:string"/>
  </xs:simpleType>
  <!-- The top-level -->
  <!--
    attributes for the "rfc" element are supplied by the RFC
    editor. when preparing drafts, authors should leave them blank.
    
    the "seriesNo" attribute is used if the category is, e.g., BCP.
  -->
  <xs:element name="rfc">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="front"/>
        <xs:element ref="middle"/>
        <xs:element minOccurs="0" ref="back"/>
      </xs:sequence>
      <xs:attribute name="number" type="NUMBER"/>
      <xs:attribute name="obsoletes" default="" type="NUMBERS"/>
      <xs:attribute name="updates" default="" type="NUMBERS"/>
      <xs:attribute name="category" default="info">
        <xs:simpleType>
          <xs:restriction base="xs:token">
            <xs:enumeration value="std"/>
            <xs:enumeration value="bcp"/>
            <xs:enumeration value="info"/>
            <xs:enumeration value="exp"/>
            <xs:enumeration value="historic"/>
          </xs:restriction>
        </xs:simpleType>
      </xs:attribute>
      <xs:attribute name="seriesNo" type="NUMBER"/>
      <xs:attribute name="ipr">
        <xs:simpleType>
          <xs:restriction base="xs:token">
            <xs:enumeration value="full2026"/>
            <xs:enumeration value="noDerivativeWorks2026"/>
            <xs:enumeration value="none"/>
          </xs:restriction>
        </xs:simpleType>
      </xs:attribute>
      <xs:attribute name="docName" type="ATEXT"/>
    </xs:complexType>
  </xs:element>
  <!-- Front matter -->
  <xs:element name="front">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="title"/>
        <xs:element maxOccurs="unbounded" ref="author"/>
        <xs:element ref="date"/>
        <xs:element minOccurs="0" maxOccurs="unbounded" ref="area"/>
        <xs:element minOccurs="0" maxOccurs="unbounded" ref="workgroup"/>
        <xs:element minOccurs="0" maxOccurs="unbounded" ref="keyword"/>
        <xs:element minOccurs="0" ref="abstract"/>
        <xs:element minOccurs="0" maxOccurs="unbounded" ref="note"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <!-- the "abbrev" attribute is used for headers, etc. -->
  <xs:element name="title">
    <xs:complexType mixed="true">
      <xs:attribute name="abbrev" type="ATEXT"/>
    </xs:complexType>
  </xs:element>
  <xs:element name="author">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="organization"/>
        <xs:element minOccurs="0" ref="address"/>
      </xs:sequence>
      <xs:attribute name="initials" type="ATEXT"/>
      <xs:attribute name="surname" type="ATEXT"/>
      <xs:attribute name="fullname" type="ATEXT"/>
      <xs:attribute name="role">
        <xs:simpleType>
          <xs:restriction base="xs:token">
            <xs:enumeration value="editor"/>
          </xs:restriction>
        </xs:simpleType>
      </xs:attribute>
    </xs:complexType>
  </xs:element>
  <xs:element name="organization">
    <xs:complexType mixed="true">
      <xs:attribute name="abbrev" type="ATEXT"/>
    </xs:complexType>
  </xs:element>
  <xs:element name="address">
    <xs:complexType>
      <xs:sequence>
        <xs:element minOccurs="0" ref="postal"/>
        <xs:element minOccurs="0" ref="phone"/>
        <xs:element minOccurs="0" ref="facsimile"/>
        <xs:element minOccurs="0" ref="email"/>
        <xs:element minOccurs="0" ref="uri"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <!--
    at most one of each the city, region, code, and country
    elements may be present
  -->
  <xs:element name="postal">
    <xs:complexType>
      <xs:sequence>
        <xs:element maxOccurs="unbounded" ref="street"/>
        <xs:choice minOccurs="0" maxOccurs="unbounded">
          <xs:element ref="city"/>
          <xs:element ref="region"/>
          <xs:element ref="code"/>
          <xs:element ref="country"/>
        </xs:choice>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="street" type="xs:string"/>
  <xs:element name="city" type="xs:string"/>
  <xs:element name="region" type="xs:string"/>
  <xs:element name="code" type="xs:string"/>
  <xs:element name="country" type="xs:string"/>
  <xs:element name="phone" type="xs:string"/>
  <xs:element name="facsimile" type="xs:string"/>
  <xs:element name="email" type="xs:string"/>
  <xs:element name="uri" type="xs:string"/>
  <xs:element name="date">
    <xs:complexType>
      <xs:attribute name="day" type="DAY"/>
      <xs:attribute name="month" type="MONTH"/>
      <xs:attribute name="year" use="required" type="YEAR"/>
    </xs:complexType>
  </xs:element>
  <!-- meta-data... -->
  <xs:element name="area" type="xs:string"/>
  <xs:element name="workgroup" type="xs:string"/>
  <xs:element name="keyword" type="xs:string"/>
  <xs:element name="abstract">
    <xs:complexType>
      <xs:sequence>
        <xs:element maxOccurs="unbounded" ref="t"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="note">
    <xs:complexType>
      <xs:sequence>
        <xs:element maxOccurs="unbounded" ref="t"/>
      </xs:sequence>
      <xs:attribute name="title" use="required" type="ATEXT"/>
    </xs:complexType>
  </xs:element>
  <!-- The body -->
  <!-- later on, may be (section+,appendix*,section*) -->
  <xs:element name="middle">
    <xs:complexType>
      <xs:sequence>
        <xs:element maxOccurs="unbounded" ref="section"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="section">
    <xs:complexType>
      <xs:choice minOccurs="0" maxOccurs="unbounded">
        <xs:element ref="t"/>
        <xs:element ref="figure"/>
        <xs:element ref="texttable"/>
        <xs:element ref="iref"/>
        <xs:element ref="section"/>
      </xs:choice>
      <xs:attribute name="anchor" type="xs:ID"/>
      <xs:attribute name="title" use="required" type="ATEXT"/>
    </xs:complexType>
  </xs:element>
  <!--
    <!ELEMENT appendix    (t|figure|texttable|iref|appendix)*>
    <!ATTLIST appendix
              anchor      ID                 #IMPLIED
              title       %ATEXT;            #REQUIRED>
  -->
  <!-- use of <figure/> is deprecated... -->
  <xs:element name="t">
    <xs:complexType mixed="true">
      <xs:choice minOccurs="0" maxOccurs="unbounded">
        <xs:element ref="list"/>
        <xs:element ref="figure"/>
        <xs:element ref="xref"/>
        <xs:element ref="eref"/>
        <xs:element ref="iref"/>
        <xs:element ref="spanx"/>
        <xs:element ref="vspace"/>
      </xs:choice>
      <xs:attribute name="hangText" type="ATEXT"/>
    </xs:complexType>
  </xs:element>
  <!--
    the value of the style attribute is inherited from the closest 
    parent
  -->
  <xs:element name="list">
    <xs:complexType>
      <xs:sequence>
        <xs:element maxOccurs="unbounded" ref="t"/>
      </xs:sequence>
      <xs:attribute name="style" default="empty" type="ATEXT"/>
      <xs:attribute name="hangIndent" type="NUMBER"/>
      <xs:attribute name="counter" type="ATEXT"/>
    </xs:complexType>
  </xs:element>
  <xs:element name="xref">
    <xs:complexType mixed="true">
      <xs:attribute name="target" use="required" type="xs:IDREF"/>
      <xs:attribute name="pageno" default="false">
        <xs:simpleType>
          <xs:restriction base="xs:token">
            <xs:enumeration value="true"/>
            <xs:enumeration value="false"/>
          </xs:restriction>
        </xs:simpleType>
      </xs:attribute>
      <xs:attribute name="format" default="default">
        <xs:simpleType>
          <xs:restriction base="xs:token">
            <xs:enumeration value="counter"/>
            <xs:enumeration value="title"/>
            <xs:enumeration value="default"/>
          </xs:restriction>
        </xs:simpleType>
      </xs:attribute>
    </xs:complexType>
  </xs:element>
  <xs:element name="eref">
    <xs:complexType mixed="true">
      <xs:attribute name="target" use="required" type="URI"/>
    </xs:complexType>
  </xs:element>
  <xs:element name="iref">
    <xs:complexType>
      <xs:attribute name="item" use="required" type="ATEXT"/>
      <xs:attribute name="subitem" default="" type="ATEXT"/>
      <xs:attribute name="primary" default="false">
        <xs:simpleType>
          <xs:restriction base="xs:token">
            <xs:enumeration value="true"/>
            <xs:enumeration value="false"/>
          </xs:restriction>
        </xs:simpleType>
      </xs:attribute>
    </xs:complexType>
  </xs:element>
  <xs:element name="spanx">
    <xs:complexType mixed="true">
      <xs:attribute ref="xml:space" default="preserve"/>
      <xs:attribute name="style" default="emph" type="ATEXT"/>
    </xs:complexType>
  </xs:element>
  <xs:element name="vspace">
    <xs:complexType>
      <xs:attribute name="blankLines" default="0" type="NUMBER"/>
    </xs:complexType>
  </xs:element>
  <xs:element name="figure">
    <xs:complexType>
      <xs:sequence>
        <xs:element minOccurs="0" ref="preamble"/>
        <xs:element ref="artwork"/>
        <xs:element minOccurs="0" ref="postamble"/>
      </xs:sequence>
      <xs:attribute name="anchor" type="xs:ID"/>
      <xs:attribute name="title" default="" type="ATEXT"/>
    </xs:complexType>
  </xs:element>
  <xs:element name="preamble">
    <xs:complexType mixed="true">
      <xs:choice minOccurs="0" maxOccurs="unbounded">
        <xs:element ref="xref"/>
        <xs:element ref="eref"/>
        <xs:element ref="iref"/>
      </xs:choice>
    </xs:complexType>
  </xs:element>
  <xs:element name="artwork">
    <xs:complexType mixed="true">
      <xs:attribute ref="xml:space" default="preserve"/>
      <xs:attribute name="name" default="" type="ATEXT"/>
      <xs:attribute name="type" type="ATEXT"/>
      <xs:attribute name="src" type="URI"/>
      <xs:attribute name="width" type="ATEXT"/>
      <xs:attribute name="height" type="ATEXT"/>
    </xs:complexType>
  </xs:element>
  <xs:element name="postamble">
    <xs:complexType mixed="true">
      <xs:choice minOccurs="0" maxOccurs="unbounded">
        <xs:element ref="xref"/>
        <xs:element ref="eref"/>
        <xs:element ref="iref"/>
      </xs:choice>
    </xs:complexType>
  </xs:element>
  <xs:element name="texttable">
    <xs:complexType>
      <xs:sequence>
        <xs:element minOccurs="0" ref="preamble"/>
        <xs:element maxOccurs="unbounded" ref="ttcol"/>
        <xs:element minOccurs="0" maxOccurs="unbounded" ref="c"/>
        <xs:element minOccurs="0" ref="postamble"/>
      </xs:sequence>
      <xs:attribute name="anchor" type="xs:ID"/>
      <xs:attribute name="title" default="" type="ATEXT"/>
    </xs:complexType>
  </xs:element>
  <xs:element name="ttcol">
    <xs:complexType mixed="true">
      <xs:attribute name="width" type="ATEXT"/>
      <xs:attribute name="align" default="left">
        <xs:simpleType>
          <xs:restriction base="xs:token">
            <xs:enumeration value="left"/>
            <xs:enumeration value="center"/>
            <xs:enumeration value="right"/>
          </xs:restriction>
        </xs:simpleType>
      </xs:attribute>
    </xs:complexType>
  </xs:element>
  <xs:element name="c">
    <xs:complexType mixed="true">
      <xs:choice minOccurs="0" maxOccurs="unbounded">
        <xs:element ref="xref"/>
        <xs:element ref="eref"/>
        <xs:element ref="iref"/>
      </xs:choice>
    </xs:complexType>
  </xs:element>
  <!-- Back matter -->
  <!-- sections, if present, are appendices -->
  <xs:element name="back">
    <xs:complexType>
      <xs:sequence>
        <xs:element minOccurs="0" maxOccurs="unbounded" ref="references"/>
        <xs:element minOccurs="0" maxOccurs="unbounded" ref="section"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="references">
    <xs:complexType>
      <xs:sequence>
        <xs:element maxOccurs="unbounded" ref="reference"/>
      </xs:sequence>
      <xs:attribute name="title" default="References" type="ATEXT"/>
    </xs:complexType>
  </xs:element>
  <xs:element name="reference">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="front"/>
        <xs:element minOccurs="0" maxOccurs="unbounded" ref="seriesInfo"/>
        <xs:element minOccurs="0" maxOccurs="unbounded" ref="format"/>
        <xs:element minOccurs="0" maxOccurs="unbounded" ref="annotation"/>
      </xs:sequence>
      <xs:attribute name="anchor" type="xs:ID"/>
      <xs:attribute name="target" type="URI"/>
    </xs:complexType>
  </xs:element>
  <xs:element name="seriesInfo">
    <xs:complexType>
      <xs:attribute name="name" use="required" type="ATEXT"/>
      <xs:attribute name="value" use="required" type="ATEXT"/>
    </xs:complexType>
  </xs:element>
  <xs:element name="format">
    <xs:complexType>
      <xs:attribute name="target" type="URI"/>
      <xs:attribute name="type" use="required" type="ATEXT"/>
      <xs:attribute name="octets" type="NUMBER"/>
    </xs:complexType>
  </xs:element>
  <xs:element name="annotation">
    <xs:complexType mixed="true">
      <xs:choice minOccurs="0" maxOccurs="unbounded">
        <xs:element ref="xref"/>
        <xs:element ref="eref"/>
        <xs:element ref="iref"/>
      </xs:choice>
    </xs:complexType>
  </xs:element>
</xs:schema>

--------------030003050405000503090808--