Programming Perl (3rd Edition)

I would suspect we may get quite a few of those? Is anyone checking into this to fix those include file? Thanks, Bert From: bwijnen@lucent.com (Wijnen, Bert (Bert)) Date: Tue, 23 Sep 2003 10:13:20 +0200 Subject: [xml2rfc] two wish-list items Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550233162D@nl0006exch001u.nl.lucent.com> > > 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: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Mon, 22 Sep 2003 20:48:54 -0700 Subject: [xml2rfc] two wish-list items In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155023315FF@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B155023315FF@nl0006exch001u.nl.lucent.com> Message-ID: <20030922204854.4ef862f4.mrose+internet.xml2rfc@dbc.mtview.ca.us> > 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: rousskov@measurement-factory.com (Alex Rousskov) Date: Mon, 22 Sep 2003 08:56:39 -0600 (MDT) Subject: [xml2rfc] feature request: artwork.trimspace=yes Message-ID: RFC parts, sections, figures, etc. lead to natural indentation of raw XML text we edit:
...
When the inner section has embedded artwork, I have to use different indentation so that rendered output looks nice:
GET / HTTP/1.1 Accept: ... Whatever: ...
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:
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 and first end-of-line including the end-of-line marker - tail: whitespace between the last non-whitespace character of the artwork and - 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:
GET / HTTP/1.1 Accept: ... Whatever: ...
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: julian.reschke@gmx.de (Julian Reschke) Date: Mon, 22 Sep 2003 16:52:27 +0200 Subject: [xml2rfc] refreences within a
In-Reply-To: Message-ID: Sure. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: xml2rfc-admin@lists.xml.resource.org > [mailto:xml2rfc-admin@lists.xml.resource.org]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
> > > > I stand corrected, then! The facts you mentioned may also explain why > Bert is not getting the intended formatting. I wonder if HTML's
> element also assumes "plain text content without child elements".
> 
> Alex.
> 
> 
> On Mon, 22 Sep 2003, Julian Reschke wrote:
> 
> > > From: xml2rfc-admin@lists.xml.resource.org
> > > [mailto:xml2rfc-admin@lists.xml.resource.org]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 
> > >
> > >
> > > 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
> >
> > --
> > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> >
> > _______________________________________________
> > xml2rfc mailing list
> > xml2rfc@lists.xml.resource.org
> > http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> >
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 


From: rousskov@measurement-factory.com (Alex Rousskov)
Date: Mon, 22 Sep 2003 08:30:31 -0600 (MDT)
Subject: [xml2rfc] refreences within a 
In-Reply-To: 
References: 
Message-ID: 

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

Alex.


On Mon, 22 Sep 2003, Julian Reschke wrote:

> > From: xml2rfc-admin@lists.xml.resource.org
> > [mailto:xml2rfc-admin@lists.xml.resource.org]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 
> >
> >
> > 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
>
> --
> bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>


From: julian.reschke@gmx.de (Julian Reschke)
Date: Mon, 22 Sep 2003 16:15:30 +0200
Subject: [xml2rfc] refreences within a 
In-Reply-To: 
Message-ID: 

> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]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 
>
>
> 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

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



From: rousskov@measurement-factory.com (Alex Rousskov)
Date: Mon, 22 Sep 2003 07:57:58 -0600 (MDT)
Subject: [xml2rfc] refreences within a 
In-Reply-To: 
References: 
Message-ID: 

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: bwijnen@lucent.com (Wijnen, Bert (Bert))
Date: Mon, 22 Sep 2003 15:29:13 +0200
Subject: [xml2rfc] refreences within a 
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550233160F@nl0006exch001u.nl.lucent.com>

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:julian.reschke@gmx.de]
> Sent: maandag 22 september 2003 15:21
> To: Wijnen, Bert (Bert); Xml2rfc (E-mail)
> Subject: RE: [xml2rfc] refreences within a 
> 
> 
> 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
> 
> --
> bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 
> > -----Original Message-----
> > From: xml2rfc-admin@lists.xml.resource.org
> > [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of 
> Wijnen, Bert
> > (Bert)
> > Sent: Monday, September 22, 2003 1:10 PM
> > To: Xml2rfc (E-mail)
> > Subject: [xml2rfc] refreences within a 
> >
> >
> > I have:
> >
> >   
> >     
> >     0   rmonEventsV2          Notifications root       > target="RFC2819"/>
> >     1   statistics            OID                      > target="RFC2819"/>
> >
> >     
> >   
> >
> > 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
> > xml2rfc@lists.xml.resource.org
> > http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> >
> 


From: julian.reschke@gmx.de (Julian Reschke)
Date: Mon, 22 Sep 2003 15:20:51 +0200
Subject: [xml2rfc] refreences within a 
In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15502331600@nl0006exch001u.nl.lucent.com>
Message-ID: 

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

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

> -----Original Message-----
> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of Wijnen, Bert
> (Bert)
> Sent: Monday, September 22, 2003 1:10 PM
> To: Xml2rfc (E-mail)
> Subject: [xml2rfc] refreences within a 
>
>
> I have:
>
>   
>     
>     0   rmonEventsV2          Notifications root       target="RFC2819"/>
>     1   statistics            OID                      target="RFC2819"/>
>
>     
>   
>
> 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
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>



From: bwijnen@lucent.com (Wijnen, Bert (Bert))
Date: Mon, 22 Sep 2003 13:09:54 +0200
Subject: [xml2rfc] refreences within a 
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502331600@nl0006exch001u.nl.lucent.com>

I have:

  
    
    0   rmonEventsV2          Notifications root      
    1   statistics            OID                     

    
  

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: bwijnen@lucent.com (Wijnen, Bert (Bert))
Date: Mon, 22 Sep 2003 11:42:49 +0200
Subject: [xml2rfc] two wish-list items
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155023315FF@nl0006exch001u.nl.lucent.com>

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: bwijnen@lucent.com (Wijnen, Bert (Bert))
Date: Mon, 22 Sep 2003 00:00:04 +0200
Subject: [xml2rfc] Help please
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155023315F9@nl0006exch001u.nl.lucent.com>

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:mrose+internet.xml2rfc@dbc.mtview.ca.us]
> 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: 
> >      >     docName="draft-ietf-rmonmib-rmon-oid-assignments-00.txt"
> >     category="std">
> > 
> > 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  element
>     
> so, if think if you look at the elements right after the 
>  you'll
> see where the problem is...
>     
> /mtr
>     
> 


From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Sun, 21 Sep 2003 14:34:11 -0700
Subject: [xml2rfc] Help please
In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155023315F7@nl0006exch001u.nl.lucent.com>
References: <7D5D48D2CAA3D84C813F5B154F43B155023315F7@nl0006exch001u.nl.lucent.com>
Message-ID: <20030921143411.4e3a747b.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> And when I try to check it online, I get 
>    Unable to Convert File
>    unexpected end of attribute list around line 20
> 
>    Context: 
>          docName="draft-ietf-rmonmib-rmon-oid-assignments-00.txt"
>     category="std">
> 
> 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  element
    
so, if think if you look at the elements right after the  you'll
see where the problem is...
    
/mtr
    


From: bwijnen@lucent.com (Wijnen, Bert (Bert))
Date: Sun, 21 Sep 2003 22:27:31 +0200
Subject: [xml2rfc] Help please
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155023315F7@nl0006exch001u.nl.lucent.com>

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

I have:


  
 ]>











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

   Context: 
    
    

But I do not see whT is wrong here?

Thanks,
Bert 


From: rousskov@measurement-factory.com (Alex Rousskov)
Date: Sat, 20 Sep 2003 08:33:53 -0600 (MDT)
Subject: [xml2rfc] xml2rfc thoughts
In-Reply-To: 
References: 
Message-ID: 

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:
>
>   write some text
>
> And later
>
>   
>
> Or something like that.
>
> --
> Wes Hardaker
> Sparta


From: hardaker@tislabs.com (Wes Hardaker)
Date: Fri, 19 Sep 2003 21:59:48 -0700
Subject: [xml2rfc] xml2rfc thoughts
Message-ID: 

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: 

  write some text

And later

  

Or something like that.

-- 
Wes Hardaker
Sparta



From: rousskov@measurement-factory.com (Alex Rousskov)
Date: Wed, 17 Sep 2003 18:48:15 -0600 (MDT)
Subject: [xml2rfc] internal entities
In-Reply-To: <20030917160347.6769aec6.mrose+internet.xml2rfc@dbc.mtview.ca.us>
References:   <20030917160347.6769aec6.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: 

  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 mime@docserver.cac.washington.edu for more info.

--0-407906576-1063845676=:26365
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: 

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: 
Content-Description: xmlpp.pl
Content-Disposition: ATTACHMENT; FILENAME="xmlpp.pl"

IyEvdXNyL2Jpbi9wZXJsIC13DQp1c2Ugc3RyaWN0Ow0KDQojDQojIEFib3V0
Og0KIyAgICAgICBUaGlzIHNjcmlwdCBpbnRlbmRzIHRvIGRvIHRoZSBmb2xs
b3dpbmcsDQojICAgICAgIGluIHRoZSBzcGVjaWZpZWQgb3JkZXI6IA0KIyAg
ICAgICAgICAgLSByZWFkIHN0YW5kYXJkIGlucHV0DQojICAgICAgICAgICAt
IGZpbmQgdmFyaW91cyB4bWwycmZjLWluY2x1ZGUgc3RhdGVtZW50cw0KIyAg
ICAgICAgICAgLSBzdWJzdGl0dXRlIHRob3NlIHN0YXRlbWVudHMgd2l0aCBp
bmNsdWRlZCBmaWxlcw0KIyAgICAgICAgICAgLSBmaW5kIGRlY2xhcmF0aW9u
cyBvZiBYTUwgaW50ZXJuYWwgZW50aXRpZXMNCiMgICAgICAgICAgIC0gZGVs
ZXRlIHRob3NlIGRlY2xhcmF0aW9ucw0KIyAgICAgICAgICAgLSBzdWJzdGl0
dXRlIGRlY2xhcmVkIGludGVybmFsIGVudGl0eSBuYW1lcyB3aXRoIHRoZWly
IGRlZmluaXRpb25zDQojICAgICAgICAgICAtIHdyaXRlIHRoZSByZXN1bHQg
dG8gc3RhbmRhcmQgb3V0cHV0Lg0KIyAgICAgICBUaGUgb25seSByZWNvZ25p
emVkIFhNTCBpbnRlcm5hbCBlbnRpdHkgZGVjbGFyYXRpb24gDQojICAgICAg
IHBhdHRlcm4gaXM6ICA8IUVOVElUWSBuYW1lICJkZWZpbml0aW9uIj4NCiMg
ICAgICAgWE1MX0xJQlJBUlkgZW52aXJvbm1lbnQgdmFyaWFibGUgaXMgdXNl
ZCBhcyBhIHBhdGggZm9yIGluY2x1ZGVzLg0KIw0KIyBCdWdzOg0KIyAgICAg
ICAgVGhpcyBzY3JpcHQgaXMgbm90IFhNTC1hd2FyZS4NCiMgICAgICAgIFNl
bGYtcmVmZXJlbmNpbmcgZW50aXRpZXMgb3IgaW5jbHVkZSBzdGF0ZW1lbnRz
IA0KIyAgICAgICAgcmVzdWx0IGluIGFuIGluZmluaXRlIGxvb3AuDQojDQoj
IExlZ2FsOiANCiMgICAgICAgIFRoaXMgc2NyaXB0IGhhcyBiZWVuIHBsYWNl
ZCBpbiBwdWJsaWMgZG9tYWluIGJ5DQojICAgICAgICB0aGUgZ29vZCBmb2xr
cyBhdCBUaGUgTWVhc3VyZW1lbnQgRmFjdG9yeS4NCiMgDQojICRJZDogeG1s
cHAucGwsdiAxLjEgMjAwMy8wOS8xOCAwMDo0NjoyNiByb3Vzc2tvdiBFeHAg
JA0KDQojIHJlYWQgZXZlcnl0aGluZyBpbg0KbXkgJHhtbCA9ICcnOw0Kd2hp
bGUgKDxTVERJTj4pIHsNCgkkeG1sIC49ICRfOw0KfQ0KDQojIGhhbmRsZSBp
bmNsdWRlcw0KJHhtbCA9fiBzLzxcP3JmY1xzK2luY2x1ZGU9WyciXShbXici
XSspWyciXVxzKlw/Pi8mbG9hZEZpbGUoJDEpL2VzZzsNCg0KIyBmaW5kIGVu
dGl0eSBkZWNsYXJhdGlvbnMNCm15ICVFbnRpdGllcyA9ICgpOw0Kd2hpbGUg
KCR4bWwgPX4gcy88IUVOVElUWVxzKyhcdyspXHMrIihbXiJdKikiXHMqPi8v
cykgew0KCW15ICRuYW1lID0gJDE7DQoJbXkgJHZhbHVlID0gJDI7DQoJaWYg
KGV4aXN0cyAkRW50aXRpZXN7JG5hbWV9KSB7DQoJCWRpZSgiZW50aXR5ICRu
YW1lIHJlZGVmaW5lZCBmcm9tICIuDQoJCQkiJyRFbnRpdGllc3skbmFtZX0n
IHRvICckbmFtZScgbmVhciAnJCYnLCBzdG9wcGVkIik7DQoJfSBlbHNlIHsN
CgkJJEVudGl0aWVzeyRuYW1lfSA9ICR2YWx1ZTsNCgl9DQp9DQoNCiMgc3Vi
c3RpdHV0ZSBlbnRpdGllcyByZWN1cnNpdmVseQ0KbXkgJHN0YWJsZTsNCmRv
IHsNCgkkc3RhYmxlID0gMTsNCgl3aGlsZSAobXkgKCRuYW1lLCAkdmFsdWUp
ID0gZWFjaCAlRW50aXRpZXMpIHsNCgkJJHN0YWJsZSA9IDAgaWYgJHhtbCA9
fiBzL1wmJG5hbWVcOy8kdmFsdWUvZzsNCgl9DQp9IHVudGlsICRzdGFibGU7
DQoNCg0KcHJpbnQgJHhtbDsNCg0KZXhpdCAwOw0KDQoNCg0Kc3ViIGxvYWRG
aWxlIHsNCglteSAkbmFtZSA9ICRfWzBdOw0KDQoJbXkgJGRpcnMgPSAkRU5W
eydYTUxfTElCUkFSWSd9Ow0KCSRkaXJzID0gJy4nIHVubGVzcyBkZWZpbmVk
ICRkaXJzOw0KCWZvcmVhY2ggbXkgJGRpciAoc3BsaXQgKC86Ky8sICRkaXJz
KSkgew0KCQlteSAkZm5hbWUgPSAiJGRpci8kbmFtZSI7DQoJCW5leHQgdW5s
ZXNzIC1lICRmbmFtZTsNCg0KCQlteSAkY29udGVudCA9ICcnOw0KCQlvcGVu
KElGLCAiPCRmbmFtZSIpIG9yIGRpZSgiY2Fubm90IHJlYWQgaW5jbHVkZWQg
ZmlsZTogJGZuYW1lLCBzdG9wcGVkIik7DQoJCXdoaWxlICg8SUY+KSB7DQoJ
CQkkY29udGVudCAuPSAkXzsNCgkJfQ0KCQljbG9zZShJRik7DQoJCXJldHVy
biAkY29udGVudDsNCgl9DQoNCglpZiAoZGVmaW5lZCAkRU5WeydYTUxfTElC
UkFSWSd9KSB7DQoJCXdhcm4oInNlYXJjaCBwYXRoIGRlcml2ZWQgZnJvbSB0
aGUgWE1MX0xJQlJBUlkgZW52aXJvbm1lbnQgdmFyaWFibGU7XG4iKTsNCgl9
IGVsc2Ugew0KCQl3YXJuKCJYTUxfTElCUkFSWSBlbnZpcm9ubWVudCB2YXJp
YWJsZSBpcyBub3Qgc2V0O1xuIik7DQoJfQ0KCWRpZSgiY2Fubm90IGZpbmQg
aW5jbHVkZWQgJyRuYW1lJyBpbiAnJGRpcnMnIHBhdGgsIHN0b3BwZWQiKTsN
Cn0NCg==

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


From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Wed, 17 Sep 2003 16:03:47 -0700
Subject: [xml2rfc] internal entities
In-Reply-To: 
References:  
Message-ID: <20030917160347.6769aec6.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> 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: rousskov@measurement-factory.com (Alex Rousskov)
Date: Wed, 17 Sep 2003 16:09:08 -0600 (MDT)
Subject: [xml2rfc] internal entities
In-Reply-To: <200309172126.h8HLQ7l9016886@bulk.resource.org>
References: <200309172126.h8HLQ7l9016886@bulk.resource.org>
Message-ID: 

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  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: carl@media.org (Carl Malamud)
Date: Wed, 17 Sep 2003 14:26:07 -0700 (PDT)
Subject: [xml2rfc] internal entities
In-Reply-To: 
Message-ID: <200309172126.h8HLQ7l9016886@bulk.resource.org>

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.,"&". 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: rousskov@measurement-factory.com (Alex Rousskov)
Date: Wed, 17 Sep 2003 15:11:21 -0600 (MDT)
Subject: [xml2rfc] internal entities
In-Reply-To: 
References: 
Message-ID: 

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.,"&". 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: julian.reschke@gmx.de (Julian Reschke)
Date: Wed, 17 Sep 2003 22:59:08 +0200
Subject: [xml2rfc] internal entities
In-Reply-To: 
Message-ID: 

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

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

> -----Original Message-----
> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of Alex Rousskov
> Sent: Wednesday, September 17, 2003 10:49 PM
> To: Carl Malamud
> Cc: xml2rfc@lists.xml.resource.org
> 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
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>



From: rousskov@measurement-factory.com (Alex Rousskov)
Date: Wed, 17 Sep 2003 14:49:04 -0600 (MDT)
Subject: [xml2rfc] internal entities
In-Reply-To: <200309172009.h8HK9LuA009551@bulk.resource.org>
References: <200309172009.h8HK9LuA009551@bulk.resource.org>
Message-ID: 

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: carl@media.org (Carl Malamud)
Date: Wed, 17 Sep 2003 13:09:21 -0700 (PDT)
Subject: [xml2rfc] internal entities
In-Reply-To: 
Message-ID: <200309172009.h8HK9LuA009551@bulk.resource.org>

> 
> 
> 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: julian.reschke@gmx.de (Julian Reschke)
Date: Wed, 17 Sep 2003 21:35:57 +0200
Subject: [xml2rfc] internal entities
In-Reply-To: 
Message-ID: 

> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of Alex Rousskov
> Sent: Wednesday, September 17, 2003 9:24 PM
> To: xml2rfc@lists.xml.resource.org
> 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:



Julian

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



From: rousskov@measurement-factory.com (Alex Rousskov)
Date: Wed, 17 Sep 2003 13:23:57 -0600 (MDT)
Subject: [xml2rfc] internal entities
In-Reply-To: 
References: 
Message-ID: 

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: julian.reschke@gmx.de (Julian Reschke)
Date: Wed, 17 Sep 2003 20:06:08 +0200
Subject: [xml2rfc] internal entities
In-Reply-To: 
Message-ID: 

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?

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

> -----Original Message-----
> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of Alex Rousskov
> Sent: Wednesday, September 17, 2003 7:47 PM
> To: xml2rfc@lists.xml.resource.org
> 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.,"&".
> >
> > 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.
>
> 	
> 		&PING; 1 2 3;
> 		&PUSH; 1.2.3;
> 	
>
> 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
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>



From: rousskov@measurement-factory.com (Alex Rousskov)
Date: Wed, 17 Sep 2003 11:47:18 -0600 (MDT)
Subject: [xml2rfc] internal entities
In-Reply-To: <20030917102550.010f0a9b.mrose+internet.xml2rfc@dbc.mtview.ca.us>
References:  <20030917102550.010f0a9b.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: 

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.,"&".
>
> 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.

	
		&PING; 1 2 3;
		&PUSH; 1.2.3;
	

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: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Wed, 17 Sep 2003 10:25:50 -0700
Subject: [xml2rfc] internal entities
In-Reply-To: 
References: 
Message-ID: <20030917102550.010f0a9b.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> Are internal entities supported?

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

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

/mtr


From: rousskov@measurement-factory.com (Alex Rousskov)
Date: Wed, 17 Sep 2003 11:11:27 -0600 (MDT)
Subject: [xml2rfc] internal entities
Message-ID: 

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

	

	
	]>

	...

The above results in the following error:
	expecting 

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:



   
      
         Programming Perl (3rd Edition)
         
         
         
         
         
      
   




--







  
  
  
    
  



  
  
    
      
        
          
        
      
      
        
          
        
      
    
    .

  



  
  
    
      
        
      
    
    
      
    
  



  
    
      
    
  
  
    
  
  
    
      
        
      
    
  



  
    
      
      
      
      
    
  



  
  
  
    
      
        
          
        
      
      
        
          
        
      
    
  



  <xsl:value-of select="."/>



  








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



From: elwynd@nortelnetworks.com (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: <4103264BC8D3D51180B7002048400C450162376E@zhard0jd.europe.nortel.com>

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

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





....

   
      
         Version 02 of the Problem Resolution draft
         
            a
            b
            c
            d
            e
         
         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:mrose+internet.xml2rfc@dbc.mtview.ca.us] 
> 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  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
>     
>     
>     
>     
> right before the
>     
>     
>     
> /mtr
> 

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






RE: [xml2rfc] Feature request: Ability to have list items =
without intervening b lank lines



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=3D"yes"?>

<?rfc compact=3D"yes"?>

<?rfc subcompact=3D"no"?>

<rfc ipr=3D"full2026" =
docName=3D"draft-davies-structural-rev-process-00.txt">


....


   <middle>

      <section =
title=3D"Introduction">

         =
<t>Version 02 of the Problem Resolution draft<xref =
target=3D"refs.resolve" />

         =
<list style=3D"symbols">

          &nb=
sp; <t>a</t>

          &nb=
sp; <t>b</t>

          &nb=
sp; <t>c</t>

          &nb=
sp; <t>d</t>

          &nb=
sp; <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:mrose+int=
ernet.xml2rfc@dbc.mtview.ca.us] 

> 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=3D'yes'?>

>     <?rfc =
subcompact=3D'no'?>

>     

> right before the

>     

>     <rfc>

>     

> /mtr

> 




------_=_NextPart_001_01C37722.4F3DC52C--


From: mrose+internet.xml2rfc@dbc.mtview.ca.us (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: <4103264BC8D3D51180B7002048400C450162376A@zhard0jd.europe.nortel.com>
References: <4103264BC8D3D51180B7002048400C450162376A@zhard0jd.europe.nortel.com>
Message-ID: <20030909144347.64e9c899.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> I have been unable to create lists of short items without a blank line
> between the items (except by using  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
    
    
    
    
right before the
    
    
    
/mtr


From: elwynd@nortelnetworks.com (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: <4103264BC8D3D51180B7002048400C450162376A@zhard0jd.europe.nortel.com>

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  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:
elwynd@nortelnetworks.com
        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






Feature request: Ability to have list items without intervening =
blank lines



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: elwynd@nortelnetworks.com

        Harlow =
Laboratories     =
        =
        =
        =
ESN           &nb=
sp;         6-742-5498

        London Road, =
Harlow,            =
        =
        Direct =
Line             =
+44-1279-405498

        Essex, CM17 =
9NA, UK     =
        =
        =
Fax           &nb=
sp;         +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.

=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






------_=_NextPart_001_01C37716.6DBF2498--


From: clive@demon.net (Clive D.W. Feather)
Date: Tue, 9 Sep 2003 20:24:42 +0100
Subject: [xml2rfc] Email addresses
Message-ID: <20030909192442.GA92342@finch-staff-1.thus.net>

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:     | Tel:    +44 20 8495 6138
Internet Expert     | Home:    | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646


From: falk@isi.edu (Aaron Falk)
Date: Tue, 9 Sep 2003 11:37:19 -0700
Subject: [xml2rfc] submitting xml to rfc-editor
Message-ID: <20030909183719.GD18884@isi.edu>

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: carl@media.org (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: <3F5BEA6B.4050107@cs.columbia.edu>
Message-ID: <200309080400.h8840Je0022068@bulk.resource.org>

Hi Henning -

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


  
  
  

]>

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
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 


From: hgs@cs.columbia.edu (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: <3F5BEA6B.4050107@cs.columbia.edu>

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: swb@employees.org (Scott W Brim)
Date: Wed, 3 Sep 2003 13:57:46 -0400
Subject: [xml2rfc] Reference indicator format
In-Reply-To: <78772088.1062596396@scan.jck.com>; from john+xml@jck.com on Wed, Sep 03, 2003 at 01:39:56PM -0400
References:  <78772088.1062596396@scan.jck.com>
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 
>  wrote:
> 
> > Try adding the following processor instructions to the top of
> > your XML file:
> >
> > 
> > 
> >
> > These are shown in
> > , 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: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Wed, 3 Sep 2003 10:57:25 -0700
Subject: [xml2rfc] Reference indicator format
In-Reply-To: <78772088.1062596396@scan.jck.com>
References:  <78772088.1062596396@scan.jck.com>
Message-ID: <20030903105725.7e4dc2c9.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> 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 , 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: john+xml@jck.com (John C Klensin)
Date: Wed, 03 Sep 2003 13:39:56 -0400
Subject: [xml2rfc] Reference indicator format
In-Reply-To: 
References: 
Message-ID: <78772088.1062596396@scan.jck.com>

--On Tuesday, 02 September, 2003 19:12 -0700 Dan Kohn 
 wrote:

> Try adding the following processor instructions to the top of
> your XML file:
>
> 
> 
>
> These are shown in
> , 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: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Wed, 3 Sep 2003 10:31:18 -0700
Subject: [xml2rfc] 3gpp bibxml now online
Message-ID: <20030903103118.5d21a7a4.mrose+internet.xml2rfc@dbc.mtview.ca.us>

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: dan@dankohn.com (Dan Kohn)
Date: Tue, 2 Sep 2003 19:12:36 -0700
Subject: [xml2rfc] Reference indicator format
Message-ID: 

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




These are shown in , which
is I believe is part of the default download.

          - dan
--
Dan Kohn 
  
-----Original Message-----
From: John C Klensin [mailto:john+xml@jck.com] 
Sent: Tuesday, September 02, 2003 16:39
To: xml2rfc@lists.xml.resource.org
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.

	

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

	 RFC1035 

Gives me
   RFC1035 [3]

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

	<reference anchor="RFC1035" >
	<!-- title="RFC1035" -->
	   <front>
	   <title abbrev="RFC1035"> Domain names -
	implementation and specification    

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
xml2rfc@lists.xml.resource.org
http://lists.xml.resource.org/mailman/listinfo/xml2rfc




From: john+xml@jck.com (John C Klensin)
Date: Tue, 02 Sep 2003 19:39:02 -0400
Subject: [xml2rfc] Reference indicator format
In-Reply-To: <4103264BC8D3D51180B7002048400C4501623662@zhard0jd.europe.nortel.com>
References: <4103264BC8D3D51180B7002048400C4501623662@zhard0jd.eu rope.nortel.com>
Message-ID: <13919595.1062531542@scan.jck.com>

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.

	

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

	 RFC1035 

Gives me
   RFC1035 [3]

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

	<reference anchor="RFC1035" >
	<!-- title="RFC1035" -->
	   <front>
	   <title abbrev="RFC1035"> Domain names -
	implementation and specification    

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