[xml2rfc] Some additional comments on xml2rfc features

fenner at research.att.com (Bill Fenner) Thu, 04 May 2006 09:22 UTC

From: "fenner at research.att.com"
Date: Thu, 04 May 2006 09:22:41 +0000
Subject: [xml2rfc] Some additional comments on xml2rfc features
Message-ID: <200605041622.k44GMY30013954@bright.research.att.com>
X-Date: Thu May 4 09:22:41 2006

Julian,

  Bob Braden from the RFC Editor said that the leader format is an
accident of the tools they're using, not an express preference.
That is, they didn't change to "..." because that's the required
RFC style; they change because that's the format that the ToC-
generation tool they use generates.

  (They still do some of the final editing in nroff, so sometimes
have to replace the xml2rfc-generated ToC.)

  Bill
>From julian at mehnle.net  Thu May  4 17:56:11 2006
From: julian at mehnle.net (Julian Mehnle)
Date: Thu May  4 09:56:23 2006
Subject: [xml2rfc] Re: Some additional comments on xml2rfc features
In-Reply-To: <200605041622.k44GMY30013954@bright.research.att.com>
References: <200605041622.k44GMY30013954@bright.research.att.com>
Message-ID: <200605041656.12475.julian@mehnle.net>

Bill Fenner wrote:
>   Bob Braden from the RFC Editor said that the leader format is an
> accident of the tools they're using, not an express preference.
> That is, they didn't change to "..." because that's the required
> RFC style; they change because that's the format that the ToC-
> generation tool they use generates.
>
>   (They still do some of the final editing in nroff, so sometimes
> have to replace the xml2rfc-generated ToC.)

Thanks for the explanation!

As an aside note, I happen to like the "......" leader better than 
the ". . . . " one.  Maybe it would still be worth to make this confi- 
gurable, if not to be able to reproduce the RFC Editor's (involuntary) 
style?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060504/e5b3458c/attachment.bin
>From julian at mehnle.net  Sat May  6 20:26:23 2006
From: julian at mehnle.net (Julian Mehnle)
Date: Sat May  6 12:26:37 2006
Subject: [xml2rfc] 
	Re: "error: with content model", or how to insert a <note> before
	the <abstract>?
In-Reply-To: <200605012306.44369.julian@mehnle.net>
References: <200605012306.44369.julian@mehnle.net>
Message-ID: <200605061926.25194.julian@mehnle.net>

Julian Mehnle wrote:
> I'm trying to update the XML source of the recently released SPF RFC
> (RFC 4408) with the RFC Ed's and the AUTH48 changes.  The IESG had an
> "IESG Note" inserted in the RFC, however it was inserted _before_ the
> abstract.
>
> Using xml2rfc 1.31pre5 I thus get the following error:
> | xml2rfc: error: with content model {title {} author + date {} area *
> | workgroup * keyword * abstract ? note *} for <front>, seen {title
> | author author date workgroup note} so far, now expecting <note> or
> | </front>, but not <abstract> around input line 133 in
> | "internally-preprocessed XML"
>
> How do I get the <note> element in front of the <abstract> element?  I
> think xml2rfc's content model will have to be adjusted to allow for what
> the IESG and the RFC Editor have done with RFC 4408.

Should I consider myself warnocked on this one? :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060506/a8e5c8f5/attachment.bin
>From fenner at gmail.com  Sat May  6 15:04:26 2006
From: fenner at gmail.com (Bill Fenner)
Date: Sat May  6 14:04:35 2006
Subject: [xml2rfc] Re: "error: with content model", or how to insert a
	<note> before the <abstract>?
In-Reply-To: <200605061926.25194.julian@mehnle.net>
References: <200605012306.44369.julian@mehnle.net>
	 <200605061926.25194.julian@mehnle.net>
Message-ID: <ed6d469d0605061404i15deb200r27f4c776ceee9715@mail.gmail.com>

Sorry for contributing to your warnockification.

You're right that the content model would need to be adjusted [or the
formatters would need to change to insert <note> elements before the
abstract, possibly changing the formatting of existing documents
negatively].

I don't know if the RFC 2629 design overlooked that most IESG Notes
are edited in before the Abstract, anticipated a change in behavior
that didn't occur, intended something other than current formatters
omit, or something else.  The obvious content model change would be
note* abstract? note*, to allow explicit placement of notes before or
after the abstract.

[I grepped through RFCs from 2000 thru 4xxx, and found that most IESG
notes were before the abstract but some were after.]

  Bill