Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[Russ White]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


>> If
>> we had a DTD that worked in other pieces of software, it could be
>> converted using commonly available software into text formats.
> 
> What is supplied with xml2rfc works fine with other pieces of software,
> per Ned's response.

Perhaps I should email Ned I've tried pulling the DTD into
Dreamweaver several times, with no success. I did email the list once,
and the response I received was along the lines of, "if you get that
working, a lot of people would be happy." I never received a response
saying, "it works, and this is the way you need to pull the DTD in."

Of course, we might be talking about two different things. You can use
Dreamweaver as a text editor on the DTD, but you can't do the same thing
you do in XMLMind, which is to have the sections set out in the other
editing modes. I can use emacs if I'm going to have to memorize all the
sections, and how to put them together--no need to use Dreamweaver as a
text editor.

:-)

Russ

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpVNh4ACgkQER27sUhU9OQUbgCdHerc1DviaFiw99qXKTlYBTq3
qJAAoMkBTrGxLC4pmLtU6TcBDAs0Nd3H
=bJX8
-END PGP SIGNATURE-
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[Yaakov Stein]

Patrik,

> Problem with LaTeX and TeX is the need for class libraries, 

How is that different from needing the latest tcl code for xml2rfc ?

> and the lack of agreed upon way of distributing a 
> LaTeX/TeX file with the class files needed (part from what is "standard"), 
> or lack of automatic tools that include needed things from the class files to 
> the source file.

Still nowhere near the combination of opaque processing instructions needed for 
xml2rfc.

Something like \documentclass[std,trust200902]{RFC} at the top of the file
is all that would be needed.

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[Dave CROCKER]

Russ White wrote:

If
we had a DTD that worked in other pieces of software, it could be
converted using commonly available software into text formats.


What is supplied with xml2rfc works fine with other pieces of software, per 
Ned's response.




The
problem, from my perspective, isn't the format, it's the lack of tools
to work in that format, at this point.


There are plenty of tools that work just fine with it.



d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[ned+ietf]

> > My apologies for the subject line. I'm very disappointed that the silent
> > majority of draft authors isn't speaking up. I can't imagine that the
> > vast majority of draft authors has absolutely no problems with XML2RFC.
> > So I'm assuming they've been ignoring the thread, hopefully the new
> > subject line will get some of them to chime in. If that doesn't happen
> > I'll shut up and try to figure out why I have so much trouble with
> > something that nobody else finds difficult.

> I don't mind the XML part of writing the drafts, it's just annoying that
> so few DTDs are available to edit the things. There are a ton of
> commercial XML editors out there--Word, Dreamweaver, and many others.

That's actually part of the problem - there are so many XML-capable
tools that providing directions for even a reasonable subset would be
very challenging.

> But, not being an XML expert, I don't know how to get a DTD to work in
> any of these software packages, so editing the XML side is a matter of
> hand coding it. 

I'm a little unclear on how configuring an XML editor to know about a DTD, or
Schema, or Relax grammar is a matter of having sufficient XML expertise. It's
mostly a matter of knowing how to use your tools. If this is truly hard to do
it's a problem with the documentation for whatever tool you're using.

FWIW, in many cases it's simply a mattter of parking the DTD or Schema in the
same directory where your XML sources are.

I use four different XML-aware editors, two of them - BBEdit and Exchanger -
quite regularly, and I've had no real problems getting this set up. The (free)
BBedit XML validation plugin is a little annoying in that it puts the material
to validate in a temporary file before invoking the validator, meaning the
coresident file trick doesn't work. But a simple google search turns up a
reasonable solution - use a URL with an explicit path in the DOCTYPE
declaration.

Exchanger handles this especially well, I think. Most of the time it finds the
DTD without any trouble, but when it can't it simply prompts for the location,
and remembers it after that. It also supports specifying the location in the
source file if that's more to your taste.

> I think a lot of the problem is the issues with editing these things. If
> we had a DTD that worked in other pieces of software, it could be
> converted using commonly available software into text formats. The
> problem, from my perspective, isn't the format, it's the lack of tools
> to work in that format, at this point.

I've had no trouble using either the DTD or the Relax grammar that comes with
the xml2rfc distro.

Ned
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)

[Wes Hardaker]

> On Mon, 6 Jul 2009 10:18:14 +0300, Lars Eggert  
> said:

LE> I'm fully open to trying something new once someone creates a
LE> different ("better") tool, but until then, xml2rfc is OK.

I'd even argue that the xml2rfc language is pretty good and fairly
flexible.  I've run into a number of things I'd like to force it to do
that are mildly difficult, but in the end I've been happy with the
language.

It's the tool that needs a rewrite, IMHO.  Don't get me wrong, it's
taken us a long way and we wouldn't be as far forward in interoperable ID
authorship if it weren't for the existing tool.  However, like all good
prototypes eventually you need to take what you've learned and rewrite
it to fix the problems.  I've been tempted to take on the task myself,
but don't have the allocated time to make it happen.  (and it certainly
wouldn't be in TCL, as that's about my least preferred language of the
large number of languages I've written code in; no offense to TCL lovers).
-- 
Wes Hardaker
Cobham Analytic Solutions
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[Russ White]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


> My apologies for the subject line. I'm very disappointed that the silent
> majority of draft authors isn't speaking up. I can't imagine that the
> vast majority of draft authors has absolutely no problems with XML2RFC.
> So I'm assuming they've been ignoring the thread, hopefully the new
> subject line will get some of them to chime in. If that doesn't happen
> I'll shut up and try to figure out why I have so much trouble with
> something that nobody else finds difficult.

I don't mind the XML part of writing the drafts, it's just annoying that
so few DTDs are available to edit the things. There are a ton of
commercial XML editors out there--Word, Dreamweaver, and many others.
But, not being an XML expert, I don't know how to get a DTD to work in
any of these software packages, so editing the XML side is a matter of
hand coding it. 

I think a lot of the problem is the issues with editing these things. If
we had a DTD that worked in other pieces of software, it could be
converted using commonly available software into text formats. The
problem, from my perspective, isn't the format, it's the lack of tools
to work in that format, at this point.

:-)

Russ
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpTWmkACgkQER27sUhU9ORlnwCdF1PckJKO7f0vRO6JdJ2UPdJ+
s/QAmQHnUXbr/DoOPj0YF9YRwkAIPlIU
=72jr
-END PGP SIGNATURE-
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)

[Julian Reschke]

Mark Andrews wrote:

In message <4a544405.8020...@gmx.de>, Julian Reschke writes:

Mark Andrews wrote:

I had wierd results with the following just printing out "Zone" and
not the rest of the lines in the table.


  Zone
  10.IN-ADDR.ARPA
  16.172.IN-ADDR.ARPA
  17.172.IN-ADDR.ARPA
...
That's a bug in the texttable processing code, which I'm currently 
fixing (download the new version later today...). Thanks for the report.


Will do.


(I just published the new release)


IPv6 reverse addresses are long.  Break and indent.  If you have
a better way I would be happy to hear it.


  Zone
  0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\
  0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
  1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\
  0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA



Ok, that's an interesting case where non-breaking spaces are needed as a 
last resort.


Also, this case would be simpler if  allowed , so you 
wouldn't need to split the contents into two table cells (which *will* 
look weird when read in HTML...).


...but then, we may be getting off-topic here, so if people want to 
discuss the xml2rfc vocabulary or the tools in more details we probably 
should move over to the xml2rfc mailing list.


BR, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)

[Mark Andrews]

In message <4a544405.8020...@gmx.de>, Julian Reschke writes:
> Mark Andrews wrote:
> > I had wierd results with the following just printing out "Zone" and
> > not the rest of the lines in the table.
> > 
> > 
> >   Zone
> >   10.IN-ADDR.ARPA
> >   16.172.IN-ADDR.ARPA
> >   17.172.IN-ADDR.ARPA
> > ...
> 
> That's a bug in the texttable processing code, which I'm currently 
> fixing (download the new version later today...). Thanks for the report.

Will do.

> > ...
> > Also how do you do the equivalent of "" in
> > xml?
> >  ...
> 
> If you reference the rfc2629.dtd (as shipping with xml2rfc.tcl), it 
> should work out of the box, as rfc2629-xhtml.ent defines that entity.
> 
> Otherwise, just substitute with: "".
> 
> Out of curiosity: where do you need that?

IPv6 reverse addresses are long.  Break and indent.  If you have
a better way I would be happy to hear it.


  Zone
  0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\
  0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
  1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\
  0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA



> BR, Julian
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)

[Julian Reschke]

Mark Andrews wrote:

I had wierd results with the following just printing out "Zone" and
not the rest of the lines in the table.


  Zone
  10.IN-ADDR.ARPA
  16.172.IN-ADDR.ARPA
  17.172.IN-ADDR.ARPA
...


That's a bug in the texttable processing code, which I'm currently 
fixing (download the new version later today...). Thanks for the report.



...
Also how do you do the equivalent of "" in
xml?
 ...


If you reference the rfc2629.dtd (as shipping with xml2rfc.tcl), it 
should work out of the box, as rfc2629-xhtml.ent defines that entity.


Otherwise, just substitute with: "".

Out of curiosity: where do you need that?

BR, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)

[Mark Andrews]

In message <200907080044.n680ir6n028...@drugs.dv.isc.org>, Mark Andrews writes:
> 
> In message <4a537666.7060...@att.com>, Tony Hansen writes:
> > I also had to copy rfc2629-other.ent, rfc2629-xhtml.ent and rfc2629.dtd
> > into the current directory to get it to work. And Firefox seems to be
> > pickier than IE about the XML it will accept.
> > 
> > Otherwise pretty cool.
> > 
> > Tony Hansen
> > t...@att.com
> 
> I had wierd results with the following just printing out "Zone" and
> not the rest of the lines in the table.
> 
> 
>   Zone
>   10.IN-ADDR.ARPA
>   16.172.IN-ADDR.ARPA
>   17.172.IN-ADDR.ARPA
>   18.172.IN-ADDR.ARPA
>   19.172.IN-ADDR.ARPA
>   20.172.IN-ADDR.ARPA
>   21.172.IN-ADDR.ARPA
>   22.172.IN-ADDR.ARPA
>   23.172.IN-ADDR.ARPA
>   24.172.IN-ADDR.ARPA
>   25.172.IN-ADDR.ARPA
>   26.172.IN-ADDR.ARPA
>   27.172.IN-ADDR.ARPA
>   28.172.IN-ADDR.ARPA
>   29.172.IN-ADDR.ARPA
>   30.172.IN-ADDR.ARPA
>   31.172.IN-ADDR.ARPA
>   168.192.IN-ADDR.ARPA
> 

I should add if I add a second column the full table is discplayed.

> Also how do you do the equivalent of "" in
> xml?
>  
> > Julian Reschke wrote:
> > > Julian Reschke wrote:
> > >> Again: it's much easier to test using any recent web browser, and
> > >> using rfc2629.xslt. Just press F5 (refresh) in the browser window, and
> > >> there you go.
> > >>
> > >> BR, Julian
> > >> ...
> > > 
> > > OK, I have been told off-list that this needs more explanation...
> > > 
> > > rfc2629.xslt implements the xml2rfc vocabulary in XSLT, which all major
> > > browsers nowadays implement.
> > > 
> > > Thus, you can simply open the XML in the browser, and let the browser
> > > convert to HTML.
> > > 
> > > To do so:
> > > 
> > > 1) Add the XML Stylesheet Processing Instruction to the top of the
> > > source file, such as in:
> > > 
> > >   
> > > 
> > > (after the XML declaration, when present)
> > > 
> > > 2) Copy rfc2629.xslt to the folder where the xml2rfc source file resides
> > > (get it from ).
> > > 
> > > 3) Open the XML file in IE/Firefox/Safari/Opera.
> > > 
> > > More info:  >
> > > 
> > > NOTE: rfc2629.xslt does not support xml2rfc's "include" processing
> > > instruction, thus external references will only work using the XML
> > > entity inclusion mechanism (see , "Including
> > > Files").
> > > 
> > > BR, Julian
> > 
> > ___
> > Ietf mailing list
> > Ietf@ietf.org
> > https://www.ietf.org/mailman/listinfo/ietf
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)

[Mark Andrews]

In message <4a537666.7060...@att.com>, Tony Hansen writes:
> I also had to copy rfc2629-other.ent, rfc2629-xhtml.ent and rfc2629.dtd
> into the current directory to get it to work. And Firefox seems to be
> pickier than IE about the XML it will accept.
> 
> Otherwise pretty cool.
> 
>   Tony Hansen
>   t...@att.com

I had wierd results with the following just printing out "Zone" and
not the rest of the lines in the table.


  Zone
  10.IN-ADDR.ARPA
  16.172.IN-ADDR.ARPA
  17.172.IN-ADDR.ARPA
  18.172.IN-ADDR.ARPA
  19.172.IN-ADDR.ARPA
  20.172.IN-ADDR.ARPA
  21.172.IN-ADDR.ARPA
  22.172.IN-ADDR.ARPA
  23.172.IN-ADDR.ARPA
  24.172.IN-ADDR.ARPA
  25.172.IN-ADDR.ARPA
  26.172.IN-ADDR.ARPA
  27.172.IN-ADDR.ARPA
  28.172.IN-ADDR.ARPA
  29.172.IN-ADDR.ARPA
  30.172.IN-ADDR.ARPA
  31.172.IN-ADDR.ARPA
  168.192.IN-ADDR.ARPA


Also how do you do the equivalent of "" in
xml?
 
> Julian Reschke wrote:
> > Julian Reschke wrote:
> >> Again: it's much easier to test using any recent web browser, and
> >> using rfc2629.xslt. Just press F5 (refresh) in the browser window, and
> >> there you go.
> >>
> >> BR, Julian
> >> ...
> > 
> > OK, I have been told off-list that this needs more explanation...
> > 
> > rfc2629.xslt implements the xml2rfc vocabulary in XSLT, which all major
> > browsers nowadays implement.
> > 
> > Thus, you can simply open the XML in the browser, and let the browser
> > convert to HTML.
> > 
> > To do so:
> > 
> > 1) Add the XML Stylesheet Processing Instruction to the top of the
> > source file, such as in:
> > 
> >   
> > 
> > (after the XML declaration, when present)
> > 
> > 2) Copy rfc2629.xslt to the folder where the xml2rfc source file resides
> > (get it from ).
> > 
> > 3) Open the XML file in IE/Firefox/Safari/Opera.
> > 
> > More info: 
> > 
> > NOTE: rfc2629.xslt does not support xml2rfc's "include" processing
> > instruction, thus external references will only work using the XML
> > entity inclusion mechanism (see , "Including
> > Files").
> > 
> > BR, Julian
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)

[Julian Reschke]

Tony Hansen wrote:

I also had to copy rfc2629-other.ent, rfc2629-xhtml.ent and rfc2629.dtd
into the current directory to get it to work. And Firefox seems to be


That hasn't got anything to do with the XSLT, but with the fact that the 
browsers use proper XML parsers, while xml2rfc does not (which really is 
frustrating).



pickier than IE about the XML it will accept.


Both browsers may differ on how they handle the DTD. If you've got an 
example I should look it, please email it.



Otherwise pretty cool.


Thanks!

BR, Julian

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)

[Tony Hansen]

I also had to copy rfc2629-other.ent, rfc2629-xhtml.ent and rfc2629.dtd
into the current directory to get it to work. And Firefox seems to be
pickier than IE about the XML it will accept.

Otherwise pretty cool.

Tony Hansen
t...@att.com

Julian Reschke wrote:
> Julian Reschke wrote:
>> Again: it's much easier to test using any recent web browser, and
>> using rfc2629.xslt. Just press F5 (refresh) in the browser window, and
>> there you go.
>>
>> BR, Julian
>> ...
> 
> OK, I have been told off-list that this needs more explanation...
> 
> rfc2629.xslt implements the xml2rfc vocabulary in XSLT, which all major
> browsers nowadays implement.
> 
> Thus, you can simply open the XML in the browser, and let the browser
> convert to HTML.
> 
> To do so:
> 
> 1) Add the XML Stylesheet Processing Instruction to the top of the
> source file, such as in:
> 
>   
> 
> (after the XML declaration, when present)
> 
> 2) Copy rfc2629.xslt to the folder where the xml2rfc source file resides
> (get it from ).
> 
> 3) Open the XML file in IE/Firefox/Safari/Opera.
> 
> More info: 
> 
> NOTE: rfc2629.xslt does not support xml2rfc's "include" processing
> instruction, thus external references will only work using the XML
> entity inclusion mechanism (see , "Including
> Files").
> 
> BR, Julian

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)

[Julian Reschke]

Iljitsch van Beijnum wrote:

On 7 jul 2009, at 15:30, Julian Reschke wrote:

Thus, you can simply open the XML in the browser, and let the browser 
convert to HTML.


Notwithstanding everything else I've said, this is pretty cool, makes it 
much easier to find problems in the XML.


Is this kind of stuff covered in the XML2RFC intro at IETF-75?


I think it was mentioned in previous intros, but I'm not sure.

That being said, I'll probably be there, and will be happy to explain 
and demo things if there's time available.


BR, Julian



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)

[Iljitsch van Beijnum]

On 7 jul 2009, at 15:30, Julian Reschke wrote:

Thus, you can simply open the XML in the browser, and let the  
browser convert to HTML.


Notwithstanding everything else I've said, this is pretty cool, makes  
it much easier to find problems in the XML.


Is this kind of stuff covered in the XML2RFC intro at IETF-75?
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)

[Julian Reschke]

Julian Reschke wrote:
Again: it's much easier to test using any recent web browser, and using 
rfc2629.xslt. Just press F5 (refresh) in the browser window, and there 
you go.


BR, Julian
...


OK, I have been told off-list that this needs more explanation...

rfc2629.xslt implements the xml2rfc vocabulary in XSLT, which all major 
browsers nowadays implement.


Thus, you can simply open the XML in the browser, and let the browser 
convert to HTML.


To do so:

1) Add the XML Stylesheet Processing Instruction to the top of the 
source file, such as in:


  

(after the XML declaration, when present)

2) Copy rfc2629.xslt to the folder where the xml2rfc source file resides 
(get it from ).


3) Open the XML file in IE/Firefox/Safari/Opera.

More info: 

NOTE: rfc2629.xslt does not support xml2rfc's "include" processing 
instruction, thus external references will only work using the XML 
entity inclusion mechanism (see , "Including 
Files").


BR, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)

[Julian Reschke]

Wes Beebee (wbeebee) wrote:

I created an xml2rfc template, like those available on xml.resource.org,
which I copy and modify for new drafts, and use the web version of the
tool - and everything works well enough for me.

I'm decidedly not picky about formatting, because I want to spend my
time contributing content.

Because sometimes the error messages can be cryptic, when modifying the
XML tags, I frequently submit the document and generate HTML in order to
bound the number of XML tags that can contribute to a problem.

- Wes
...


Again: it's much easier to test using any recent web browser, and using 
rfc2629.xslt. Just press F5 (refresh) in the browser window, and there 
you go.


BR, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)

[Wes Beebee (wbeebee)]

I created an xml2rfc template, like those available on xml.resource.org,
which I copy and modify for new drafts, and use the web version of the
tool - and everything works well enough for me.

I'm decidedly not picky about formatting, because I want to spend my
time contributing content.

Because sometimes the error messages can be cryptic, when modifying the
XML tags, I frequently submit the document and generate HTML in order to
bound the number of XML tags that can contribute to a problem.

- Wes

-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Tim Bray
Sent: Tuesday, July 07, 2009 12:26 AM
To: Lars Eggert
Cc: Iljitsch van Beijnum; IETF Discussion Mailing List
Subject: Re: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two
different threads - IETF Document Format)

On Mon, Jul 6, 2009 at 12:18 AM, Lars Eggert
wrote:

> since you asked: I have absolutely no problems with xml2rfc.
>
> I used to edit in nroff, which wasn't compatible with my brain, and I 
> used Joe's Word template, which works OK, but I prefer something 
> ASCII-based for collaborative editing (for svn, diff, etc.)
>
> I'm fully open to trying something new once someone creates a 
> different
> ("better") tool, but until then, xml2rfc is OK.

What Lars said. -T
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[John C Klensin]

--On Sunday, July 05, 2009 12:01 -0400 "Joel M. Halpern"
 wrote:

> Having written a moderate number of drafts, using a number of
> tools, I find that I strongly prefer using XML2RFC.
>...
> The current procedures allow for XML2RFC, Word, NROFF, and
> manual text (if you really want.)  Yes, to use any one of
> those you have to figure out some idiosyncrasies of the
> particular approach.  So I am very confused why you are asking
> us to kill a tool that was produced by volunteers, works very
> well, and that many people use by choice.
> 
> I have seen some folks arguing that we should make XML2RFC
> normative and mandatory.  If they can figure out how to
> automatically and accurate convert the other mechanisms people
> use, then that can be considered. Otherwise, mandating would
> be inappropriate, as some folks do indeed find it difficult.
>...

+1

I also believe that some documents may argue for different
tools.  In one document I've had to work on recently, I've had
to use the xml2rfc-> nroff -> text path (or could have started
in nroff), and it doesn't make me very happy.  But that is, at
most, an argument for improving xml2rfc, not for getting rid of
it.

I do believe that we need to [regularly] reexamine the content
and format requirements for I-Ds to be sure that no set of tools
is inadvertently excluded or made more burdensome, but that is a
separate issue.


--On Monday, July 06, 2009 09:42 -0400 "Livingood, Jason"
 wrote:

> How frequently do any of us work when we're not connected to
> the Internet? 
>...

Quite a lot, actually.  And it is why, as pointed out in an
earlier note, I think xml2rfc would benefit from a "report and
move on" strategy for dealing with external entity references
that cannot be retrieved and/or from a directive or attribute
that would permit use of a text placeholder as the body of a
 element in documents under development rather than
the formal structure now required.  But the tool is quite usable
without those enhancements and, even when I'm working offline
for an extended period, I haven't found that "edit offline,
compile after I get back on line" is a serious impediment to
getting work done.

   john




___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)

[Tim Bray]

On Mon, Jul 6, 2009 at 12:18 AM, Lars Eggert wrote:

> since you asked: I have absolutely no problems with xml2rfc.
>
> I used to edit in nroff, which wasn't compatible with my brain, and I used
> Joe's Word template, which works OK, but I prefer something ASCII-based for
> collaborative editing (for svn, diff, etc.)
>
> I'm fully open to trying something new once someone creates a different
> ("better") tool, but until then, xml2rfc is OK.

What Lars said. -T
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[Tony Hain]

Hadriel is right... I quit using xmlmind (never installed on the new
machine) because I should not be focusing on formatting nonsense when I
should be focusing on generating the correct content. Getting the arcane
systax correct always takes me half a day because I am not constantly
writing drafts. 

I am not opposed to tools like xml2rfc in general, but that implementation
(even using something like xmlmind with the appropriate filter) represents a
giant leap backward to the early 80's world of document creation. As far as
I am concerned xml2rfc represents a first step, but we must not stop there. 

Tony

> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
> Hadriel Kaplan
> Sent: Sunday, July 05, 2009 4:26 PM
> To: Joel M. Halpern; Iljitsch van Beijnum
> Cc: IETF Discussion Mailing List
> Subject: RE: XML2RFC must die, was: Re: Two different threads - IETF
> Document Format
> 
> 
> > At 11:01 AM 7/5/2009, Joel M. Halpern wrote:
> > >I have seen some folks arguing that we should make XML2RFC normative
> > >and mandatory.  If they can figure out how to automatically and
> > >accurate convert the other mechanisms people use, then that can be
> > >considered. Otherwise, mandating would be inappropriate, as some
> > >folks do indeed find it difficult.
> 
> +1
> 
> For those who are used to MS-Word, XMLMind is frustrating and truly
> requires an XML mind.  Even simple things like cut/paste are done in a
> very different (and frankly inconsistent) way, as are references and
> such.  In theory a WYSIWYG word processor shouldn't require an author
> to know the internal representation and underlying language of the
> document format.
> 
> I know a large number if not outright majority of IETF authors do not
> use MS-Word, so XML2RFC is a fine *option* - but please don't ever
> *mandate* it and force the rest of us have to write documents in a
> syntax only a tiny fraction of the planet uses and understands.
> 
> -hadriel
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)

[Dave CROCKER]

Eric Rosen wrote:

Lars> since you asked: I have absolutely no problems with xml2rfc.

I find  that xml2rfc  takes too  much control over  the boilerplate  and the
references to  be a  really useful  tool.  



Given how extensive and strong the support for using it is, your assertion is 
demonstrably incorrect.  On the other hand, that some folk might not like using 
it is demonstrably correct.


d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)

[Eric Rosen]

Lars> since you asked: I have absolutely no problems with xml2rfc.

I find  that xml2rfc  takes too  much control over  the boilerplate  and the
references to  be a  really useful  tool.  I dropped  it after  one attempt.
However, many  of my  colleagues use it,  and as  a result I've  gotten many
questions of the form  "what do I have to do to  make xml2rfc produce output
that  will pass  idnits?".  I  can't tell  them "just  put in  the following
boilerplate", instead  I've had to figure  out the right value  of the "ipr"
variable.  (BTW, no one ever  cares what the boilerplate actually says, just
whether it will  pass idnits; xml2rfc really encourages  folks to ignore the
semantics of the boilerplate.) 

Joel> One large draft I was working on was originally written using WORD.  I
Joel> found it extremely  difficult to work with (although  I have a current
Joel> version  of  Word available  at  all  times.)   Instead, working  with
Joel> another author we converted the document to XML for XML2RFC.

Hey, I've converted  from both Word and  XML to nroff; that way  I don't get
any surprises  ;-) OTOH, I  have to admit  that nroff was a  bit challenging
when I moved from Solaris to Linux.

Joel> I have seen  some folks arguing that we  should make XML2RFC normative
Joel> and mandatory.

Of course,  in the  IETF it  is very common  for folks  to think  that their
personal preferences are objectively superior.  


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[Livingood, Jason]

> My apologies for the subject line. I'm very disappointed that the
> silent majority of draft authors isn't speaking up. I can't imagine
> that the vast majority of draft authors has absolutely no problems
> with XML2RFC. So I'm assuming they've been ignoring the thread,
> hopefully the new subject line will get some of them to chime in.

I was ignoring it and hoping it went away.  ;-)

I started off using the MS Word template and CRLF to output txt documents.
I found this to be a PITA.  About 9 months ago I switched to xml2rfc and
found it to be great.  Yes, it had a learning curve and the error messages
could be better, but the learning curve is not terrible IMHO and you
eventually get to figure out what the errors mean after awhile.  My
productivity gains in writing and editing drafts is much higher than with MS
Word, though I miss some of Word's built-in change acceptance/rejection
functionality (doing an xml diff is fine, just different).

I also love being able to define both external links and internal anchors so
easily.  Just the internal reference linking has saved me time in post
version -00 docs when I move sections or sentences around and needn't worry
about keeping track of what section was what number.  And it is also nice to
be able to share an HTML version of the doc with co-authors and reviewers,
rather than a txt doc with no working links.

I happen to use Coda on the Mac and use it to write HTML and other scripting
stuff.  YMMV.

> No, it's not. The problem with XML2RFC formatted drafts and RFCs is
> that you can't display them reasonably without using XML2RFC, and
> although XML2RFC can run on many systems in theory, in practice it's
> very difficult to install and run successfully because it's written in
> TCL and many XML2RFC files depend on the local availability of
> references. When those aren't present the conversion fails.

How frequently do any of us work when we're not connected to the Internet?
I just have my XML editor open in one window and the web-based xml2rfc tool
in the other, and every time I make a significant change, I just re-run it
to display an HTML version of the document.  This tends to also make
error-investigation easier since I know what I just changed and can then
review a specific section to find my error.

> those tools. So I write my XML2RFC source by hand. The result is that
> I invariably get error messages that the  and  tags
> don't match properly. This is a problem that is extremely hard to
> debug manually, especially as just grepping for "section" isn't
> enough: there could be a ,  etc somewhere between a
>  and  that breaks everything.

This is most likely a nested section tag problem.  When you write your XML
do you have every "flat" and justified left?  If so, I'd recommend you
tab-in sections and keep your open and close tags lined up, as well as any
tags within each section tabbed in further.

> What we need is the ability to write drafts with a standard issue word
> processor. 

You mean like the template and directions available for MS Word?  Why not
just use that?  

Jason

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[Lou Berger]

I *strongly* support "please don't ever *mandate* it [XML2RFC]".

Although, I'm perfectly happy using the obscure syntax of nroff (when
combined with a set of macros I received from George Swallow about 10-12
years ago).  I produced a couple of drafts using xml and decided that
nroff was much easier and let me focus on the the document rather than
the document production...

Lou

On 7/5/2009 7:25 PM, Hadriel Kaplan wrote:
>> At 11:01 AM 7/5/2009, Joel M. Halpern wrote:
>>> I have seen some folks arguing that we should make XML2RFC normative
>>> and mandatory.  If they can figure out how to automatically and
>>> accurate convert the other mechanisms people use, then that can be
>>> considered. Otherwise, mandating would be inappropriate, as some
>>> folks do indeed find it difficult.
> 
> +1
> 
> For those who are used to MS-Word, XMLMind is frustrating and truly requires 
> an XML mind.  Even simple things like cut/paste are done in a very different 
> (and frankly inconsistent) way, as are references and such.  In theory a 
> WYSIWYG word processor shouldn't require an author to know the internal 
> representation and underlying language of the document format.
> 
> I know a large number if not outright majority of IETF authors do not use 
> MS-Word, so XML2RFC is a fine *option* - but please don't ever *mandate* it 
> and force the rest of us have to write documents in a syntax only a tiny 
> fraction of the planet uses and understands.
> 
> -hadriel
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 
> 
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[Julian Reschke]

Shane Kerr wrote:

...
I had my first experience with xml2rfc recently, and I largely agree.
It's easy to totally screw up a document by misplaced XML, xml2rfc


Yes.


doesn't handle non-ASCII very well (important for some names), the error


That's an IETF doc format restriction, not an xml2rfc problem per se.


output is non-intuitive, the tool didn't work off-line (no fun on an
airplane), and so on.


It does work offline, unless your source requires non-local files (like 
external references).



...


BR, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[Shane Kerr]

Iljitsch,

On Sun, 2009-07-05 at 15:24 +0200, Iljitsch van Beijnum wrote:
> My apologies for the subject line. I'm very disappointed that the  
> silent majority of draft authors isn't speaking up. I can't imagine  
> that the vast majority of draft authors has absolutely no problems  
> with XML2RFC. So I'm assuming they've been ignoring the thread,  
> hopefully the new subject line will get some of them to chime in. If  
> that doesn't happen I'll shut up and try to figure out why I have so  
> much trouble with something that nobody else finds difficult.

I had my first experience with xml2rfc recently, and I largely agree.
It's easy to totally screw up a document by misplaced XML, xml2rfc
doesn't handle non-ASCII very well (important for some names), the error
output is non-intuitive, the tool didn't work off-line (no fun on an
airplane), and so on.

It seems to get in the way of writing the actual draft.

Maybe there is no better way, but it seems hard to believe. (I am more
willing to believe that there is no better way *now*, but that one may
be found in the future.) Making it harder on authors (of which we seem
to have plenty) in order to make things easier on editors and reviewers
(which seem in short supply) may be the right trade-off.

--
Shane

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[Stewart Bryant]

Colin Perkins wrote:


I have no significant problems using xml2rfc, and find it easier to 
write Internet-Drafts using xml2rfc than I did using nroff, LaTeX, or 
Microsoft Word.

+1

... and I am quite happy to use the online compiler.

Stewart
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)

[Dave Cridland]

On Mon Jul  6 08:46:24 2009, Julian Reschke wrote:
Also, we should keep in mind that xml2rfc can refer both to a  
specific XML vocabulary, and a set of tools.


The vocabulary is relatively straightforward, and has been extended  
by both MTR and others. At some point of time, we may want to work  
on a revision of it (that is, RFC 2629).



The vocabulary is basically sound. I sympathize with Iljitsch wanting  
finer control over the rendering of his name, which would need to be  
addressed here.


If a GUI WYSIWYG tool got created, I'd probably use it. If someone  
created an import filter for some word processor or another, I might  
use it, but I generally don't get on with word processors anymore. (I  
had an argument with one a few years ago, we never made up).



With respect to the tools: I usually do not worry about xml2rfc.tcl  
(the processor) until I need to submit something. Instead, I make  
sure that my source validates (against the DTD), and instead focus  
on content, and just review the HTML output, as produced by  
rfc2629.xslt. The latter works on any machine that has support for  
XSLT, such as any that can run IE6, Firefox 2, Opera 9, or Safari  
3. And no, you don't need a browser to run the XSLT, just install  
xsltproc or Saxon.



I do much the same, although because the document is in XML, I use a  
slightly extended format to include annotations to support finer  
reference handling and checking, which I scribbled some time back in  
XSLT. It gives me an extra stage to my processing, and annoys  
co-authors, but produces documents I know have the right references  
in the right sections.


XML purists will probably wail and gnash teeth, since I replaced the  
inclusion handling very early on with something probably even worse  
than the include PI, but that's the joy of XML.


Finally, regarding local installations of xml2rfc.tcl: at least on  
Windows, just install Cygwin, make sure TCL is included in the  
install, and it will work just fine.


There are also online versions, which eliminate the need to install  
it at all if you've got bandwidth.


I'm quite sure that both the file format and toolset could improve,  
but I thinks it's a very reasonable way of processing drafts as it  
is, and I've be very happy if it were eventually the only way.


FWIW, I suspect that the way I'm doing things - with an initial  
format and using the RFC 2629 format as an intermediate one - is  
probably the rough shape of things to come.


Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)

[Julian Reschke]

Lars Eggert wrote:

Hi,

On 2009-7-5, at 16:24, Iljitsch van Beijnum wrote:

My apologies for the subject line. I'm very disappointed that the
silent majority of draft authors isn't speaking up. I can't imagine
that the vast majority of draft authors has absolutely no problems
with XML2RFC. So I'm assuming they've been ignoring the thread,
hopefully the new subject line will get some of them to chime in.


since you asked: I have absolutely no problems with xml2rfc.

I used to edit in nroff, which wasn't compatible with my brain, and I 
used Joe's Word template, which works OK, but I prefer something 
ASCII-based for collaborative editing (for svn, diff, etc.)


I'm fully open to trying something new once someone creates a different 
("better") tool, but until then, xml2rfc is OK.


Indeed.

Also, we should keep in mind that xml2rfc can refer both to a specific 
XML vocabulary, and a set of tools.


The vocabulary is relatively straightforward, and has been extended by 
both MTR and others. At some point of time, we may want to work on a 
revision of it (that is, RFC 2629).


With respect to the tools: I usually do not worry about xml2rfc.tcl (the 
processor) until I need to submit something. Instead, I make sure that 
my source validates (against the DTD), and instead focus on content, and 
just review the HTML output, as produced by rfc2629.xslt. The latter 
works on any machine that has support for XSLT, such as any that can run 
IE6, Firefox 2, Opera 9, or Safari 3. And no, you don't need a browser 
to run the XSLT, just install xsltproc or Saxon.


Finally, regarding local installations of xml2rfc.tcl: at least on 
Windows, just install Cygwin, make sure TCL is included in the install, 
and it will work just fine.


BR, Julian


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)

[Lars Eggert]

Hi,

On 2009-7-5, at 16:24, Iljitsch van Beijnum wrote:

My apologies for the subject line. I'm very disappointed that the
silent majority of draft authors isn't speaking up. I can't imagine
that the vast majority of draft authors has absolutely no problems
with XML2RFC. So I'm assuming they've been ignoring the thread,
hopefully the new subject line will get some of them to chime in.


since you asked: I have absolutely no problems with xml2rfc.

I used to edit in nroff, which wasn't compatible with my brain, and I  
used Joe's Word template, which works OK, but I prefer something ASCII- 
based for collaborative editing (for svn, diff, etc.)


I'm fully open to trying something new once someone creates a  
different ("better") tool, but until then, xml2rfc is OK.


Lars

smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[Patrik Fältström]

On 6 jul 2009, at 09.01, Yaakov Stein wrote:


... and don't get me started on LaTeX.


I am not sure what problems you had with LaTeX, but as someone who has
written thousands of pages using TeX,
I can't imagine anything better for professional document preparation.

On the other hand, the learning curve is relatively steep,
and its full power is not needed for the plain text documents that
most people participating in this thread seem to be writing.


Problem with LaTeX and TeX is the need for class libraries, and the  
lack of agreed upon way of distributing a LaTeX/TeX file with the  
class files needed (part from what is "standard"), or lack of  
automatic tools that include needed things from the class files to the  
source file.


   Patrik



PGP.sig
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[Yaakov Stein]

> ... and don't get me started on LaTeX.

I am not sure what problems you had with LaTeX, but as someone who has
written thousands of pages using TeX,
I can't imagine anything better for professional document preparation.

On the other hand, the learning curve is relatively steep,
and its full power is not needed for the plain text documents that
most people participating in this thread seem to be writing.

Y(J)S
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[Stefan Santesson]

I also would be against mandating xml2rfc.

I do agree that certain aspects of xml2rfc are convenient, but when it comes
to edit text, I really prefer .nroff


On 09-07-05 8:16 PM, "ned+i...@mauve.mrochek.com"
 wrote:

> I particularly like the fact that xml2rfc lets me focus on the content of my
> drafts and spend very little time on presentation issues. I don't even want to
> think about how much time I've wasted piddling around with formattting nits
> when using nroff, and don't get me started on LaTeX.
> 
> Oh, and as for installing the software, I'm not a TCL fan, but even so I've
> done that on everything from  Mac OS 9 to Solaris to OpenVMS. I sure can't say
> the same for groff.

I hope to have provided a simple way to get around these issues with nroff
with the tool I wrote, as it makes it easy to do the formatting nits and
does not require groff or any other external tools to be installed.

/Stefan


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[Hadriel Kaplan]

> At 11:01 AM 7/5/2009, Joel M. Halpern wrote:
> >I have seen some folks arguing that we should make XML2RFC normative
> >and mandatory.  If they can figure out how to automatically and
> >accurate convert the other mechanisms people use, then that can be
> >considered. Otherwise, mandating would be inappropriate, as some
> >folks do indeed find it difficult.

+1

For those who are used to MS-Word, XMLMind is frustrating and truly requires an 
XML mind.  Even simple things like cut/paste are done in a very different (and 
frankly inconsistent) way, as are references and such.  In theory a WYSIWYG 
word processor shouldn't require an author to know the internal representation 
and underlying language of the document format.

I know a large number if not outright majority of IETF authors do not use 
MS-Word, so XML2RFC is a fine *option* - but please don't ever *mandate* it and 
force the rest of us have to write documents in a syntax only a tiny fraction 
of the planet uses and understands.

-hadriel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[Colin Perkins]

On 5 Jul 2009, at 20:52, James M. Polk wrote:

At 09:38 AM 7/5/2009, Colin Perkins wrote:

On 5 Jul 2009, at 14:24, Iljitsch van Beijnum wrote:

My apologies for the subject line. I'm very disappointed that the
silent majority of draft authors isn't speaking up. I can't imagine
that the vast majority of draft authors has absolutely no problems
with XML2RFC. So I'm assuming they've been ignoring the thread,
hopefully the new subject line will get some of them to chime in. If
that doesn't happen I'll shut up and try to figure out why I have so
much trouble with something that nobody else finds difficult.


I have no significant problems using xml2rfc, and find it easier to
write Internet-Drafts using xml2rfc than I did using nroff, LaTeX, or
Microsoft Word.

I also appreciate the added consistency in Internet-Draft formatting
that has resulted since xml2rfc has been widely adopted. This makes  
it

a lot easier to print drafts, since they have consistent page sizes
and form-feed characters.


huh?

the current boilerplate has the first page being 54 lines long, and  
subsequent pages being 57 lines long, but with the "footer" on the  
56th line, and not the 57th.


The "footer" on the first page isn't on the last line of the page  
either.


This isn't very uniform...  perhaps unless you use some special  
viewer to recreate this non-uniform display consistently.


It doesn't greatly offend me that the first page is three lines  
shorter than the other pages.  Nor does it confuse enscript, on those  
occasions when I want to print an internet-draft or RFC.


This is very much unlike the situation pre-xml2rfc, when the page  
length and width varied considerably for some drafts, and where form- 
feeds were often inconsistently applied.


--
Colin Perkins
http://csperkins.org/



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[Patrik Fältström]

I also support this view, and the reason why I think this is a good  
idea is that the likelyhood we will see MORE (professional) tools  
helping with the XML2RFC production if we do.


So I think it will help "both" views expressed on this list.

   Patrik

On 5 jul 2009, at 21.55, James M. Polk wrote:


+1

At 11:01 AM 7/5/2009, Joel M. Halpern wrote:
I have seen some folks arguing that we should make XML2RFC  
normative and mandatory.  If they can figure out how to  
automatically and accurate convert the other mechanisms people use,  
then that can be considered. Otherwise, mandating would be  
inappropriate, as some folks do indeed find it difficult.


Yours,
Joel M. Halpern

Iljitsch van Beijnum wrote:
My apologies for the subject line. I'm very disappointed that the  
silent majority of draft authors isn't speaking up. I can't  
imagine that the vast majority of draft authors has absolutely no  
problems with XML2RFC. So I'm assuming they've been ignoring the  
thread, hopefully the new subject line will get some of them to  
chime in. If that doesn't happen I'll shut up and try to figure  
out why I have so much trouble with something that nobody else  
finds difficult.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf




PGP.sig
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[James M. Polk]

+1

At 11:01 AM 7/5/2009, Joel M. Halpern wrote:
I have seen some folks arguing that we should make XML2RFC normative 
and mandatory.  If they can figure out how to automatically and 
accurate convert the other mechanisms people use, then that can be 
considered. Otherwise, mandating would be inappropriate, as some 
folks do indeed find it difficult.


Yours,
Joel M. Halpern

Iljitsch van Beijnum wrote:
My apologies for the subject line. I'm very disappointed that the 
silent majority of draft authors isn't speaking up. I can't imagine 
that the vast majority of draft authors has absolutely no problems 
with XML2RFC. So I'm assuming they've been ignoring the thread, 
hopefully the new subject line will get some of them to chime in. 
If that doesn't happen I'll shut up and try to figure out why I 
have so much trouble with something that nobody else finds difficult.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[James M. Polk]

At 09:38 AM 7/5/2009, Colin Perkins wrote:

On 5 Jul 2009, at 14:24, Iljitsch van Beijnum wrote:

My apologies for the subject line. I'm very disappointed that the
silent majority of draft authors isn't speaking up. I can't imagine
that the vast majority of draft authors has absolutely no problems
with XML2RFC. So I'm assuming they've been ignoring the thread,
hopefully the new subject line will get some of them to chime in. If
that doesn't happen I'll shut up and try to figure out why I have so
much trouble with something that nobody else finds difficult.


I have no significant problems using xml2rfc, and find it easier to
write Internet-Drafts using xml2rfc than I did using nroff, LaTeX, or
Microsoft Word.

I also appreciate the added consistency in Internet-Draft formatting
that has resulted since xml2rfc has been widely adopted. This makes it
a lot easier to print drafts, since they have consistent page sizes
and form-feed characters.


huh?

the current boilerplate has the first page being 54 lines long, and 
subsequent pages being 57 lines long, but with the "footer" on the 
56th line, and not the 57th.


The "footer" on the first page isn't on the last line of the page either.

This isn't very uniform...  perhaps unless you use some special 
viewer to recreate this non-uniform display consistently.


IDs and RFCs are displayed in text, and they should be viewable in 
any text program consistently.


Or am I missing some magic program that is implicitly mandatory to 
use in all this process?




--
Colin Perkins
http://csperkins.org/



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[Iljitsch van Beijnum]

On 5 jul 2009, at 16:22, Dave Nelson wrote:


I suppose if there were indeed a *standard* word processor, this might
be feasible, but I think by "standard issue" you mean "commercially
available".


Standard issue = standard, typical. I used it in the sense of "any  
decent".


Any word processor can create styles the way I talked about, such as  
Word, Pages, OpenOffice, just to name the ones that I know are still  
around. The only problem converting a style-tagged document to draft/ 
RFC format or whatever archival format we end up using in the future.


The obvious way to do this would be to interpret the XML that each of  
these produce, but the problem is that they each have their own  
format, with little interoperation. Word 97 .doc format is the de  
facto lingua franca in the word processing world, but this is an  
inconvenient format. Rich text (RTF) format would probably be best.  
This format is fairly limited, but we only need the text itself and  
the styles so it should be more than sufficient. It's also a text- 
based format.


On 5 jul 2009, at 18:01, Joel M. Halpern wrote:

So I am very confused why you are asking us to kill a tool that was  
produced by volunteers, works very well, and that many people use by  
choice.


You're right, I shouldn't use the word "die". The blog post by ekr  
that I linked to in my first message talked about how XML2RFC has  
become a de facto requirement because of the outdated formatting  
requirements that can only be met with XML2RFC or even quainter tools.  
This is what I'm having problems with. Of course if people are happy  
with XML2RFC, that's fine.


I have seen some folks arguing that we should make XML2RFC normative  
and mandatory.  If they can figure out how to automatically and  
accurate convert the other mechanisms people use, then that can be  
considered.


Ah, but that's impossible, unless you add an AI to the conversion tool  
that comes up with the semantic annontations that were never in the  
source.



On 5 jul 2009, at 19:04, Doug Ewell wrote:


The point about capitalizing Dutch names wrong is an important  
localization issue, since people's names are important, but  
treating it as a fatal flaw in the premise of "encode meaning, not  
presentation" seems to weaken the overall argument.  It's a bug.


It's not a bug, it shows that the basic premise behind XML2RFC is  
untenable.






What we need is the ability to write drafts with a standard issue  
word processor. I'm sure that sentence conjured up nightmares of  
Word documents with insane formatting being mailed around clueless  
beaurocracies, but that's not what I mean. Word processors use  
styles to tag headings, text, quotes, lists and so on: the exact  
same stuff that you can do in XML but rather than having to think  
about it (especially closing all tags correctly) it happens  
easily, automatically and without getting in the way. (I can even  
change the style for an entire paragraph with a single menu  
selection or function key without having to find the beginnings  
and ends of that paragraph.)


I fear this will run into the ground instantly, if the anti- 
Microsoft faction insists on a single "standard issue" word  
processor that is unfamiliar to most users.  The same problems with  
learning to use a new tool will apply.


It sounds like what people really want is a more comprehensive  
system that would allow I-D authors to use xml2rfc, roff, Word,  
LaTeX, or basically any tool they like, not a great policy reversal  
that replaces one mandatory tool with another.  Given the level of  
effort involved and user expectations, especially concerning  
support for the latest updates to the IP boilerplate, this would be  
beyond the scope of volunteer developers; it would require  
professional developers with a professional development budget.


--
Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[ned+ietf]

On 5 Jul 2009, at 14:24, Iljitsch van Beijnum wrote:
> My apologies for the subject line. I'm very disappointed that the
> silent majority of draft authors isn't speaking up. I can't imagine
> that the vast majority of draft authors has absolutely no problems
> with XML2RFC. So I'm assuming they've been ignoring the thread,
> hopefully the new subject line will get some of them to chime in. If
> that doesn't happen I'll shut up and try to figure out why I have so
> much trouble with something that nobody else finds difficult.



I have no significant problems using xml2rfc, and find it easier to
write Internet-Drafts using xml2rfc than I did using nroff, LaTeX, or
Microsoft Word.


My experience has been the same. I will also add that I find the ability to
apply XML tools, including but not limited to syntax checking editors, very
convenient.

I particularly like the fact that xml2rfc lets me focus on the content of my
drafts and spend very little time on presentation issues. I don't even want to
think about how much time I've wasted piddling around with formattting nits
when using nroff, and don't get me started on LaTeX.

Oh, and as for installing the software, I'm not a TCL fan, but even so I've
done that on everything from  Mac OS 9 to Solaris to OpenVMS. I sure can't say
the same for groff.

My only serious complaint about xml2rc has been the current need to use a
pre-release version and the whole boilerplate thing, but I view that as a
failing (or is that "flailing"?) of our process and not an xml2rfc issuue per
se.


I also appreciate the added consistency in Internet-Draft formatting
that has resulted since xml2rfc has been widely adopted. This makes it
a lot easier to print drafts, since they have consistent page sizes
and form-feed characters.


Agreed that the consistency is very welcome, but I honestly can't recall the
last time I printed out a draft or RFC. It's been several years at least.

Ned
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[Elwyn Davies]

Carsten Bormann wrote:

What we need is the ability to write drafts with a standard
issue word processor.


Why?  I suppose if there were indeed a *standard* word processor, 
this might

be feasible, but I think by "standard issue" you mean "commercially
available".


http://www.xmlmind.com/xmleditor/

Commercial, and the personal edition is available at no cost.
I've gotten non-CS people up to speed on that tool in no time.

Best with:
http://code.google.com/p/xml2rfc-xxe/

+1

This is my preferred mechanism (thanks to Bill Fenner).  It isn't 
totally perfect but it makes it very difficult to produce invaliud xml 
and does give you a good idea of what you will get.


One colleague has had problems due to exploiting (or maybe just not 
getting caught by) some of the laxities in earlier versions getting 
tightened up later, but it is generally easy enough to fix things up.  
Bill's verifier is very helpful for this purpose.

http://www.fenron.com/~fenner/ietf/xml2rfc-valid/

As regards documentation, there are two sets of tutorial slides (maybe 
could be described as 'basic' and 'intermediate' - I wrote the latter).  
The FAQ is very useful and there are several templates, including the 
one I did to accompany the tutorial I did.  This has lots of explanatory 
text in it with many examples - there is a stripped down version for 
when you are experienced. These all fill in the holes left by the basic 
documentation IMHO, including the complete list of PIs and what they do.

http://xml.resource.org/xml2rfcFAQ.html

Regards,
Elwyn






(But then, I use Emacs, which is non-commercial and free.)

Gruesse, Carsten

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[Marc Petit-Huguenin]

Iljitsch van Beijnum wrote:
> My apologies for the subject line. I'm very disappointed that the silent
> majority of draft authors isn't speaking up. I can't imagine that the
> vast majority of draft authors has absolutely no problems with XML2RFC.

I use the RFC 2629 format for all my drafts and cannot imagine using
something else.  The xml2rfc tool is not perfect but does a good job
to convert in html or text.

I do not think that the RFC 2629 format should be the only mandatory
format, but I think that the upload tool should at least give a
warning when an RFC 2629 document will not permit to recreate the
text version uploaded at the same time.

I wrote an (yet unpublished) tool to convert RFC 2629 documents to
mobi document, so they can be used on an Amazon Kindle.  The plan
was to take the list of all I-Ds published as RFC 2629 documents
before the deadline, convert them and let people install them on
their Kindle, e.g. to read on the trip to the IETF meeting.
Unfortunately most of the I-D uploaded in RFC 2629 form cannot be
used to generated a useful document (mobi or text), for two main
reasons: 1) the date element is not fully filled, so the date in the
final output changes and, 2) the references are not resolved (i.e.
there is  elements in the document), so the
final output changes when the documents referenced change.

The problem is that there is at the same time some high level
components (include, unspecified dates) mixed with low level
components in the RFC 2629 format.  The low level components are
part of the subset that makes possible to rebuild the various output
formats at anytime and that, IMO, should be enforced at upload time.
 The high level components are what makes the editing process
easier.  I use a superset of RFC 2629 for my documents (e.g. I use
xinclude instead of the include PI) and a script to convert it to
the low-level subset described above.  This script uses the docName
in the high level document to generate the filename of the low level
document, which is very useful when using source control management.
 The script also resolves all the xinclude references, removes the
comments and adds the current date.  The process is then something
like this:

turn-uri.xml
   --> draft-ietf-behave-turn-uri-02.xml --> upload
   --> draft-ietf-behave-turn-uri-02.txt --> upload
   --> draft-ietf-behave-turn-uri-02.mobi

-- 
Marc Petit-Huguenin
Home: m...@petit-huguenin.org
Work: petit...@acm.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[Doug Ewell]

Iljitsch van Beijnum  wrote:

My apologies for the subject line. I'm very disappointed that the 
silent majority of draft authors isn't speaking up. I can't imagine 
that the vast majority of draft authors has absolutely no problems 
with XML2RFC. So I'm assuming they've been ignoring the thread, 
hopefully the new subject line will get some of them to chime in. If 
that doesn't happen I'll shut up and try to figure out why I have so 
much trouble with something that nobody else finds difficult.


I'm a programmer, so none of this probably matters, but I didn't have 
any more trouble learning to use xml2rfc than I normally have with other 
programs that are fairly powerful but poorly documented.  Reading XML is 
its own skill and not always easy, by any means, but that is true for 
any other text markup language.  Deciphering the error messages isn't 
easy either, but not *extremely* hard.


I did try to install xml2rfc locally on my system and failed miserably, 
partly because of all the additional junk I would have had to install, 
but the online version always works like a champ for me.


The point about capitalizing Dutch names wrong is an important 
localization issue, since people's names are important, but treating it 
as a fatal flaw in the premise of "encode meaning, not presentation" 
seems to weaken the overall argument.  It's a bug.


What we need is the ability to write drafts with a standard issue word 
processor. I'm sure that sentence conjured up nightmares of Word 
documents with insane formatting being mailed around clueless 
beaurocracies, but that's not what I mean. Word processors use styles 
to tag headings, text, quotes, lists and so on: the exact same stuff 
that you can do in XML but rather than having to think about it 
(especially closing all tags correctly) it happens easily, 
automatically and without getting in the way. (I can even change the 
style for an entire paragraph with a single menu selection or function 
key without having to find the beginnings and ends of that paragraph.)


I fear this will run into the ground instantly, if the anti-Microsoft 
faction insists on a single "standard issue" word processor that is 
unfamiliar to most users.  The same problems with learning to use a new 
tool will apply.


It sounds like what people really want is a more comprehensive system 
that would allow I-D authors to use xml2rfc, roff, Word, LaTeX, or 
basically any tool they like, not a great policy reversal that replaces 
one mandatory tool with another.  Given the level of effort involved and 
user expectations, especially concerning support for the latest updates 
to the IP boilerplate, this would be beyond the scope of volunteer 
developers; it would require professional developers with a professional 
development budget.


--
Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[Joel M. Halpern]

Having written a moderate number of drafts, using a number of tools, I 
find that I strongly prefer using XML2RFC.
One large draft I was working on was originally written using WORD.  I 
found it extremely difficult to work with (although I have a current 
version of Word available at all times.)
Instead, working with another author we converted the document to XML 
for XML2RFC.  And we did this in spite of knowing up front that the 
large amount of XML in the I-D was going to make this harder.


The current procedures allow for XML2RFC, Word, NROFF, and manual text 
(if you really want.)  Yes, to use any one of those you have to figure 
out some idiosyncrasies of the particular approach.  So I am very 
confused why you are asking us to kill a tool that was produced by 
volunteers, works very well, and that many people use by choice.


I have seen some folks arguing that we should make XML2RFC normative and 
mandatory.  If they can figure out how to automatically and accurate 
convert the other mechanisms people use, then that can be considered. 
Otherwise, mandating would be inappropriate, as some folks do indeed 
find it difficult.


Yours,
Joel M. Halpern

Iljitsch van Beijnum wrote:
My apologies for the subject line. I'm very disappointed that the silent 
majority of draft authors isn't speaking up. I can't imagine that the 
vast majority of draft authors has absolutely no problems with XML2RFC. 
So I'm assuming they've been ignoring the thread, hopefully the new 
subject line will get some of them to chime in. If that doesn't happen 
I'll shut up and try to figure out why I have so much trouble with 
something that nobody else finds difficult.

...
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[Colin Perkins]

On 5 Jul 2009, at 14:24, Iljitsch van Beijnum wrote:
My apologies for the subject line. I'm very disappointed that the  
silent majority of draft authors isn't speaking up. I can't imagine  
that the vast majority of draft authors has absolutely no problems  
with XML2RFC. So I'm assuming they've been ignoring the thread,  
hopefully the new subject line will get some of them to chime in. If  
that doesn't happen I'll shut up and try to figure out why I have so  
much trouble with something that nobody else finds difficult.


I have no significant problems using xml2rfc, and find it easier to  
write Internet-Drafts using xml2rfc than I did using nroff, LaTeX, or  
Microsoft Word.


I also appreciate the added consistency in Internet-Draft formatting  
that has resulted since xml2rfc has been widely adopted. This makes it  
a lot easier to print drafts, since they have consistent page sizes  
and form-feed characters.


--
Colin Perkins
http://csperkins.org/



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[Dave Nelson]

Iljitsch van Beijnum writes...

> I'm very disappointed that the silent majority of draft authors
> isn't speaking up. I can't imagine that the vast majority of
> draft authors has absolutely no problems with XML2RFC.

My personal experience with XML2RFC, as an I-D and RFC author has been
largely positive.  There does seem to be a bug in the latest pre-release
version around the use of ">" and "<" characters in ASCII art figures (as
arrow heads).  Other than that, I find it easy to use.

It's true that the documentation is merely adequate, especially in the area
of document meta-data.  I find it to be generally consistent with other open
source documentation.

> The problem with XML2RFC formatted drafts and RFCs is that you
> can't display them reasonably without using XML2RFC...

All you're saying is that XLM2RFC isn't WYSIWYG.  True enough.  Neither is
nroff.

> ...and although XML2RFC can run on many systems in theory, in
> practice it's very difficult to install and run successfully because
> it's written in TCL and many XML2RFC files depend on the local 
> availability of references.

I rely on the on-line, web-based conversion service.  I'll admit that I've
never gotten a local install of XML2RFC to work.

> What we need is the ability to write drafts with a standard
> issue word processor. 

Why?  I suppose if there were indeed a *standard* word processor, this might
be feasible, but I think by "standard issue" you mean "commercially
available".


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[Carsten Bormann]

What we need is the ability to write drafts with a standard
issue word processor.


Why?  I suppose if there were indeed a *standard* word processor,  
this might

be feasible, but I think by "standard issue" you mean "commercially
available".


http://www.xmlmind.com/xmleditor/

Commercial, and the personal edition is available at no cost.
I've gotten non-CS people up to speed on that tool in no time.

Best with:
http://code.google.com/p/xml2rfc-xxe/

(But then, I use Emacs, which is non-commercial and free.)

Gruesse, Carsten

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

XML2RFC must die, was: Re: Two different threads - IETF Document Format

[Iljitsch van Beijnum]

My apologies for the subject line. I'm very disappointed that the  
silent majority of draft authors isn't speaking up. I can't imagine  
that the vast majority of draft authors has absolutely no problems  
with XML2RFC. So I'm assuming they've been ignoring the thread,  
hopefully the new subject line will get some of them to chime in. If  
that doesn't happen I'll shut up and try to figure out why I have so  
much trouble with something that nobody else finds difficult.


On 4 jul 2009, at 13:27, John Levine wrote:


I think it's reasonable to assume that going forward the vast majority
of users who read online documents will be able to use software that
can reformat them in various ways.  This tells me that although the
publication form has to be readable in a pinch as plain text, it's
more important that it's amenable to mechanical processing.  Tidily
formatted xml2rfc would be a reasonable candidate


No, it's not. The problem with XML2RFC formatted drafts and RFCs is  
that you can't display them reasonably without using XML2RFC, and  
although XML2RFC can run on many systems in theory, in practice it's  
very difficult to install and run successfully because it's written in  
TCL and many XML2RFC files depend on the local availability of  
references. When those aren't present the conversion fails.


The philosophy behind XML2RFC is to encode meaning in the XML wherever  
possible, rather than simply display text. There are several problems  
with that:


1. It makes it hard to write source files, because now rather than  
type "Experimental" at the top of the file, I have to know what  
XML2RFC looks for to determine the draft's status. Same thing with  
boilerplate, references, etc.


2. It makes it hard to read source files for the same reason. You  
can't read an XML2RFC formatted XML file without prior knowledge and  
get all the information that would be displayed in the final draft/RFC  
format.


3. It gets it wrong. XML2RFC "knows" that you create a name from an  
initial, a period, a space and a last name. So initial "I" and last  
name "Van Beijnum" becomes "I. Van Beijnum". However, XML2RFC doesn't  
know that in Dutch, certain last name prefixes are capitalized if they  
appear at the beginning of the name (Van Beijnum) but not if they're  
in the middle because there are first names or initials: "I. van  
Beijnum".


This means that the makers of XML2RFC spent a lot of time making the  
tool require the authors to spend a lot of time to create something  
that is sometimes incorrect, with no means to correct the problem. An  
all-around waste of time.


Then there is the problem with XML in general. Now apparently there  
are XML editors that can make sure you create syntactically correct  
XML without having to take care of all the details manually. But as  
someone who has otherwise no need to write XML, I'm not familiar with  
those tools. So I write my XML2RFC source by hand. The result is that  
I invariably get error messages that the  and  tags  
don't match properly. This is a problem that is extremely hard to  
debug manually, especially as just grepping for "section" isn't  
enough: there could be a ,  etc somewhere between a  
 and  that breaks everything.


First writing a source file and then compiling it into an output file  
is no longer something something that is familiar to most people. When  
I write anything other than a draft, I can simply select "header level  
2" and I know that everything will be taken care of. I don't have to  
explicitly tell my word processor where the text following a header  
level 2 ends, because the presence of another header makes that clear  
both to me and to the software.


What we need is the ability to write drafts with a standard issue word  
processor. I'm sure that sentence conjured up nightmares of Word  
documents with insane formatting being mailed around clueless  
beaurocracies, but that's not what I mean. Word processors use styles  
to tag headings, text, quotes, lists and so on: the exact same stuff  
that you can do in XML but rather than having to think about it  
(especially closing all tags correctly) it happens easily,  
automatically and without getting in the way. (I can even change the  
style for an entire paragraph with a single menu selection or function  
key without having to find the beginnings and ends of that paragraph.)


Formatting is then based on the style tags, with all explicit  
formatting aplied by the word processor removed. This is standard  
operating procedure in 99% of publishing. (The other 1% being  
scientific/engineering books where the authors send in Latex.)


All the stuff that can't be handled by styles should just be copied  
and pasted from the boilerplate, without the need for tools to know  
about the structure of these things. (At least not in the draft stage,  
perhaps this can be useful in the final stages of RFC editing.)

___
Ietf ma