-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.
Perhap
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 to
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 th
> > 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
> 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 o
-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
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
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.ARP
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
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
> >
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 H
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 (whi
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
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 o
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 XML2
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 v
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 co
g] 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:
&g
--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
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 (f
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: XML2
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
demons
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
> 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 subjec
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 easie
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
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 XML2R
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
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
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
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 be
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 learni
> ... 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 powe
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
>
> 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
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 major
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 w
+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 inap
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
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
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'v
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/xmledi
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 c
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,
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.)
I
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
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 p
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 t
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
49 matches
Mail list logo
