RE: XML2RFC must die, was: Re: Two different threads - IETF Document Format
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
-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 is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)
Mark Andrews wrote: I had wierd results with the following just printing out Zone and not the rest of the lines in the table. texttable ttcol align=leftZone/ttcol c10.IN-ADDR.ARPA/c c16.172.IN-ADDR.ARPA/c c17.172.IN-ADDR.ARPA/c ... 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 nbsp;nbsp;nbsp;nbsp; 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: #160;#160;#160;#160;. 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)
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. texttable ttcol align=leftZone/ttcol c10.IN-ADDR.ARPA/c c16.172.IN-ADDR.ARPA/c c17.172.IN-ADDR.ARPA/c ... 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 nbsp;nbsp;nbsp;nbsp; 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: #160;#160;#160;#160;. 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. texttable ttcol align=leftZone/ttcol c0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\/c cnbsp;nbsp;nbsp;nbsp;0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA/c c1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\/c c0nbsp;nbsp;nbsp;nbsp;.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA/c /texttable 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)
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. texttable ttcol align=leftZone/ttcol c10.IN-ADDR.ARPA/c c16.172.IN-ADDR.ARPA/c c17.172.IN-ADDR.ARPA/c ... 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. texttable ttcol align=leftZone/ttcol c0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\/c cnbsp;nbsp;nbsp;nbsp;0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA/c c1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\/c c0nbsp;nbsp;nbsp;nbsp;.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA/c /texttable Ok, that's an interesting case where non-breaking spaces are needed as a last resort. Also, this case would be simpler if c allowed vspace, 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 must die, was: Re: Two different threads - IETF Document Format
-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. blech 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)
On Mon, 6 Jul 2009 10:18:14 +0300, Lars Eggert lars.egg...@nokia.com 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
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. blech 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 must die, was: Re: Two different threads - IETF Document Format
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
--On Sunday, July 05, 2009 12:01 -0400 Joel M. Halpern j...@joelhalpern.com 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 jason_living...@cable.comcast.com 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 reference 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)
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 Eggertlars.egg...@nokia.com 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 is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)
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)
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: ?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ? (after the XML declaration, when present) 2) Copy rfc2629.xslt to the folder where the xml2rfc source file resides (get it from http://greenbytes.de/tech/webdav/rfc2629xslt.zip). 3) Open the XML file in IE/Firefox/Safari/Opera. More info: http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html NOTE: rfc2629.xslt does not support xml2rfc's include processing instruction, thus external references will only work using the XML entity inclusion mechanism (see http://xml.resource.org/, 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)
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)
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)
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: ?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ? (after the XML declaration, when present) 2) Copy rfc2629.xslt to the folder where the xml2rfc source file resides (get it from http://greenbytes.de/tech/webdav/rfc2629xslt.zip). 3) Open the XML file in IE/Firefox/Safari/Opera. More info: http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html NOTE: rfc2629.xslt does not support xml2rfc's include processing instruction, thus external references will only work using the XML entity inclusion mechanism (see http://xml.resource.org/, 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)
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)
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. texttable ttcol align=leftZone/ttcol c10.IN-ADDR.ARPA/c c16.172.IN-ADDR.ARPA/c c17.172.IN-ADDR.ARPA/c c18.172.IN-ADDR.ARPA/c c19.172.IN-ADDR.ARPA/c c20.172.IN-ADDR.ARPA/c c21.172.IN-ADDR.ARPA/c c22.172.IN-ADDR.ARPA/c c23.172.IN-ADDR.ARPA/c c24.172.IN-ADDR.ARPA/c c25.172.IN-ADDR.ARPA/c c26.172.IN-ADDR.ARPA/c c27.172.IN-ADDR.ARPA/c c28.172.IN-ADDR.ARPA/c c29.172.IN-ADDR.ARPA/c c30.172.IN-ADDR.ARPA/c c31.172.IN-ADDR.ARPA/c c168.192.IN-ADDR.ARPA/c /texttable Also how do you do the equivalent of nbsp;nbsp;nbsp;nbsp; 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: ?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ? (after the XML declaration, when present) 2) Copy rfc2629.xslt to the folder where the xml2rfc source file resides (get it from http://greenbytes.de/tech/webdav/rfc2629xslt.zip). 3) Open the XML file in IE/Firefox/Safari/Opera. More info: http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html NOTE: rfc2629.xslt does not support xml2rfc's include processing instruction, thus external references will only work using the XML entity inclusion mechanism (see http://xml.resource.org/, 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)
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. texttable ttcol align=leftZone/ttcol c10.IN-ADDR.ARPA/c c16.172.IN-ADDR.ARPA/c c17.172.IN-ADDR.ARPA/c c18.172.IN-ADDR.ARPA/c c19.172.IN-ADDR.ARPA/c c20.172.IN-ADDR.ARPA/c c21.172.IN-ADDR.ARPA/c c22.172.IN-ADDR.ARPA/c c23.172.IN-ADDR.ARPA/c c24.172.IN-ADDR.ARPA/c c25.172.IN-ADDR.ARPA/c c26.172.IN-ADDR.ARPA/c c27.172.IN-ADDR.ARPA/c c28.172.IN-ADDR.ARPA/c c29.172.IN-ADDR.ARPA/c c30.172.IN-ADDR.ARPA/c c31.172.IN-ADDR.ARPA/c c168.192.IN-ADDR.ARPA/c /texttable I should add if I add a second column the full table is discplayed. Also how do you do the equivalent of nbsp;nbsp;nbsp;nbsp; 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: ?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ? (after the XML declaration, when present) 2) Copy rfc2629.xslt to the folder where the xml2rfc source file resides (get it from http://greenbytes.de/tech/webdav/rfc2629xslt.zip). 3) Open the XML file in IE/Firefox/Safari/Opera. More info: http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html NOTE: rfc2629.xslt does not support xml2rfc's include processing instruction, thus external references will only work using the XML entity inclusion mechanism (see http://xml.resource.org/, 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 must die, was: Re: Two different threads - IETF Document Format
... 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
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
xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)
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 is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)
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
Re: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)
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 must die, was: Re: Two different threads - IETF Document Format
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 must die, was: Re: Two different threads - IETF Document Format
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
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
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
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 section and /section 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 !--, --, /middle etc somewhere between a section and /section 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 is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)
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 is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)
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 must die, was: Re: Two different threads - IETF Document Format
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
XML2RFC must die, was: Re: Two different threads - IETF Document Format
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 section and /section 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 !--, --, /middle etc somewhere between a section and /section 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.)
Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format
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
RE: XML2RFC must die, was: Re: Two different threads - IETF Document Format
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
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
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
Iljitsch van Beijnum iljitsch at muada dot com 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
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 ?rfc include='file'? 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
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
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
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
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
+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
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
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
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
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 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
