Subject: Re: Alternative formats for IDs

From: Bob Braden <[email-masked]>
Date: Thu, 12 Jan 2006 15:36:26 -0800 (PST)

*> 
  *> 2. Given that the RFC Editor has the current practice of converting .txt 
  *> submissions to nroff, it is equally reasonable to pursue their changing that 
  *> conversion, to instead be into xml2rfc.

Dave,

Are you suggesting that the IETF adopt the xml2rfc source as the
normative version of a specification, rather than the .txt (or .pdf)
version?

Bob Braden

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Dave Crocker <[email-masked]>
Date: Thu, 12 Jan 2006 16:22:53 -0800

> normative version of a specification, rather than the .txt (or .pdf)

yes.

as I understand your current operation, the *real* normative version is in nroff.

i believe that an incremental process of switching to xml2rfc -- with easy 
access to that source version for follow-on editing -- would be a considerable 
improvement over the status quo.

 > Who is volunteering to maintain xml2rfc and guarantee backwards
 > compatibility for the next 20 years?  (And why should
 > we believe them?)

Maintaining xml2rfc is going to far less fragile than maintaining nroff.  Nroff 
has no current industry penetration.  XML has quite a lot.

(Both are textual encodings, so that the fall-back position of reverting to pure 
text is probably equally painful.)

d/
-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

---

From: Ted Faber <[email-masked]>
Date: Thu, 12 Jan 2006 17:54:34 -0800

On Thu, Jan 12, 2006 at 04:22:53PM -0800, Dave Crocker wrote:
> Maintaining xml2rfc is going to far less fragile than maintaining nroff.  
> Nroff has no current industry penetration.  XML has quite a lot.

I'd be cautious here.

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

There's an important distinction between the XML meta-language and the
xml2rfc language and its associated formatting tools.  Lots of places
express languages in XML DTDs and use one of the many XML parsers in
their tools to parse those DTDs.  That widespread adoption of the
meta-language and the resultant support for XML parsing libraries in a
large number of implementation languages and environments does simplify
the specification of the xml2rfc language and the generation and
maintenance of the xml2rfc program.  However, the actual community of
that uses the XML-based RFC authoring tools is a subset of the
contributors to the IETF; the maintainers of the xml2rfc formatter(s)
are a subset of that.  That smaller community is the one that is needed
to keep a working xml2rfc language and formatting program available to
the IETF.

It's by no means obvious to me that xml2rfc has reached a critical mass
of developers and users, nor that it will necessarily do so organically.
A financial IETF commitment to the system might mitigate that problem,
though I recognize the trolls under *that* bridge.  (Please do not take
this is not a slap at the rfc2xml developers.  I use the program and I
like the program.)

All that said, I do think that an XML-based encoding of RFC contents is
a good idea (seriously - that's not just lip service), but let's assess
the situation with open eyes.  If we're talking about changing formats
from ASCII -> rfc2xml, Bob's concerns about the long-term viability of
the xml2rfc formatting program(s) do need to be addressed, and the
assertion that there's a lot of interest and activity in XML doesn't do
so adequately.  IMHO.

-- 
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
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Joe Touch <[email-masked]>
Date: Fri, 13 Jan 2006 11:44:40 -0800

> of developers and users, nor that it will necessarily do so organically.

This is my impression, from trying to use it as well. I was troubled by
'yet another embedded text system' that necessitated editing source,
which seemed like a stone-age throwback when I abandoned such systems in
the mid 1980s (Scribe, nroff, etc. at the time).

While I appreciate that, in theory:

	1. there are WYSIWYG XML editors that *can* be loaded with DTDs
	2. Word et al. are moving to XML

it's worth noting that:

	(1) requires users to enter data into XML fields, which can
	be very tedious. it also assumes that the XML editor can be
	loaded with the current IETF RFC DTD, which is by no means
	guaranteed or easy
	
	(2) AFAICT, Word uses its own DTD, and isn't particularly
	cooperative with using your own (I've asked others on the tools
	list about this, and they have had similar experience)

...
> a good idea 

I do not; there is very little in RFCs that needs to be tagged except:
	MIBs
	lists of authors
	lists of references

I can't see why pushing the whole document into 'yet another tagged data
format' does anything for the utility of the remainder.

Joe

---

From: Dave Crocker <[email-masked]>
Date: Fri, 13 Jan 2006 12:07:21 -0800

> 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.

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.  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.

d/

-- 

Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Fri, 13 Jan 2006 14:37:16 -0800

On Jan 13, 2006, at 12:07 PM, Dave Crocker wrote:

> 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.

Agreed.

Adopting an XML structure for the creation of RFCs and related  
documents should be moving in the right direction.  At some point,  
even removing nroff as a crutch may ensure greater conformity for  
tools used to process documents.  Although nroff is an extremely  
powerful and efficient word processing application, building upon  
more versatile and hierarchical structures offers many possibilities  
for managing the growing complexity of information being amassed.

Both approaches requires post processing together with the cut and  
paste of some templates.  As long as xml2rfc allows a means to bypass  
formatting difficulties in getting a good looking draft, regardless  
whether this requires 120 characters or 12, the end results in text  
form of either process _can_ be identical.  Cut and paste does not  
take much effort either way, and even the clumsiness for some  
operations in xml2rfc can be readily overcome.  XML data structures  
enable new features with less effort, like automatic generation of  
bibliographies or the insertion of hyperlinks in html output  
versions.  XML also has the ability to add new elements to  
accommodate new features without disrupting other forms of output.

-Doug

---

From: Ted Faber <[email-masked]>
Date: Fri, 13 Jan 2006 14:53:20 -0800

On Fri, Jan 13, 2006 at 12:07:21PM -0800, Dave Crocker wrote:
> 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. :-)

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 14 Jan 2006 00:40:23 +0100

Joe Touch wrote:

> requires users to enter data into XML fields, which can

Authors could create their own input format, transformed into
the 2629bis XML by a script.  Something like "Wiki" would be
far more than good enough, and that's not very tedious.

An XML editor not knowing the latest and greatest DTD would
still guarantee proper nesting of tags.  And if authors use
US ASCII as document charset their worst problem would be to
convince their XML editor that symbolic entities like &nbhy;
are no nonsense, but defined in the xml2rfc DTD.

If authors use UTF-8 (or anything else that's not ASCII) they
deserve to be in serious trouble for the resulting text/plain
output, that's a point for the I18N considerations in a future
2629bis 

> AFAICT, Word uses its own DTD, and isn't particularly
> cooperative with using your own

Maybe Word isn't an ideal XML-editor then.  Any decent text
editor will do.  If authors don't like vi or notepad they use
something else.  My favourite text editor is based on XEDIT,
about 23 years old.

>> I do think that an XML-based encoding of RFC contents is
>> a good idea
 
> I do not; there is very little in RFCs that needs to be

That list is not complete, e.g. you forgot to mention ABNF.
Another point are the keywords for many RfCs, example:

http://purl.net/net/rfc/2070
http://tools.ietf.org/html/2070

The latter tool doesn't "see" some meta-data like keywords,
because it's not part of the ASCII version.  But it's simple
to specify meta-data in an XML version.

                           Bye, Frank

---

From: Dave Crocker <[email-masked]>
Date: Fri, 13 Jan 2006 15:56:37 -0800

> the program you were talking about.

I use it, or a version that runs on windows, to create the txt output.  But, no, 
it's not what I work with otherwise.  What i work with normally is a commercial 
somewhat-wysiwyg xml editor that is driven by standard xml metafiles.

> to adopt. 

There is.

> toolchain you're using and what limitations you've encountered.  

My impression is that there are now a number of entirely competent xml editing 
systems.  I happen to use oXygen.

> produced plain text RFCs, 

the reason xml is interesting is that it makes editing easier, not just display.

d/

-- 

Dave Crocker

---

From: Ted Faber <[email-masked]>
Date: Fri, 13 Jan 2006 17:20:37 -0800

On Fri, Jan 13, 2006 at 03:56:37PM -0800, Dave Crocker wrote:
> My impression is that there are now a number of entirely competent xml 
> editing systems.  I happen to use oXygen.

Oxygen looks like an interesting tool, but I wasn't able to readily see
that it applies stylesheets to XML to produce printable/readable
documents.  For example, can I go from a docbook document to
cmaera-ready postscript/pdf using oxygen?  Or xml2rfc -> txt? If so,
your argument is better than I thought; if not, I think that's a sign
that we're not ready to move.  Yet.

I don't think editing systems by themselves are a reason to go to an XML
format.  Again, I think that making the RFC content and metadata
available to both machines & humans is facilitated by an XML format.

[snip]
> the reason xml is interesting is that it makes editing easier, not just 

XML does not interest me for that reason.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sat, 14 Jan 2006 04:21:44 +0100

> 	2. Word et al. are moving to XML

Bill Fenner has made a plugin available for the XMLMind XML Editor that 
gives you a lot of assistance in writing XML2RFC documents.

I haven't used it for "production" yet, but it looks wonderful - not 
WYSIWYG, but WYSIPU - What You See Is Pretty Useful.

Details on <http://rtg.ietf.org/~fenner/ietf/xml2rfc-xxe/>

                           Harald

---

From: Elwyn Davies <[email-masked]>
Date: Sat, 14 Jan 2006 15:32:04 +0000

Seconded.

I *have* used it for a production run and whilst it is not perfect it
makes document creation and editing significantly easier than typing
'raw' xml even into a syntax-aware text editor.

It is also very helpful for proof reading and commenting (spell checker
provided).

And the standard version is free.. and supported on Windows, Linux and Mac.

I used to use the Word template but the freedom from hassle of generating the 
final documents, the ease of generating references and support of complex 
numbered lists (almost impossible to achieve in Word) makes
xxe/xml2rfc my current tool chain of choice and means I am never going back to Word.

Regards,
Elwyn
(addict)

Harald Tveit Alvestrand wrote:

> Bill Fenner has made a plugin available for the XMLMind XML Editor 
> that gives you a lot of assistance in writing XML2RFC documents.
>
>------------------------------------------------------------------------
>

---

From: Julian Reschke <[email-masked]>
Date: Sat, 14 Jan 2006 12:02:02 +0100

> not the tool I see in operation today. 

That's correct, in that the only xml2rfc processor that currently 
produces usable ASCII output is the TCL version maintained by MTR and 
Charles Levert.

There are other xml2rfc processors that are useful during the editing 
stage, such as rfc2629.xslt that allows you to open a text editor and a 
browser and basically gives you a nearly instantaneous (depending on 
browser and CPU power) preview of an HTML version of the text.

Best regards, Julian

---

From: Elwyn Davies <[email-masked]>
Date: Sat, 14 Jan 2006 12:50:13 +0000

Seconded.

I used to use the Word template but the freedom from hassle of 
generating the final documents, the ease of generating references makes 
xxe/xml2rfc
and support of complex numbered lists (almost impossible to achieve in 
Word) means I am never going back.

Regards,
Elwyn
(addict)

---

From: Joe Touch <[email-masked]>
Date: Fri, 13 Jan 2006 22:40:36 -0800

> WYSIWYG, but WYSIPU - What You See Is Pretty Useful.

Pretty useful compared to text-editing the source code, yes. Compared to
WYSIWYG, still primitive, unfortunately.

If the goal is to allow the output - i.e., the RFC - to be useful for
data mining, why not allow the XML tags to be used *just* for the
portions that we expect to extract (i.e., for the data to be mined), and
let WYSIWYG editors format the rest of the document structure.

I.e., let each tool be used where it works?

That would allow us to generate the documents with whatever editor we
wanted, in whatever format we wanted, so long as the mined data were
extractable as ASCII text *with* XML tags. At that point, the choice of
archive format is decoupled from the decision of the editor, which it
should be IMO.

Joe

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sat, 14 Jan 2006 10:35:46 +0100

> I.e., let each tool be used where it works?

FWIW - I hate WYSIWYG with a passion.
I *never* want to consider pages, fonts, indentation, section numbers or 
justification when I'm typing. I want to get the text in there, mark 
clearly where the sections are, make my lists as lists, and *get the text 
written*.

Then I want to get it readable with minimal effort - and be able to change 
it later *without* having to guess at the difference between a section 
heading and a line that just happens to start with a number.

Semantic markup works for me - for the *whole* document.

But YMMV.

---

From: Joe Touch <[email-masked]>
Date: Sat, 14 Jan 2006 09:37:42 -0800

Harald Tveit Alvestrand wrote:
> clearly where the sections are, make my lists as lists, and *get the
> text written*.
> 
> Then I want to get it readable with minimal effort - and be able to
> change it later *without* having to guess at the difference between a
> section heading and a line that just happens to start with a number.

I agree completely. Everything you're describing is a function of
WYSIWYG with named styles - which is what it has been for 20+ years,
rather than just "make this bold", "make this 12pt". That's the WYSIWYG
I was assuming (style-WYSIWYG?).

Every system I've seen to date for XML tries very hard to approach what
S-WYSIWYG was capable of 20+ years ago. While some XML editors are
certainly better than editing source, it's nowhere near as capable as
S-WYSIWYG.

> Semantic markup works for me - for the *whole* document.

Agreed, but my point is that there's no reason to force each of us to
use a particular semantic markup where the semantics of the result are
not relevant. There's no utility to plowing through all the markup
associated with lists and headings, when that's not what data needs to
be mined.

What I'm proposing is that RFCs use text/PDF/PS as the archived,
authoritative file (sure - we can argue about which of those three, or
maybe others), but that to extract MIBs/authors/references those tags
need to be in the authoritative version, but the others do not.

Joe

---

From: Joe Touch <[email-masked]>
Date: Sun, 15 Jan 2006 11:00:46 -0800

Elwyn Davies wrote:
> generating the final documents

I'm not sure what freedom this means; XML still needs to run through a
script, just as Word does.

> the ease of generating references

Commercial software allows BIBTEX references to be imported into
citation databases, so this is moot as well.

> makes
> Word)

