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
Attachment:
pgpcPAR1VZ32I.pgp
Description: PGP signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf