Subject: [xml2rfc] includes?
From: [email-masked] (Marshall Rose)
Date: Mon, 29 Sep 2003 08:58:38 -0700

> I am using the webinterface again to convert a .xml file\into a internet
> draft.
> 
> I Use
>    <?rfc include='reference.RFC.3033.xml'?>
> 
> ANd it causes error:
> 
>    title element needs an abbrev attribute around line 109
> ...

i was unable to reproduce this. please send me the input file you are using.

/mtr

From: [email-masked] (Wijnen, Bert (Bert))
Date: Mon, 29 Sep 2003 15:40:05 +0200
Subject: [xml2rfc] includes?
Message-ID: <[email-masked]>

I am using the webinterface again to convert a .xml file\into a internet draft.

I Use
   <?rfc include='reference.RFC.3033.xml'?>

ANd it causes error:

   title element needs an abbrev attribute around line 109

   Context: 
    <rfc ipr="full2026" docName="draft-bwijnen-mpls-status-00.txt" category="std">
    <middle>
    <section title="Current RFCs and status">
    <figure>
    <artwork>
    <reference anchor="RFC3033">

I would suspect we may get quite a few of those?
Is anyone checking into this to fix those include file?

Thanks,
Bert 

From: [email-masked] (Wijnen, Bert (Bert))
Date: Tue, 23 Sep 2003 10:13:20 +0200
Subject: [xml2rfc] two wish-list items
Message-ID: <[email-masked]>

> > WOuld it be possible to update the web-based service interface
> > to do the following:
> > 
> > - keep the source file name in the "input" field when an error
> >   occurs? In fact the filename stays there if you succeed,
> >   but when you get an error it gets blanked out.... while
> >   at that time you probably want to fix something and resubmit!
>     
> when i get an error, i hit the back button on my browser and 
> i get back the page with the filename still there...
>     
Guess I could/should havethought about that myself.
At the other hand, since you DO put it there when there are
no errors ??? 
>     
> > - when you get the result and you have specified to save the 
> >   file, would it be possible to have the filename be set to the
> >   filename that one has specified in the docName attribute?
> >   This instead of using the filename of the input file?
> 
> the cgi script dosn't parse the file, it just runs xml2rfc. so, doing
> this would be hard. is there a reason why you don't want the input and
> output files to be the same except for the suffix...
>     
I use a very short (local) filename for XML that I edit.
The generated name I prefer to be the ID.
I can deal with it.. so forget it since it seem to be hard.

Bert
> /mtr
> 

From: [email-masked] (Marshall Rose)
Date: Mon, 22 Sep 2003 20:48:54 -0700
Subject: [xml2rfc] two wish-list items
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> WOuld it be possible to update the web-based service interface
> to do the following:
> 
> - keep the source file name in the "input" field when an error
>   occurs? In fact the filename stays there if you succeed,
>   but when you get an error it gets blanked out.... while
>   at that time you probably want to fix something and resubmit!
    
when i get an error, i hit the back button on my browser and i get back
the page with the filename still there...

> - when you get the result and you have specified to save the 
>   file, would it be possible to have the filename be set to the
>   filename that one has specified in the docName attribute?
>   This instead of using the filename of the input file?

the cgi script dosn't parse the file, it just runs xml2rfc. so, doing
this would be hard. is there a reason why you don't want the input and
output files to be the same except for the suffix...
    
/mtr

From: [email-masked] (Alex Rousskov)
Date: Mon, 22 Sep 2003 08:56:39 -0600 (MDT)
Subject: [xml2rfc] feature request: artwork.trimspace=yes
Message-ID: <[email-masked]>

RFC parts, sections, figures, etc. lead to natural indentation of raw
XML text we edit:

    <rfc>
        <middle>
            <section>
                <section>
		    ...
                </section>
            <section>
        </middle>
    </rfc>

When the inner section has embedded artwork, I have to use different
indentation so that rendered output looks nice:

    <rfc>
        <middle>
            <section>
                <section>
                    <artwork>
    GET / HTTP/1.1
    Accept: ...
    Whatever: ...
                    <artwork>
                </section>
            <section>
        </middle>
    </rfc>

When there are many small artwork-ed examples in the text, the natural
indentation gets lost in the artwork noise. I also often have to
manually avoid whitespace between artwork opening tag and the
example itself, creating hard-to-read raw example text:

    <rfc>
        <middle>
            <section>
                <section>
                    <artwork><![CDATA[GET / HTTP/1.1
    Accept: ...
    Whatever: ...]]></artwork>
                </section>
            <section>
        </middle>
    </rfc>

Assuming there is no existing xml2rfc or native XML trick I am
missing, I would suggest adding "trimspace", an optional parameter of
the artwork element. If "trimspace" is set to "yes", xml2rfc will
delete before further processing:

    - head: whitespace between <artwork> and first end-of-line
	    including the end-of-line marker
    - tail: whitespace between the last non-whitespace character
            of the artwork and </artwork>
    - body: indentation whitespace in front of all artwork lines(*)

Where indentation size in (*) is defined as the minimum number of
whitespace characters among all artwork lines, after head and tail
trimming has been performed. I had this feature implemented in a
custom pre-xml2rfc formatting tool, and it was very handy for
preserving natural text layout in XML sources:

    <rfc>
        <middle>
            <section>
                <section>
                    <artwork trimspace="yes">
                        GET / HTTP/1.1
                        Accept: ...
                        Whatever: ...
                    <artwork>
                </section>
            <section>
        </middle>
    </rfc>

The feature defaults to "no" so that existing spec sources are not
affected.

Thank you,

Alex.

P.S. An existing "solution" is not use include files, but that is
     too much work when dealing with small inlined examples. It
     makes reading and editing raw text difficult as well because
     one cannot see the included examples until compile time...

From: [email-masked] (Julian Reschke)
Date: Mon, 22 Sep 2003 16:52:27 +0200
Subject: [xml2rfc] refreences within a <figure><artwork>
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Sure.

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

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Alex Rousskov
> Sent: Monday, September 22, 2003 4:31 PM
> To: Julian Reschke
> Cc: Wijnen, Bert (Bert); Xml2rfc (E-mail)
> Subject: RE: [xml2rfc] refreences within a <figure><artwork>
> 
> 
> 
> I stand corrected, then! The facts you mentioned may also explain why
> Bert is not getting the intended formatting. I wonder if HTML's <pre>
> element also assumes "plain text content without child elements".
> 
> Alex.
> 
> 
> On Mon, 22 Sep 2003, Julian Reschke wrote:
> 
> > > From: [email-masked]
> > > [mailto:[email-masked]]On Behalf Of 
> Alex Rousskov
> > > Sent: Monday, September 22, 2003 3:58 PM
> > > To: Julian Reschke
> > > Cc: Wijnen, Bert (Bert); Xml2rfc (E-mail)
> > > Subject: RE: [xml2rfc] refreences within a <figure><artwork>
> > >
> > >
> > > On Mon, 22 Sep 2003, Julian Reschke wrote:
> > >
> > > > are you saying that xref elements in artwork get resolved? That
> > > would be a
> > > > bug in xml2rfc. It's supposed to be plain text.
> > >
> > > My understanding is that artwork does not imply CDATA. Artwork alone
> >
> > However, artwork implies plain text content, and doesn't allow child
> > elements. Thus, this is a validity issue (that should be catched by a
> > validating XML parser).
> >
> > > protects whitespace formatting only. CDATA protects everything, and
> > > can be used within artwork. The availability of the two options (bare
> > > artwork and artwork+CDATA) is the "right thing" to support, IMO.
> >
> > Yes, but that's not what RFC2629 and it's DTD currently define.
> >
> > > This may clarify why references get resolved, but does not answer
> > > Bert's original question, of course.
> >
> > Julian
> >
> > --
> > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> >
> > _______________________________________________
> > xml2rfc mailing list
> > [email-masked]
> > http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> >
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

From: [email-masked] (Alex Rousskov)
Date: Mon, 22 Sep 2003 08:30:31 -0600 (MDT)
Subject: [xml2rfc] refreences within a <figure><artwork>
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

I stand corrected, then! The facts you mentioned may also explain why
Bert is not getting the intended formatting. I wonder if HTML's <pre>
element also assumes "plain text content without child elements".

Alex.

On Mon, 22 Sep 2003, Julian Reschke wrote:

> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Alex Rousskov
> > Sent: Monday, September 22, 2003 3:58 PM
> > To: Julian Reschke
> > Cc: Wijnen, Bert (Bert); Xml2rfc (E-mail)
> > Subject: RE: [xml2rfc] refreences within a <figure><artwork>
> >
> >
> > On Mon, 22 Sep 2003, Julian Reschke wrote:
> >
> > > are you saying that xref elements in artwork get resolved? That
> > would be a
> > > bug in xml2rfc. It's supposed to be plain text.
> >
> > My understanding is that artwork does not imply CDATA. Artwork alone
>
> However, artwork implies plain text content, and doesn't allow child
> elements. Thus, this is a validity issue (that should be catched by a
> validating XML parser).
>
> > protects whitespace formatting only. CDATA protects everything, and
> > can be used within artwork. The availability of the two options (bare
> > artwork and artwork+CDATA) is the "right thing" to support, IMO.
>
> Yes, but that's not what RFC2629 and it's DTD currently define.
>
> > This may clarify why references get resolved, but does not answer
> > Bert's original question, of course.
>
> 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, 22 Sep 2003 16:15:30 +0200
Subject: [xml2rfc] refreences within a <figure><artwork>
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Alex Rousskov
> Sent: Monday, September 22, 2003 3:58 PM
> To: Julian Reschke
> Cc: Wijnen, Bert (Bert); Xml2rfc (E-mail)
> Subject: RE: [xml2rfc] refreences within a <figure><artwork>
>
>
> On Mon, 22 Sep 2003, Julian Reschke wrote:
>
> > are you saying that xref elements in artwork get resolved? That
> would be a
> > bug in xml2rfc. It's supposed to be plain text.
>
> My understanding is that artwork does not imply CDATA. Artwork alone

However, artwork implies plain text content, and doesn't allow child
elements. Thus, this is a validity issue (that should be catched by a
validating XML parser).

> protects whitespace formatting only. CDATA protects everything, and
> can be used within artwork. The availability of the two options (bare
> artwork and artwork+CDATA) is the "right thing" to support, IMO.

Yes, but that's not what RFC2629 and it's DTD currently define.

> This may clarify why references get resolved, but does not answer
> Bert's original question, of course.

Julian

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

From: [email-masked] (Alex Rousskov)
Date: Mon, 22 Sep 2003 07:57:58 -0600 (MDT)
Subject: [xml2rfc] refreences within a <figure><artwork>
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 22 Sep 2003, Julian Reschke wrote:

> are you saying that xref elements in artwork get resolved? That would be a
> bug in xml2rfc. It's supposed to be plain text.

My understanding is that artwork does not imply CDATA. Artwork alone
protects whitespace formatting only. CDATA protects everything, and
can be used within artwork. The availability of the two options (bare
artwork and artwork+CDATA) is the "right thing" to support, IMO.

This may clarify why references get resolved, but does not answer
Bert's original question, of course.

Alex.

From: [email-masked] (Wijnen, Bert (Bert))
Date: Mon, 22 Sep 2003 15:29:13 +0200
Subject: [xml2rfc] refreences within a <figure><artwork>
Message-ID: <[email-masked]>

for all I could tell, yes they did get resolved. But the text (reference)
was put on a separate line by itself, followed by yet another blank line.
I wanted them to be inline.

Thanks,
Bert 

> -----Original Message-----
> From: Julian Reschke [mailto:[email-masked]]
> Sent: maandag 22 september 2003 15:21
> To: Wijnen, Bert (Bert); Xml2rfc (E-mail)
> Subject: RE: [xml2rfc] refreences within a <figure><artwork>
> 
> 
> Bert,
> 
> are you saying that xref elements in artwork get resolved? 
> That would be a
> bug in xml2rfc. It's supposed to be plain text.
> 
> Julian
> 
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of 
> Wijnen, Bert
> > (Bert)
> > Sent: Monday, September 22, 2003 1:10 PM
> > To: Xml2rfc (E-mail)
> > Subject: [xml2rfc] refreences within a <figure><artwork>
> >
> >
> > I have:
> >
> >   <figure>
> >     <artwork>
> >     0   rmonEventsV2          Notifications root      <xref
> > target="RFC2819"/>
> >     1   statistics            OID                     <xref
> > target="RFC2819"/>
> >
> >     </artwork>
> >   </figure>
> >
> > The result is that all the references get created on a new 
> line by itself.
> > Would it be too difficult to keep them on same line  (it 
> fits within the
> > 72 column limit even).
> >
> > Thanks,
> > Bert
> > _______________________________________________
> > xml2rfc mailing list
> > [email-masked]
> > http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> >
> 

From: [email-masked] (Julian Reschke)
Date: Mon, 22 Sep 2003 15:20:51 +0200
Subject: [xml2rfc] refreences within a <figure><artwork>
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Bert,

are you saying that xref elements in artwork get resolved? That would be a
bug in xml2rfc. It's supposed to be plain text.

Julian

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

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Wijnen, Bert
> (Bert)
> Sent: Monday, September 22, 2003 1:10 PM
> To: Xml2rfc (E-mail)
> Subject: [xml2rfc] refreences within a <figure><artwork>
>
>
> I have:
>
>   <figure>
>     <artwork>
>     0   rmonEventsV2          Notifications root      <xref
> target="RFC2819"/>
>     1   statistics            OID                     <xref
> target="RFC2819"/>
>
>     </artwork>
>   </figure>
>
> The result is that all the references get created on a new line by itself.
> Would it be too difficult to keep them on same line  (it fits within the
> 72 column limit even).
>
> Thanks,
> Bert
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>

From: [email-masked] (Wijnen, Bert (Bert))
Date: Mon, 22 Sep 2003 13:09:54 +0200
Subject: [xml2rfc] refreences within a <figure><artwork>
Message-ID: <[email-masked]>

I have:

  <figure>
    <artwork>
    0   rmonEventsV2          Notifications root      <xref target="RFC2819"/>
    1   statistics            OID                     <xref target="RFC2819"/>

    </artwork>
  </figure>

The result is that all the references get created on a new line by itself.
Would it be too difficult to keep them on same line  (it fits within the
72 column limit even).

Thanks,
Bert 

From: [email-masked] (Wijnen, Bert (Bert))
Date: Mon, 22 Sep 2003 11:42:49 +0200
Subject: [xml2rfc] two wish-list items
Message-ID: <[email-masked]>

WOuld it be possible to update the web-based service interface
to do the following:

- keep the source file name in the "input" field when an error
  occurs? In fact the filename stays there if you succeed,
  but when you get an error it gets blanked out.... while
  at that time you probably want to fix something and resubmit!
- when you get the result and you have specified to save the 
  file, would it be possible to have the filename be set to the
  filename that one has specified in the docName attribute?
  This instead of using the filename of the input file?

Thanks,
Bert 

From: [email-masked] (Wijnen, Bert (Bert))
Date: Mon, 22 Sep 2003 00:00:04 +0200
Subject: [xml2rfc] Help please
Message-ID: <[email-masked]>

OK, I found it. It was in my title element.
I must say that (line 25 was not poiting tot title element)
the error message did not help much. It caused me to play with
the rfc attributes, cause that seemed wrong to me based on
the error message.

Anyway... forward we go. 
Thanks,
Bert 

> -----Original Message-----
> From: Marshall Rose [mailto:[email-masked]]
> Sent: zondag 21 september 2003 23:34
> To: Wijnen, Bert (Bert)
> Cc: Xml2rfc (E-mail)
> Subject: Re: [xml2rfc] Help please
> 
> 
> > And when I try to check it online, I get 
> >    Unable to Convert File
> >    unexpected end of attribute list around line 20
> > 
> >    Context: 
> >     <rfc ipr="full2026"
> >     docName="draft-ietf-rmonmib-rmon-oid-assignments-00.txt"
> >     category="std"><front>
> > 
> > But I do not see whT is wrong here?
> 
> the two things to note:
>     
>     1. it says *around* line 20
>     
>     2. it says that the context is inside the <front> element
>     
> so, if think if you look at the elements right after the 
> <front> you'll
> see where the problem is...
>     
> /mtr
>     
> 

From: [email-masked] (Marshall Rose)
Date: Sun, 21 Sep 2003 14:34:11 -0700
Subject: [xml2rfc] Help please
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> And when I try to check it online, I get 
>    Unable to Convert File
>    unexpected end of attribute list around line 20
> 
>    Context: 
>     <rfc ipr="full2026"
>     docName="draft-ietf-rmonmib-rmon-oid-assignments-00.txt"
>     category="std"><front>
> 
> But I do not see whT is wrong here?

the two things to note:
    
    1. it says *around* line 20
    
    2. it says that the context is inside the <front> element
    
so, if think if you look at the elements right after the <front> you'll
see where the problem is...
    
/mtr

From: [email-masked] (Wijnen, Bert (Bert))
Date: Sun, 21 Sep 2003 22:27:31 +0200
Subject: [xml2rfc] Help please
Message-ID: <[email-masked]>

Not sure what I am doing wrong (maybe it is just too late and
I should look with fresh eyes tomorrow.

I have:
<?xml version="1.0" ?>
<!DOCTYPE rfc SYSTEM "rfc2629bis.dtd"
 [
  <!ENTITY rfc2434 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2434.xml'>
  <!ENTITY rfc2021 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2021.xml'>
 ]>

<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<?rfc toc="yes" ?>

<rfc ipr="full2026"
     docName="draft-ietf-rmonmib-rmon-oid-assignments-00.txt"
     category="std"
>

<front>

And when I try to check it online, I get 
   Unable to Convert File
   unexpected end of attribute list around line 20

   Context: 
    <rfc ipr="full2026" docName="draft-ietf-rmonmib-rmon-oid-assignments-00.txt" category="std">
    <front>

But I do not see whT is wrong here?

Thanks,
Bert 

From: [email-masked] (Alex Rousskov)
Date: Sat, 20 Sep 2003 08:33:53 -0600 (MDT)
Subject: [xml2rfc] xml2rfc thoughts
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Wes,

	What you want is supported in XML via external and internal
entities. Xml2rfc supports external entities (see web page or docs).
As for internal entities, you would need a preprocessor to expand
them. I posted a simple preprocessing script a few days ago, see the
end of the "internal entities" thread in the archives.

	You can also use rfc2xml-native "include"  processing
instruction, also an "external" approach.

HTH,

Alex.

On Fri, 19 Sep 2003, Wes Hardaker wrote:

>
> Food for thought: You know, with the amount of repeated text in RFCs
> these days, it would be handy to have xml2rfc help you out with this
> by letting you wrap a definition around some text segment and reuse it
> later.
>
> Something like:
>
>   <define anchor="blah">write some text</define>
>
> And later
>
>   <insert anchor="blah" />
>
> Or something like that.
>
> --
> Wes Hardaker
> Sparta

From: [email-masked] (Wes Hardaker)
Date: Fri, 19 Sep 2003 21:59:48 -0700
Subject: [xml2rfc] xml2rfc thoughts
Message-ID: <[email-masked]>

Food for thought: You know, with the amount of repeated text in RFCs
these days, it would be handy to have xml2rfc help you out with this
by letting you wrap a definition around some text segment and reuse it
later.

Something like: 

  <define anchor="blah">write some text</define>

And later

  <insert anchor="blah" />

Or something like that.

-- 
Wes Hardaker
Sparta

From: [email-masked] (Alex Rousskov)
Date: Wed, 17 Sep 2003 18:48:15 -0600 (MDT)
Subject: [xml2rfc] internal entities
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

--0-407906576-1063845676=:26365
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <[email-masked]>

Marshall,

	With your clarification, I think we can and should close the
issue of entities support in xml2rfc. Thank you!

	For mid-timers with similar needs, attached is a Perl script
to preprocess internal XML entities and include all referenced files
before XML is fed to xml2rfc. New-timers should use XSLT magic
instead, of course. See this thread for XSLT pointers from Julian
Reschke.

HTH,

Alex.

On Wed, 17 Sep 2003, Marshall Rose wrote:

> back in early 1999, when 2629 was being drafted, half-a-dozen
> "old-timers" from the rfc writing world were consulted. as a group,
> they had collectively authored a few thousand pages of rfcs at that
> time.
>
>     it was clear from the start, that xml was universally disliked.
> there were a whole series of arguments about the syntax. (my
> personal favorite: "do you really need closing tags".) after much
> discussion, it was clear that a minimalistic interpretation of all
> things xml would sell, because at that point, it comes down to
> whether we really needed to argue about what color to paint the
> outhouse, and, frankly, senior people have better things to argue
> about.
>
>     the xml parser that xml2rfc uses was written in 1999. the main
> reason i don't update it is because its a bare bones parser that
> does the absolute minimum. it keeps things honest.
>
>     to this day, the core audience for 2629 remains that old-timer
> demographic. if you consider the rather virulent reaction that
> occurs whenever someone says "xml and rfc" or "xml and i-d" on the
> ietf list, you can appreciate why...
>
> /mtr

--0-407906576-1063845676=:26365
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="xmlpp.pl"
Content-Transfer-Encoding: BASE64
Content-ID: <[email-masked]>
Content-Description: xmlpp.pl
Content-Disposition: ATTACHMENT; FILENAME="xmlpp.pl"

--0-407906576-1063845676=:26365--

From: [email-masked] (Marshall Rose)
Date: Wed, 17 Sep 2003 16:03:47 -0700
Subject: [xml2rfc] internal entities
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> I think we're confusing the format (as defined in rfc2629) and a specific
> application (xml2rfc). If you run your input through an rfc2629 processor
> that is based on a full-blown XML processor (such as transforming using
> rfc2629.xslt), there wouldn't be an issue.
> 
> So from my point of view this is just a restriction in a specific RFC2629
> processor, not a restriction of the format itself. 

a couple of things.
    
first, the confusion is mine: i didn't clearly state things to alex's
early message. oops, sorry!
    
your example wrt to rfc2629.xslt demonstrates that pretty clearly. thanks!

second, i think it's useful to reinforce carl's point about the
razor.
    
back in early 1999, when 2629 was being drafted, half-a-dozen
"old-timers" from the rfc writing world were consulted. as a group, they
had collectively authored a few thousand pages of rfcs at that time.
    
it was clear from the start, that xml was universally disliked. there
were a whole series of arguments about the syntax. (my personal
favorite: "do you really need closing tags".) after much discussion, it
was clear that a minimalistic interpretation of all things xml would
sell, because at that point, it comes down to whether we really needed
to argue about what color to paint the outhouse, and, frankly, senior
people have better things to argue about.
    
the xml parser that xml2rfc uses was written in 1999. the main reason i
don't update it is because its a bare bones parser that does the
absolute minimum. it keeps things honest.
    
to this day, the core audience for 2629 remains that old-timer
demographic. if you consider the rather virulent reaction that occurs
whenever someone says "xml and rfc" or "xml and i-d" on the ietf list,
you can appreciate why...
    
/mtr

From: [email-masked] (Alex Rousskov)
Date: Wed, 17 Sep 2003 16:09:08 -0600 (MDT)
Subject: [xml2rfc] internal entities
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 17 Sep 2003, Carl Malamud wrote:

> Adding internal entities is not going to make the rfc editor's life
> easier.

True. Internal entities are for authors. Using XML instead of plain
text is supposed to make editor's life easier (eventually). Since I
assume the editors are going to use xml2rfc, I want to make sure I can
give them XML they can use.

> Why don't you simply preprocess?  The end result is an xml file
> which can be used by xml2rfc or other tools.

Yes, preprocessing seems to be the consensus. External preprocessing
is awkward because I have <?rfc include> files and because I share
sources with other authors, but it seems to be the right thing to do
anyway.

> You could, of course, do a code fork and do the King James RFC2629
> and play with that for a while, but I've worked with Marshall for
> almost 20 years and I suspect you're not going to get him to
> reincarnate this particular horse.

The only kind of fork I can afford right now is a suicide weapon :-).
Trust me, if I knew it is a beaten horse issue, I would not ask the
question; but
	http://www.google.com/search?q=xml2rfc+%22internal+entit%22
yielded nothing...

Thanks everybody for comments and advice!

Alex.

From: [email-masked] (Carl Malamud)
Date: Wed, 17 Sep 2003 14:26:07 -0700 (PDT)
Subject: [xml2rfc] internal entities
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Alex -

Adding internal entities is not going to make the rfc editor's life
easier.  He/she/it wants simple straightforward xml that
can be read in a linear format.  E.g., internal entities
may make *your* life easier, but the rfc editor is going to
simply tell you "fix this" or "fix that" so there is little
or no benefit to them.  I may be wrong, of course, and
the editor is free to request this particular feature.

Why don't you simply preprocess?  The end result is an xml file
which can be used by xml2rfc or other tools.

It may not be ideal, but that is the way this particular
tool and format happens to be.  Any format requires design
choices, and these are the choices that Marshall made.
Again, the choices may or not be ideal, but there they are.

You could, of course, do a code fork and do the King James
RFC2629 and play with that for a while, but I've worked
with Marshall for almost 20 years and I suspect you're
not going to get him to reincarnate this particular horse.

Regards,

Carl

> 
> On Wed, 17 Sep 2003, Julian Reschke wrote:
> 
> > I think we're confusing the format (as defined in rfc2629) and a
> > specific application (xml2rfc). If you run your input through an
> > rfc2629 processor that is based on a full-blown XML processor (such
> > as transforming using rfc2629.xslt), there wouldn't be an issue.
> 
> Hmm.. Indeed, I cannot find any RFC 2629 text implying that internal
> entities are prohibited. DTD alone cannot prohibit them, right?
> However, that kind of contradicts Marshall's original response:
> 
> 	2629 limits you to a very small number of pre-defined
> 	entities, e.g.,"&amp;". bottom line: if you want the full
> 	glory of xml, you aren't going to be using 2629.
> 
> Marshall, did you mean to say "xml2rfc" instead of 2629 in the above?
> 
> > So from my point of view this is just a restriction in a specific
> > RFC2629 processor, not a restriction of the format itself.
> 
> ... but if Marshall disagrees or does not see enough value in
> supporting internal entities in xml2rfc, then I am still half-stuck
> because, I assume, RFC Editor is not going to accept XML that xml2rfc
> cannot handle. Making RFC Editor's life easier was one of the primary
> motivations for me to use rfc2629/xml2rfc combo!
> 
> Alex.
> 

From: [email-masked] (Alex Rousskov)
Date: Wed, 17 Sep 2003 15:11:21 -0600 (MDT)
Subject: [xml2rfc] internal entities
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 17 Sep 2003, Julian Reschke wrote:

> I think we're confusing the format (as defined in rfc2629) and a
> specific application (xml2rfc). If you run your input through an
> rfc2629 processor that is based on a full-blown XML processor (such
> as transforming using rfc2629.xslt), there wouldn't be an issue.

Hmm.. Indeed, I cannot find any RFC 2629 text implying that internal
entities are prohibited. DTD alone cannot prohibit them, right?
However, that kind of contradicts Marshall's original response:

	2629 limits you to a very small number of pre-defined
	entities, e.g.,"&amp;". bottom line: if you want the full
	glory of xml, you aren't going to be using 2629.

Marshall, did you mean to say "xml2rfc" instead of 2629 in the above?

> So from my point of view this is just a restriction in a specific
> RFC2629 processor, not a restriction of the format itself.

... but if Marshall disagrees or does not see enough value in
supporting internal entities in xml2rfc, then I am still half-stuck
because, I assume, RFC Editor is not going to accept XML that xml2rfc
cannot handle. Making RFC Editor's life easier was one of the primary
motivations for me to use rfc2629/xml2rfc combo!

Alex.

From: [email-masked] (Julian Reschke)
Date: Wed, 17 Sep 2003 22:59:08 +0200
Subject: [xml2rfc] internal entities
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Alex,

I think we're confusing the format (as defined in rfc2629) and a specific
application (xml2rfc). If you run your input through an rfc2629 processor
that is based on a full-blown XML processor (such as transforming using
rfc2629.xslt), there wouldn't be an issue.

So from my point of view this is just a restriction in a specific RFC2629
processor, not a restriction of the format itself.

Regards, Julian

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

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Alex Rousskov
> Sent: Wednesday, September 17, 2003 10:49 PM
> To: Carl Malamud
> Cc: [email-masked]
> Subject: Re: [xml2rfc] internal entities
>
>
> On Wed, 17 Sep 2003, Carl Malamud wrote:
>
> > Marshall and I had long talks about this when he was putting both
> > rfc2629 and beep together.
>
> First of all, I appreciate you sharing the rationale and background.
>
> > The problem with internal entities is the slippery slope issue. With
> > external entities, you do a simple include.  Very easy and
> > straightforward.  Internal entities are much more slippery and
> > indeterminate (e.g., your "constant" internal entity is one, but
> > then what about "html" entities and ....).
>
> I am not 100% sure what you mean by "html" entities, but I would say
> that no entities should be predefined except for those that are
> already "predefined" in rfc2629. Then, internal entities are no more
> complex or slippery than external ones, I guess.
>
> > The answer may or may not have been the correct one, but it was an
> > application of Occum's razor, along with some other simplifications,
> > that made XML a workable solution.
>
> Understood. From my point of view, the razor killed one of the most
> useful features of XML when it comes to editing technical documents,
> but I suspect that is just me, and I am sure it was not an easy
> decision to make!
>
>
> This simplification of XML is really interesting, IMHO. XML fans like
> to emphasize the eXtensible part. What you had to do is to _restrict_
> XML (to simplify writing of xml2rfc?). Did you have any input from W3C
> regarding this?  Any pages or e-mail archives left on the web? I
> wonder if the syntax that RFC 2629 is using can be even called XML
> from W3C XML working group point of view??
>
> Thank you,
>
> Alex.
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>

From: [email-masked] (Alex Rousskov)
Date: Wed, 17 Sep 2003 14:49:04 -0600 (MDT)
Subject: [xml2rfc] internal entities
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 17 Sep 2003, Carl Malamud wrote:

> Marshall and I had long talks about this when he was putting both
> rfc2629 and beep together.

First of all, I appreciate you sharing the rationale and background.

> The problem with internal entities is the slippery slope issue. With
> external entities, you do a simple include.  Very easy and
> straightforward.  Internal entities are much more slippery and
> indeterminate (e.g., your "constant" internal entity is one, but
> then what about "html" entities and ....).

I am not 100% sure what you mean by "html" entities, but I would say
that no entities should be predefined except for those that are
already "predefined" in rfc2629. Then, internal entities are no more
complex or slippery than external ones, I guess.

> The answer may or may not have been the correct one, but it was an
> application of Occum's razor, along with some other simplifications,
> that made XML a workable solution.

Understood. From my point of view, the razor killed one of the most
useful features of XML when it comes to editing technical documents,
but I suspect that is just me, and I am sure it was not an easy
decision to make!

This simplification of XML is really interesting, IMHO. XML fans like
to emphasize the eXtensible part. What you had to do is to _restrict_
XML (to simplify writing of xml2rfc?). Did you have any input from W3C
regarding this?  Any pages or e-mail archives left on the web? I
wonder if the syntax that RFC 2629 is using can be even called XML
from W3C XML working group point of view??

Thank you,

Alex.

From: [email-masked] (Carl Malamud)
Date: Wed, 17 Sep 2003 13:09:21 -0700 (PDT)
Subject: [xml2rfc] internal entities
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> 
> 
> Now, I am sure I am missing something important, but I find it strange
> that _external_ entities are supported/documented and (much simpler?)
> internal entities are not supported. What is the rationale?
> 

Hi Alex -

Marshall and I had long talks about this when he was putting both
rfc2629 and beep together.

The problem with internal entities is the slippery slope issue.
With external entities, you do a simple include.  Very easy
and straightforward.   Internal entities are much more slippery
and indeterminate (e.g., your "constant" internal entity is one,
but then what about "html" entities and ....).

The answer may or may not have been the correct one, but it was
an application of Occum's razor, along with some other 
simplifications, that made XML a workable solution.

So, if you want the full glory of XML, Docbook gives you that.
If you want a simple XML tool for producing RFCs, I'm afraid you have
to do some preprocessing in the form of state-of-the-art tools
like XSLT or state-of-the arc tools like sed.

Regards,

Carl

From: [email-masked] (Julian Reschke)
Date: Wed, 17 Sep 2003 21:35:57 +0200
Subject: [xml2rfc] internal entities
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Alex Rousskov
> Sent: Wednesday, September 17, 2003 9:24 PM
> To: [email-masked]
> Subject: RE: [xml2rfc] internal entities
>
>
>
> On Wed, 17 Sep 2003, Julian Reschke wrote:
>
> > Why don't you just run your input file through an "identity" XSLT
> > transformation which will in fact replaces all entities by their
> > replacement texts?
>
> Julian,
>
> 	Isn't this the same, in principle, as the "script" solution I
> described (the one I am trying to avoid!). Of course, if I get some
> simple tool that will do an identity XSLT transformation in my
> environment, then I do not have to write a script. Thus, your advice
> _is_ helpful, but would I not suffer from the same problems I
> mentioned below?
>
> > > 	- XML files include other XML files by filename
> > > 	  so I would either have to preprocess those filenames
> > > 	  as well OR use post-preprocessor filenames in sources
> > >
> > > 	- makes sharing XML sources more difficult because
> > > 	  I would have to share the script as well
>
> Or is there some X* magic I am missing here?

Yes and no (I think).

Unless you're speaking of XInclude, running the document through XSLT will
resolve *all* references, to if your source includes another file through
external entities, this will included as well.

And no, this doesn't solve the sharing issue.

Anyway, the XSLT identity transform can be found here:

<http://www.w3.org/TR/xslt#copying>

Julian

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

From: [email-masked] (Alex Rousskov)
Date: Wed, 17 Sep 2003 13:23:57 -0600 (MDT)
Subject: [xml2rfc] internal entities
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 17 Sep 2003, Julian Reschke wrote:

> Why don't you just run your input file through an "identity" XSLT
> transformation which will in fact replaces all entities by their
> replacement texts?

Julian,

	Isn't this the same, in principle, as the "script" solution I
described (the one I am trying to avoid!). Of course, if I get some
simple tool that will do an identity XSLT transformation in my
environment, then I do not have to write a script. Thus, your advice
_is_ helpful, but would I not suffer from the same problems I
mentioned below?

> > 	- XML files include other XML files by filename
> > 	  so I would either have to preprocess those filenames
> > 	  as well OR use post-preprocessor filenames in sources
> >
> > 	- makes sharing XML sources more difficult because
> > 	  I would have to share the script as well

Or is there some X* magic I am missing here?

Thank you,

Alex.

From: [email-masked] (Julian Reschke)
Date: Wed, 17 Sep 2003 20:06:08 +0200
Subject: [xml2rfc] internal entities
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Why don't you just run your input file through an "identity" XSLT
transformation which will in fact replaces all entities by their replacement
texts?

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

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Alex Rousskov
> Sent: Wednesday, September 17, 2003 7:47 PM
> To: [email-masked]
> Subject: Re: [xml2rfc] internal entities
>
>
>
> On Wed, 17 Sep 2003, Marshall Rose wrote:
>
> > > Are internal entities supported?
> >
> > no. further, 2629 limits you to a very small number of pre-defined
> > entities, e.g.,"&amp;".
> >
> > bottom line: if you want the full glory of xml, you aren't going to
> > be using 2629.
>
> Let's ignore RFC 2629 compliance for a second -- I believe xml2rfc
> already supports features not mentioned in RFC 2629. Let's focus on
> xml2rfc abilities. When/if RFC 2629 is refined, useful xml2rfc
> features may be included.
>
>
> Now, I am sure I am missing something important, but I find it strange
> that _external_ entities are supported/documented and (much simpler?)
> internal entities are not supported. What is the rationale?
>
> Please let me give you a specific use case. I hope it is common enough
> to deserve your consideration: I need named constants. I want to name
> a short piece of text and use that name repeatedly in the
> specification. I want xml2rfc to complain when a used name is not
> defined.
>
> This feature would be very useful for things like command names in
> protocol specs. In new specs, command names change often but it is a
> painful and error-prone process to rename a command because you have
> to search for command name in the text (which can be split across
> several files, can match English words, etc.). I want the interpreter
> to tell me when I left a now-undefined old command behind.
>
> 	<artwork>
> 		&PING; 1 2 3;
> 		&PUSH; 1.2.3;
> 	</artwork>
>
> As an added bonus, it might make auto-indexing of commands simple --
> just add an index-entry-generating element into the entity
> definition!
>
> Are there any better solutions than XML entities?
>
> Without modifying xml2rfc, I can only think of preprocessing XML
> files with a custom script. However, this is not trivial because
>
> 	- XML files include other XML files by filename
> 	  so I would either have to preprocess those filenames
> 	  as well OR use post-preprocessor filenames in sources
>
> 	- makes sharing XML sources more difficult because
> 	  I would have to share the script as well
>
> Am I overlooking a better solution?
>
> Thank you,
>
> Alex.
>
> --
>                             | HTTP performance - Web Polygraph benchmark
> www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
>                             | all of the above - PolyBox appliance
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>

From: [email-masked] (Alex Rousskov)
Date: Wed, 17 Sep 2003 11:47:18 -0600 (MDT)
Subject: [xml2rfc] internal entities
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 17 Sep 2003, Marshall Rose wrote:

> > Are internal entities supported?
>
> no. further, 2629 limits you to a very small number of pre-defined
> entities, e.g.,"&amp;".
>
> bottom line: if you want the full glory of xml, you aren't going to
> be using 2629.

Let's ignore RFC 2629 compliance for a second -- I believe xml2rfc
already supports features not mentioned in RFC 2629. Let's focus on
xml2rfc abilities. When/if RFC 2629 is refined, useful xml2rfc
features may be included.

Now, I am sure I am missing something important, but I find it strange
that _external_ entities are supported/documented and (much simpler?)
internal entities are not supported. What is the rationale?

Please let me give you a specific use case. I hope it is common enough
to deserve your consideration: I need named constants. I want to name
a short piece of text and use that name repeatedly in the
specification. I want xml2rfc to complain when a used name is not
defined.

This feature would be very useful for things like command names in
protocol specs. In new specs, command names change often but it is a
painful and error-prone process to rename a command because you have
to search for command name in the text (which can be split across
several files, can match English words, etc.). I want the interpreter
to tell me when I left a now-undefined old command behind.

	<artwork>
		&PING; 1 2 3;
		&PUSH; 1.2.3;
	</artwork>

As an added bonus, it might make auto-indexing of commands simple --
just add an index-entry-generating element into the entity
definition!

Are there any better solutions than XML entities?

Without modifying xml2rfc, I can only think of preprocessing XML
files with a custom script. However, this is not trivial because

	- XML files include other XML files by filename
	  so I would either have to preprocess those filenames
	  as well OR use post-preprocessor filenames in sources

	- makes sharing XML sources more difficult because
	  I would have to share the script as well

Am I overlooking a better solution?

Thank you,

Alex.

-- 
                            | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance

From: [email-masked] (Marshall Rose)
Date: Wed, 17 Sep 2003 10:25:50 -0700
Subject: [xml2rfc] internal entities
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> Are internal entities supported?

no. further, 2629 limits you to a very small number of pre-defined entities,
e.g.,"&amp;".

bottom line: if you want the full glory of xml, you aren't going to be using
2629.

/mtr

From: [email-masked] (Alex Rousskov)
Date: Wed, 17 Sep 2003 11:11:27 -0600 (MDT)
Subject: [xml2rfc] internal entities
Message-ID: <[email-masked]>

I am trying to declare a new internal entity. Xml2rfc seems to force
me to use an external entity:

	<?xml version="1.0"?>

	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	    <!ENTITY TEST "TEST">
	]>

	...

The above results in the following error:
	expecting <!ENTITY TEST SYSTEM or PUBLIC

Same error happens if the entity is declared outside of the DOCTYPE
instruction.

Am I doing something wrong? Are internal entities supported?

Thank you,

Alex.

From: [email-masked] (Julian Reschke)
Date: Sat, 13 Sep 2003 21:56:25 +0200
Subject: [xml2rfc] references vs. Amazon web services
Message-ID: <[email-masked]>

Here's a nice hack to retrieve biographical information using the Amazon Web
Services interface:

Given the ASIN (Amazon product code, for books this is the ISBN), enter:

	XSLT amazon-asin.xslt amazon-asin.xslt asin=ASIN

where "XSLT" is the name of your favorite XSLT command line processor and
"ASIN" is the ASIN. For instance,

	saxon amazon.xslt amazon-asin.xslt asin=0596000278

yields:

<?xml version="1.0" encoding="utf-8"?>
<references>
   <reference target="urn:isbn:0596000278">
      <front>
         <title>Programming Perl (3rd Edition)</title>
         <author surname="Wall" fullname="Larry Wall" initials="L. "/>
         <author surname="Christiansen" fullname="Tom Christiansen"
initials="T. "/>
         <author surname="Orwant" fullname="Jon Orwant" initials="J. "/>
         <seriesInfo name="O'Reilly &amp; Associates" value=""/>
         <date year="2000" month="July"/>
      </front>
   </reference>
</references>

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

<xsl:output indent="yes"/>

<xsl:param name="asin" />

<xsl:template match="/">
  <xsl:variable name="uri"
select="concat('http://xml.amazon.com/onca/xml3?t=webservices-20&amp;dev-t=f
oobar&amp;AsinSearch=',$asin,'&amp;type=heavy&amp;f=xml')" />
  <xsl:variable name="res" select="document($uri)" />
  <references>
    <xsl:apply-templates select="$res/ProductInfo/Details" />
  </references>
</xsl:template>

<xsl:template name="initials">
  <xsl:param name="str"/>
  <xsl:choose>
    <xsl:when test="contains($str,' ')">
      <xsl:call-template name="initials">
        <xsl:with-param name="str">
          <xsl:value-of select="substring-before($str,' ')"/>
        </xsl:with-param>
      </xsl:call-template>
      <xsl:call-template name="initials">
        <xsl:with-param name="str">
          <xsl:value-of select="substring-after($str,' ')"/>
        </xsl:with-param>
      </xsl:call-template>
    </xsl:when>
    <xsl:otherwise><xsl:value-of select="substring($str,1,1)"/>.
</xsl:otherwise>
  </xsl:choose>
</xsl:template>

<xsl:template name="get-surname">
  <xsl:param name="str"/>
  <xsl:choose>
    <xsl:when test="contains($str,' ')">
      <xsl:call-template name="get-surname">
        <xsl:with-param name="str" select="substring-after($str,' ')"/>
      </xsl:call-template>
    </xsl:when>
    <xsl:otherwise>
      <xsl:value-of select="$str"/>
    </xsl:otherwise>
  </xsl:choose>
</xsl:template>

<xsl:template match="Author">
  <xsl:variable name="surname">
    <xsl:call-template name="get-surname">
      <xsl:with-param name="str" select="normalize-space(.)"/>
    </xsl:call-template>
  </xsl:variable>
  <xsl:variable name="givenname">
    <xsl:value-of select="normalize-space(substring-before(.,$surname))"/>
  </xsl:variable>
  <author surname="{$surname}" fullname="{$givenname} {$surname}">
    <xsl:attribute name="initials">
      <xsl:call-template name="initials">
        <xsl:with-param name="str" select="$givenname"/>
      </xsl:call-template>
    </xsl:attribute>
  </author>
</xsl:template>

<xsl:template match="Details">
  <reference target="urn:isbn:{Isbn}">
    <front>
      <xsl:apply-templates select="ProductName"/>
      <xsl:apply-templates select="Authors/Author"/>
      <xsl:apply-templates select="Manufacturer"/>
      <xsl:apply-templates select="ReleaseDate"/>
    </front>
  </reference>
</xsl:template>

<xsl:template match="ReleaseDate">
  <xsl:variable name="part1"
select="normalize-space(substring-before(.,','))" />
  <xsl:variable name="part2"
select="normalize-space(substring-after(.,','))" />
  <date year="{$part2}">
    <xsl:choose>
      <xsl:when test="contains($part1,' ')">
        <xsl:attribute name="month">
          <xsl:value-of select="substring-after($part1,' ')" />
        </xsl:attribute>
      </xsl:when>
      <xsl:otherwise>
        <xsl:attribute name="month">
          <xsl:value-of select="$part1" />
        </xsl:attribute>
      </xsl:otherwise>
    </xsl:choose>
  </date>
</xsl:template>

<xsl:template match="ProductName">
  <title><xsl:value-of select="."/></title>
</xsl:template>

<xsl:template match="Manufacturer">
  <seriesInfo name="{.}" value="" />
</xsl:template>

</xsl:transform>

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

From: [email-masked] (Elwyn Davies)
Date: Tue, 9 Sep 2003 23:33:10 +0100
Subject: [xml2rfc] Feature request: Ability to have list items without intervening b lank lines
Message-ID: <[email-masked]>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C37722.4F3DC52C
Content-Type: text/plain

I must admit I thought I had tried that.. but maybe it was in an earlier
release.

I just tried it again using v 1.19

and

-------------------------------------------
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc ipr="full2026" docName="draft-davies-structural-rev-process-00.txt">

....

   <middle>
      <section title="Introduction">
         <t>Version 02 of the Problem Resolution draft<xref
target="refs.resolve" />
         <list style="symbols">
            <t>a</t>
            <t>b</t>
            <t>c</t>
            <t>d</t>
            <t>e</t>
         </list>
         solicited proposals from the community for processes to resolve the
more

---------------------------------------------
produced

---------------------------------------------

   o  a

   o  b

   o  c

   o  d

   o  e

---------------------------------------------

Regards,
Elwyn

> -----Original Message-----
> From: Marshall Rose [mailto:[email-masked]] 
> Sent: 09 September 2003 22:44
> To: Davies, Elwyn [HAL02:0S00:EXCH]
> Cc: xml2rfc mailing list
> Subject: Re: [xml2rfc] Feature request: Ability to have list 
> items without intervening b lank lines
> 
> 
> > I have been unable to create lists of short items without a 
> blank line
> > between the items (except by using <vspace 0/> within a 
> single paragraph).
> > This is rather wasteful of space apart from anything else 
> and with a lengthy
> > list makes it difficult for the reader to scan the list in 
> one go. Could
> > this be considered for a future upgrade?
> 
> what PIs are you using?
>     
> try putting
>     
>     <?rfc compact='yes'?>
>     <?rfc subcompact='no'?>
>     
> right before the
>     
>     <rfc>
>     
> /mtr
> 

------_=_NextPart_001_01C37722.4F3DC52C
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: [xml2rfc] Feature request: Ability to have list items =
without intervening b lank lines</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I must admit I thought I had tried that.. but maybe =
it was in an earlier release.</FONT>
</P>

<P><FONT SIZE=3D2>I just tried it again using v 1.19</FONT>
</P>

<P><FONT SIZE=3D2>and</FONT>
</P>

<P><FONT SIZE=3D2>-------------------------------------------</FONT>
<BR><FONT SIZE=3D2>&lt;?rfc strict=3D&quot;yes&quot;?&gt;</FONT>
<BR><FONT SIZE=3D2>&lt;?rfc compact=3D&quot;yes&quot;?&gt;</FONT>
<BR><FONT SIZE=3D2>&lt;?rfc subcompact=3D&quot;no&quot;?&gt;</FONT>
<BR><FONT SIZE=3D2>&lt;rfc ipr=3D&quot;full2026&quot; =
docName=3D&quot;draft-davies-structural-rev-process-00.txt&quot;&gt;</FO=
NT>
</P>

<P><FONT SIZE=3D2>....</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; &lt;middle&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;section =
title=3D&quot;Introduction&quot;&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;t&gt;Version 02 of the Problem Resolution draft&lt;xref =
target=3D&quot;refs.resolve&quot; /&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;list style=3D&quot;symbols&quot;&gt;</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; &lt;t&gt;a&lt;/t&gt;</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; &lt;t&gt;b&lt;/t&gt;</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; &lt;t&gt;c&lt;/t&gt;</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; &lt;t&gt;d&lt;/t&gt;</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; &lt;t&gt;e&lt;/t&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;/list&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
solicited proposals from the community for processes to resolve the =
more</FONT>
</P>

<P><FONT SIZE=3D2>---------------------------------------------</FONT>
<BR><FONT SIZE=3D2>produced</FONT>
</P>

<P><FONT SIZE=3D2>---------------------------------------------</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; o&nbsp; a</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; o&nbsp; b</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; o&nbsp; c</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; o&nbsp; d</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; o&nbsp; e</FONT>
</P>

<P><FONT SIZE=3D2>---------------------------------------------</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Elwyn</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Marshall Rose [<A =
HREF=3D"mailto:[email-masked]">mailto:mrose+int=
[email-masked]</A>] </FONT>
<BR><FONT SIZE=3D2>&gt; Sent: 09 September 2003 22:44</FONT>
<BR><FONT SIZE=3D2>&gt; To: Davies, Elwyn [HAL02:0S00:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: xml2rfc mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [xml2rfc] Feature request: Ability =
to have list </FONT>
<BR><FONT SIZE=3D2>&gt; items without intervening b lank lines</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I have been unable to create lists of =
short items without a </FONT>
<BR><FONT SIZE=3D2>&gt; blank line</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; between the items (except by using =
&lt;vspace 0/&gt; within a </FONT>
<BR><FONT SIZE=3D2>&gt; single paragraph).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; This is rather wasteful of space apart =
from anything else </FONT>
<BR><FONT SIZE=3D2>&gt; and with a lengthy</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; list makes it difficult for the reader to =
scan the list in </FONT>
<BR><FONT SIZE=3D2>&gt; one go. Could</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; this be considered for a future =
upgrade?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; what PIs are you using?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; try putting</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; &lt;?rfc =
compact=3D'yes'?&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; &lt;?rfc =
subcompact=3D'no'?&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; right before the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; &lt;rfc&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; /mtr</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C37722.4F3DC52C--

From: [email-masked] (Marshall Rose)
Date: Tue, 9 Sep 2003 14:43:47 -0700
Subject: [xml2rfc] Feature request: Ability to have list items without intervening b lank lines
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> I have been unable to create lists of short items without a blank line
> between the items (except by using <vspace 0/> within a single paragraph).
> This is rather wasteful of space apart from anything else and with a lengthy
> list makes it difficult for the reader to scan the list in one go. Could
> this be considered for a future upgrade?

what PIs are you using?
    
try putting
    
    <?rfc compact='yes'?>
    <?rfc subcompact='no'?>
    
right before the
    
    <rfc>
    
/mtr

From: [email-masked] (Elwyn Davies)
Date: Tue, 9 Sep 2003 22:07:52 +0100
Subject: [xml2rfc] Feature request: Ability to have list items without intervening b lank lines
Message-ID: <[email-masked]>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C37716.6DBF2498
Content-Type: text/plain

Hi.

I have been unable to create lists of short items without a blank line
between the items (except by using <vspace 0/> within a single paragraph).
This is rather wasteful of space apart from anything else and with a lengthy
list makes it difficult for the reader to scan the list in one go. Could
this be considered for a future upgrade?

BTW I think that as it stands the xml2rfc suite is *extremely* useful - so
much easier than struggling with W**d.

Regards,
Elwyn

----------------------------------------------------------------------------
------

Elwyn B Davies

        Routing and Addressing Strategy Prime & IPv6 Core Team Leader
        CTO Office, Portfolio Integration		Solutions Ready

        Nortel Networks plc			Email:
[email-masked]
        Harlow Laboratories     			ESN
6-742-5498
        London Road, Harlow,    			Direct Line
+44-1279-405498
        Essex, CM17 9NA, UK     		Fax
+44-1279-402047
        Registered Office: 			Maidenhead Office Park,
Westacott Way,
        Company No. 3937799			Maidenhead, Berkshire, SSL6
3QH
----------------------------------------------------------------------------
This message may contain information proprietary to Nortel Networks plc so
any
unauthorised disclosure, copying or distribution of its contents is strictly
prohibited.
----------------------------------------------------------------------------
"The Folly is mostly mine"
and the opinions are mine and not those of my employer.
============================================================================
======

------_=_NextPart_001_01C37716.6DBF2498
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>Feature request: Ability to have list items without intervening =
blank lines</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I have been unable to create lists of =
short items without a blank line between the items (except by using =
&lt;vspace 0/&gt; within a single paragraph).&nbsp; This is rather =
wasteful of space apart from anything else and with a lengthy list =
makes it difficult for the reader to scan the list in one go. Could =
this be considered for a future upgrade?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">BTW I think that as it stands the =
xml2rfc suite is *extremely* useful - so much easier than struggling =
with W**d.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Elwyn</FONT>
</P>

<P><FONT SIZE=3D1 =
FACE=3D"Arial">---------------------------------------------------------=
-------------------------</FONT>
</P>

<P><FONT SIZE=3D1 FACE=3D"Arial">Elwyn B Davies</FONT>
</P>

<P><FONT SIZE=3D1 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Routing and =
Addressing Strategy Prime &amp; IPv6 Core Team Leader</FONT>
<BR><FONT SIZE=3D1 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CTO Office, =
Portfolio Integration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Solutions Ready =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D1 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Nortel =
Networks plc&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT> <FONT SIZE=3D1 =
FACE=3D"Arial">Email: [email-masked]</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D1 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Harlow =
Laboratories&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
ESN&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 6-742-5498</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D1 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; London Road, =
Harlow,&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Direct =
Line&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
+44-1279-405498</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D1 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Essex, CM17 =
9NA, UK&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Fax&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +44-1279-402047</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D1 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Registered =
Office: &nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Maidenhead Office Park, =
Westacott Way,</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D1 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Company =
No.</FONT> <FONT SIZE=3D1 =
FACE=3D"Arial">3937799&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT><FONT =
COLOR=3D"#000000" SIZE=3D1 FACE=3D"Arial">Maidenhead, Berkshire, SSL6 =
3QH</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D1 =
FACE=3D"Arial">---------------------------------------------------------=
-------------------</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D1 FACE=3D"Arial">This message may =
contain information proprietary to Nortel Networks plc so any</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D1 FACE=3D"Arial">unauthorised =
disclosure, copying or distribution of its contents is strictly =
prohibited.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D1 =
FACE=3D"Arial">---------------------------------------------------------=
-------------------</FONT>
<BR><FONT SIZE=3D1 FACE=3D"Arial">&quot;The Folly is mostly =
mine&quot;</FONT>
<BR><FONT SIZE=3D1 FACE=3D"Arial">and the opinions are mine and not =
those of my employer.</FONT>
<BR><FONT SIZE=3D1 =
FACE=3D"Arial">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C37716.6DBF2498--

From: [email-masked] (Clive D.W. Feather)
Date: Tue, 9 Sep 2003 20:24:42 +0100
Subject: [xml2rfc] Email addresses
Message-ID: <[email-masked]>

Why am I only allowed one email address in the author details? I've got
more than one that I want to be listed.

-- 
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] (Aaron Falk)
Date: Tue, 9 Sep 2003 11:37:19 -0700
Subject: [xml2rfc] submitting xml to rfc-editor
Message-ID: <[email-masked]>

The RFC Editor is experimenting with XML to edit RFCs and requests
that, when Internet Drafts are submitted to the RFC Editor, authors
using the xml2rfc tool email their XML files to the RFC Editor.

While we can't promise that we will use your XML, you will be helping
us make our evaluation of the tool.

Thanks,

--aaron (for the RFC Editor)

From: [email-masked] (Carl Malamud)
Date: Sun, 7 Sep 2003 21:00:19 -0700 (PDT)
Subject: [xml2rfc] Error when validating at http://www.w3.org/2001/03/webdata/xsv
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Henning -

Try adding a % sign to your entity declarations as follows:

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY % rfc2119 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
  <!ENTITY % ietf-simple-rpid PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-simple-rpid.xml'>
  <!ENTITY % ietf-impp-cpim-pidf PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-impp-cpim-pidf.xml'>
  <!ENTITY % mealling-iana-xmlns-registry PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mealling-iana-xmlns-registry.xml'>

]>

Regards,

Carl

> Any hints what causes this validation failure?
> 
> Error: Encoding declaration is required in text declaration
>   in entity "rfc2119" at line 1 char 22 of 
> http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml
>   in unnamed entity at line 227 char 10 of 
> http://www.cs.columbia.edu/sip/draft/future-status/draft-ietf-simple-future-00.xml
> 
> 
> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

From: [email-masked] (Henning Schulzrinne)
Date: Sun, 07 Sep 2003 22:33:15 -0400
Subject: [xml2rfc] Error when validating at http://www.w3.org/2001/03/webdata/xsv
Message-ID: <[email-masked]>

Any hints what causes this validation failure?

Error: Encoding declaration is required in text declaration
  in entity "rfc2119" at line 1 char 22 of 
http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml
  in unnamed entity at line 227 char 10 of 
http://www.cs.columbia.edu/sip/draft/future-status/draft-ietf-simple-future-00.xml

From: [email-masked] (Scott W Brim)
Date: Wed, 3 Sep 2003 13:57:46 -0400
Subject: [xml2rfc] Reference indicator format
In-Reply-To: <[email-masked]>; from [email-masked] on Wed, Sep 03, 2003 at 01:39:56PM -0400
References: <[email-masked] <[email-masked]> <[email-masked]>
Message-ID: <20030903135746.H2600@sbrim-w2k01>

On Wed, Sep 03, 2003 01:39:56PM -0400, John C Klensin allegedly wrote:
> --On Tuesday, 02 September, 2003 19:12 -0700 Dan Kohn 
> <[email-masked]> wrote:
> 
> > Try adding the following processor instructions to the top of
> > your XML file:
> >
> > <?rfc symrefs="yes" ?>
> > <?rfc sortrefs="yes"?>
> >
> > These are shown in
> > <http://xml.resource.org/authoring/sample.xml>, which is I
> > believe is part of the default download.
> 
> That did it.  Thanks, and sorry for the trouble.
> 
> However, I do think this stuff would be desirably drawn together 
> into one place -- requiring that prospective users poke through 
> "sample" files is not an optimal way to build usage.  Marshall, 
> would you like text contributions to 2629bis?

The processing instructions are listed in the README.* that came with
xml2rfc.  I suspect you're right about better organization of
information.

From: [email-masked] (Marshall Rose)
Date: Wed, 3 Sep 2003 10:57:25 -0700
Subject: [xml2rfc] Reference indicator format
In-Reply-To: <[email-masked]>
References: <[email-masked] .skymv.com> <[email-masked]>
Message-ID: <[email-masked]>

> However, I do think this stuff would be desirably drawn together 
> into one place -- requiring that prospective users poke through 
> "sample" files is not an optimal way to build usage.  Marshall, 
> would you like text contributions to 2629bis?

sure, but a couple of things:

there's a README file that comes with xml2rfc that should be linked on the
homepage (i'll do that now). that file describes the PI's understood by xml2rfc.

a PI, such as <?rfc keyword='value'?>, is an optional directive to the XML
processor. the README file lists the ones that xml2rfc knows about, other
processors probably have an improper subset of those.

if there's concensus that a particular collection of PIs provide the best or
recommended for the rfc editor, i can add a "super" PI which does just that.
(thus, if you put in this one option, you don't have to worry about putting in
new ones). someone tell me what goes in the super option and i'll add it.

thanks,

/mtr

From: [email-masked] (John C Klensin)
Date: Wed, 03 Sep 2003 13:39:56 -0400
Subject: [xml2rfc] Reference indicator format
In-Reply-To: <[email-masked]>
References: <[email-masked] .skymv.com>
Message-ID: <[email-masked]>

--On Tuesday, 02 September, 2003 19:12 -0700 Dan Kohn 
<[email-masked]> wrote:

> Try adding the following processor instructions to the top of
> your XML file:
>
> <?rfc symrefs="yes" ?>
> <?rfc sortrefs="yes"?>
>
> These are shown in
> <http://xml.resource.org/authoring/sample.xml>, which is I
> believe is part of the default download.

That did it.  Thanks, and sorry for the trouble.

However, I do think this stuff would be desirably drawn together 
into one place -- requiring that prospective users poke through 
"sample" files is not an optimal way to build usage.  Marshall, 
would you like text contributions to 2629bis?

     john

From: [email-masked] (Marshall Rose)
Date: Wed, 3 Sep 2003 10:31:18 -0700
Subject: [xml2rfc] 3gpp bibxml now online
Message-ID: <[email-masked]>

thanks to miguel garcia, the 3gpp bixml is now available, cf.,

	http://xml.resource.org/

/mtr

ps: i've updated the server hosting the web-based service, the mailing lists,
etc. any problems, please let me know...

From: [email-masked] (Dan Kohn)
Date: Tue, 2 Sep 2003 19:12:36 -0700
Subject: [xml2rfc] Reference indicator format
Message-ID: <[email-masked]>

Try adding the following processor instructions to the top of your XML
file:

<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>

These are shown in <http://xml.resource.org/authoring/sample.xml>, which
is I believe is part of the default download.

          - dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>
-----Original Message-----
From: John C Klensin [mailto:[email-masked]] 
Sent: Tuesday, September 02, 2003 16:39
To: [email-masked]
Subject: [xml2rfc] Reference indicator format

Hi.

I recently received a note from the RFC Editor that reads, in 
part,

> 6. We request that you change from numeric citations to
> another form. 	EG in section 4.1 it is unclear (without
> checking) that 	[9] and RFC 2396 are the same thing.

I suppose that consistency remains the refuge...

I have therefore been trying to get the markup and xml2rfc to 
produce [RFC2396] rather than [9].  It appears from the 24 July 
(version 1.20) version of 2629bis as if this should be possible, 
but I'm having trouble reading the relevant text.

	<xref target="RFC2396"  format="title" />

produces no reference at all, presumably because there is no 
relevant element.  But

	<xref target="RFC1035"  format="title" /> RFC1035 </xref>

Gives me
   RFC1035 [3]

Inserting, or not, an "abbrev" parameter in the <title> element 
of the target, e.g.,

	<reference anchor="RFC1035" >
	<!-- title="RFC1035" -->
	   <front>
	   <title abbrev="RFC1035"> Domain names -
	implementation and specification</title>    <author
	initials="P.V." surname="Mockapetris"
		  fullname="P.V. Mockapetris">

Doesn't seem to have any impact on this.

What should I be doing?   And, as a suggestion, it might be 
desirable, given especially that the RFC Editor is asking for 
this sort of thing (again), to give a bit more explanation 
and/or an example of this in the 2629bis text.

thanks,
    john

_______________________________________________
xml2rfc mailing list
[email-masked]
http://lists.xml.resource.org/mailman/listinfo/xml2rfc

From: [email-masked] (John C Klensin)
Date: Tue, 02 Sep 2003 19:39:02 -0400
Subject: [xml2rfc] Reference indicator format
In-Reply-To: <[email-masked]>
References: <[email-masked] rope.nortel.com>
Message-ID: <[email-masked]>

Hi.

I recently received a note from the RFC Editor that reads, in 
part,

> 6. We request that you change from numeric citations to
> another form. 	EG in section 4.1 it is unclear (without
> checking) that 	[9] and RFC 2396 are the same thing.

I suppose that consistency remains the refuge...

I have therefore been trying to get the markup and xml2rfc to 
produce [RFC2396] rather than [9].  It appears from the 24 July 
(version 1.20) version of 2629bis as if this should be possible, 
but I'm having trouble reading the relevant text.

	<xref target="RFC2396"  format="title" />

produces no reference at all, presumably because there is no 
relevant element.  But

	<xref target="RFC1035"  format="title" /> RFC1035 </xref>

Gives me
   RFC1035 [3]

Inserting, or not, an "abbrev" parameter in the <title> element 
of the target, e.g.,

	<reference anchor="RFC1035" >
	<!-- title="RFC1035" -->
	   <front>
	   <title abbrev="RFC1035"> Domain names -
	implementation and specification</title>    <author
	initials="P.V." surname="Mockapetris"
		  fullname="P.V. Mockapetris">

Doesn't seem to have any impact on this.

What should I be doing?   And, as a suggestion, it might be 
desirable, given especially that the RFC Editor is asking for 
this sort of thing (again), to give a bit more explanation 
and/or an example of this in the 2629bis text.

thanks,
    john