I checked your three current I-Ds and five RFCs, and the most complex
numbering I saw was "G1, G2, ...", "P1, P2...", and paragraphs numbered
"G.1:, G.2:...". Word has been able to handle all of these since the
late 1980's. Was there a more complex example I missed, or one in a
pending document that hasn't been issued that you could give as an example?

Joe

---

From: Elwyn Davies <[email-masked]>
Date: Sun, 15 Jan 2006 23:13:08 +0000

>script, just as Word does.
you can't do it from inside Word and in my experience the Word process 
broke about 80% of the time (mostly due to the generic text printer 
being horribly buggy) but maybe it is better now since I gave up with 
Word some time ago. [Microsoft were never interested in fixing these 
bugs - reducing some lines to heights of a fraction of a point and 
rendering one character per line in an apparently random fashion - and 
they persisted across multiple releases of Word.]

>citation databases, so this is moot as well.
I am sure I could buy some tools but how well integrated with Word would 
this be and how much would it cost me?

>pending document that hasn't been issued that you could give as an example?

In theory.. my experience was that multiple sets of numbered paragraphs 
spread across sections was painful and error prone.

But ultimately it was just the level of repeated niggles and panics when 
conversion fails close to the I-D deadline that I don't get with xml2rfc 
and especially with xxe.

Don't let me stop you using Word but I know which set of tools I prefer.

Elwyn