[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
MIB template issues
Hi,
The new xml2rfc was not meant to permit putting appendices before the
references, as the mail below shows, even though it worked for my
template using the experimental revision in some cases, and was
considered valid against the DTD by XMLSpy. Oh well.
The RFC Editor doesn't *require* appendices before the references, and
putting them before the references causes some problems with xml2rfc.
I don't want to waste my political capital fighting that battle.
David Harrington
dbharrington@comcast.net
-----Original Message-----
From: xml2rfc-bounces@dbc.mtview.ca.us
[mailto:xml2rfc-bounces@dbc.mtview.ca.us] On Behalf Of Charles Levert
Sent: Thursday, September 29, 2005 5:28 AM
To: xml2rfc@lists.xml.resource.org
Subject: Re: living on the edge [xml2rfc]
Hi.
* On Wednesday 2005-09-28 at 13:17:20 -0400, David B Harrington wrote:
>
> I found two anomalies:
> 1) if strict=="yes", xml2rfc complains about finding <references> at
a
> line number that actually has the </back> tag on it. (and
<references>
> actually has a number of appendices between it and <back>
There is an actual error to be reported here,
but it's just being badly reported.
>From the DTD, the content model for the <back>
element is <section>s, then <references>s.
You have them backward, so that's the error
to be reported. To validate against the DTD,
your input XML document has to be corrected in
this regard. (This has no bearing on which
per-element-type group is placed before the
other in the output; it's just the input model.)
However, the problem in the way the error is
reported is that one stack frame is missing when
the line number part of the message is generated,
so the next one (for <back>) is used instead.
Note that it's the line number of the start tag
<back>, not that of the end tag </back> that is
reported when I try it. At any rate, this is a
(minor) bug and I will look at what can be done
to fix it.
> 2) appendices can now be inserted before <references>, but
references
> still get numbered. In 2223bis, the references are not numbered
> (although section 7.4f seems to indicate numbering.
The order in which they are inserted in the
output seems to be consistent in recently
published RFCs: after regular sections and
before appendixes. So this is what xml2rfc
does as well. If they are to be numbered,
the numbering can just continue from that of
the regular sections just before them.
I can see that for its own purposes,
draft-rfc-editor-rfc2223bis-08 puts them after
its own appendixes, but in practice this seems
to be the exception, despite the recommendation
in Section 4.7e. It's clear that they can't
really be numbered when they are placed there.
(What goes after A, B, C, ...?)
The decision for xml2rfc is to just numbers them,
creating subsections for many <references>s
elements if need be. This isn't done in all
recently published RFCs, but it's done fairly
often and seems to be accepted by the RFC Editor
so it's probably worth sticking with until/unless
it gets prohibited.
_______________________________________________
xml2rfc mailing list
xml2rfc@lists.xml.resource.org
http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc