Re: Alternative formats for IDs

On Fri, Jan 13, 2006 at 12:07:21PM -0800, Dave Crocker wrote:

Equating the XML communities and the xml2rfc communities is not correct.


Actually, it is.

xml2rfc uses some tailored dtd/xslt files.  They semantics in them is 
significant but what is far more important is the xml infrastructure that 
is available, in terms of expertise and tools.


The xml2rfc tool that I am familiar with (available from here:
http://xml.resource.org/ ) formats the text itself, without using
standard xslt (or dsssl or any standard formatting language).  Unless
I'm really misreading it, it's a 13,000 line tcl script that does
all its own text/html/nroff formatting.  I don't think tcl code is an
XML standard.

I was operating under the assumption that rfc2xml from the above site is
the program you were talking about.  A system that produces RFC output
from the xml2rfc markup using only (or even primarily) standard,
well-supported XML parsing and formatting tools would make the
communities much more congruent and reap the obvious benefits.   That's
not the tool I see in operation today. 

I'd be more likely to believe that the formatting was robust and that
the system was maintainable if there was such a tool for the RFC editor
to adopt.  I'd also be more likely to believe your assertions that the
toolchain was benefiting from the growing XML community.


I now produce drafts using an off-the-shelf xml tool that take the 
standard-form xml2rfc dtd and xslt files and produce excellent output.  (To 
be entirely fair, yes, there is some special software that produces the txt 
version.)  The xml tool and knowledge of xml are broadly applicable, and 
growing.


There's no need to copy IETFdom Assembled on this, but I'm curious what
toolchain you're using and what limitations you've encountered.

          Knowledge of nroff is now sufficiently obscure as to be beyond 
mere characterization as "marginalized".  A word like "archaic" is more 
appropriate.

And by the way, please note that the use of nroff for rfcs also requires 
special conventions.

What is important is not the files used to tailor the production service, 
but the prevalence of expertise and tools for that service.

In reality, nroff expertise is isolated in a tiny community.  In reality, 
xml expertise has become global.  That's not an assessment of hypothetical, 
future adoption.  It is an assessment of *existing* adoption.


You'll note that I make no assertions about the stability of
nroff nor about the size of its user community in the message you're
responding to.  That was not accidental.

If the only issue were the existence of a markup language that reliably
produced plain text RFCs, I *would* be arguing that *roff would be
sufficient if not optimal.  The reson I'm studiously avoiding having
that argument (and will continue to do so) is that I think changing to
an RFC representation that is strictly a formatting language - like
*roff - is not very interesting.

If there's a benefit to be had, IMHO, it's from content-based markup.
Right now the only serious contender I've heard for CBM of RFCs is
rfc2xml (the language).  And, IMHO, it's OKish.  I think the tools and
language will continue to improve.  I don't feel confortable with their
maturity to advocate for them now.

(Again - I'm really not trying to run down xml2rfc.  I think it's on the
right track and I support the idea and the work.  I'm an enthusiastic
user.)

I am looking forward to the day when we not only agree about where to
go, but how to get there. :-)

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG

pgppkgoGRcxmf.pgp
Description: PGP signature

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf