RE: A modest proposal - allow the ID repository to hold xml
2003-09-03 10:32:58
Jean-Jacques
Is it not better to add xml incremental to text, rather than
exclusive OR? If we demand that the I=D editor have a tool
and use it to generate text, we open a large box of problems.
What if the version of the tool the author used is different
from the I-D editor? What if the xml is not well formed and
the tool does something unexpected? What do we do when we
upgrade the xml schema (that is, do we have to go back and
edit older documents)? All of these questions would have to
be answered, and answered well enough to satisfy some pretty
demanding people, some of whom are pretty content with the status quo.
My proposal avoids such discussions. It makes no requirements
other than if xml is submitted, then it SHOULD be in conformance
to 2629.
I also think it is MUCH better to start with the I-D archive and
not change the RFC process. Among other things, I-Ds expire.
If this change doesn't work, in 6 months, we can be rid of any
vestiges. RFCs don't expire (although they get obsoleted), and
the time frame is much longer. Let's stick to I-Ds only, please.
Brian
-----Original Message-----
From: Jean-Jacques Puig
[mailto:Jean-Jacques(_dot_)Puig(_at_)int-evry(_dot_)fr]
Sent: Wednesday, September 03, 2003 7:47 AM
To: 'ietf(_at_)ietf(_dot_)org'
Subject: Re: A modest proposal - allow the ID repository to hold xml
On Tue, Sep 02, 2003 at 01:52:38PM -0600, Lyndon Nerenberg wrote:
You didn't say what the additional value would be. We know the
additional value of a .ps file (drawings that don't translate to
ASCII art). What is the value of XML? It certainly isn't
searchability or readability.
While I normally run in horror from all things XML, this is
one of the few
exceptions. XML would immediately solve a number of
problems I face almost
daily:
- give me a list of all the documents "belonging" to a particular WG
- for any given RFC, show me the chain of document dependencies
(obsoletes, updated by, obsoleted by) that pass through
this document
- for any given RFC, generate a dependency graph based on
the normative
references in this document
You have to have a structured document format to
programmatically solve
these sorts of problems, and XML provides that. (While I've
become quite
adept at searching rfc-index.txt with less, I really want something
better.)
May I add in the same direction ? The structure of the document allows
for invoking relations between nodes, which helps for expressing
elaborate search both on meta informations (WG, Author, etc.) and on
content (the actual titles and text sections). You can surely look
within all 'xmlly' available drafts for draft belonging to a specific
WG AND referencing a list of specific docs in sections whose
title contains
a specific word. This would be hard to express against the
txt version.
And I second Ned's comments about generating *useful* diffs between
document revisions. This is especially useful if we
generate drafts in XML
format.
I'm not sure how to address the problem with legacy RFCs.
I'll bet we
could find volunteers to generate XML equivalents from the
existing plain
text documents. (We would need an XML tag to indicate which
of the plain
text or XML documents is considered authoritative.)
I wonder whether this has not already been done by zvon
(http://www.zvon.org/). Concerning referencing rfcs, citation
libraries
from http://xml.resource.org look rather complete.
Several additions to the xml cause:
Edition in xml allows for good modularity, e.g. with the definition
of xml entities. This is an easy way to divide work between several
editors. Availability of the xml source helps for editors to welcome
new contributors.
What I would suggest is the following:
- Authors provide draft in xml XOR txt . This allows for a test
period of xml as an alternate default format; authors do not
provide both, this in order to avoid incoherences.
- rfc editor generates txt, ps, etc. versions. html
version may only
require reference to a stylesheet, though this is
currently tricky
because few browsers actually support xml+xsl.
Newcomers to xml should be informed of the following:
- xml is easy.
- Grammar/spelling tools compatible with html generally
work (I use
ispell and aspell indifferently).
- Document structure and well-formedness can be validated.
- Maintaining an xml source is easy, compared to
maintaining a ASCII
formatted txt: this is a point authors may care about.
- xml rendering generates classic formats and newers:
this is what
reviewers, readers care about.
- xml users are not hackers, extremists or ninjas.
Common sense and
good pratice is the main source of xml advocacy.
Also, xml is not
perfect; it is only better.
--
Jean-Jacques Puig
[homepage] http://www-lor.int-evry.fr/~puig/
_______________________________________________
This message was passed through
ietf_censored(_at_)carmen(_dot_)ipv6(_dot_)cselt(_dot_)it, which is a sublist
of
ietf(_at_)ietf(_dot_)org(_dot_) Not all messages are passed. Decisions on
what
to pass are made solely by Raffaele D'Albenzio.
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: A modest proposal - allow the ID repository to hold xml, (continued)
- A modest proposal - allow the ID repository to hold xml, wang liang
- RE: A modest proposal - allow the ID repository to hold xml, Rosen, Brian
- RE: A modest proposal - allow the ID repository to hold xml, Rosen, Brian
- RE: A modest proposal - allow the ID repository to hold xml, Rosen, Brian
- RE: A modest proposal - allow the ID repository to hold xml, Rosen, Brian
- RE: A modest proposal - allow the ID repository to hold xml,
Rosen, Brian <=
- RE: A modest proposal - allow the ID repository to hold xml, Rosen, Brian
- RE: A modest proposal - allow the ID repository to hold xml, Rosen, Brian
- Fw: A modest proposal - allow the ID repository to hold xml, JORDI PALET MARTINEZ
- RE: A modest proposal - allow the ID repository to hold xml, Rosen, Brian
|
|
|