Subject: Re: A modest proposal - allow the ID repository to hold xml

From: Jean-Jacques Puig <[email-masked]>
Date: Wed, 3 Sep 2003 16:36:42 +0200

On Wed, Sep 03, 2003 at 09:46:09AM -0400, Rosen, Brian wrote:
> What if the version of the tool the author used is different
> from the I-D editor?

The tool itself has -in theory :)- no incidence. Only the DTD has, and
it is not expected to change very often.

> What if the xml is not well formed and
> the tool does something unexpected?

Well-formedness and validation against dtd MUST be checked by I-D
editor, and SHOULD by authors. Note that this pb is the same with
current scheme: authors can provide messy, bad formatted documents with
ansi escape sequences, etc.

> What do we do when we
> upgrade the xml schema (that is, do we have to go back and
> edit older documents)?

This is a general pb. Let's assume we change formatting rules for txt
IDs. Then, how do we upgrade to new format ? As for many document
formats, ascendant compatibility is a legitimate expectation, and is
easily granted. When a design flaw from previous models has to be
corrected, then most of the time, it should be easy to move old doc to
the latest model with a batch xsl tranformation; this sometimes happens.

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

Sure.
BTW, note that the xml source actually contains in the clear the content
of the draft. Information can not be lost.

> My proposal avoids such discussions.  It makes no requirements
> other than if xml is submitted, then it SHOULD be in conformance
> to 2629.  

In my opinion, it MUST be in conformance to 2629 DTD (or later
version). If everyone designs one's own DTD, then the advantages from
sharing the xml source are greatly reduced.

> I also think it is MUCH better to start with the I-D archive and
> not change the RFC process.

I certainly agree.

> 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

-- 
Jean-Jacques Puig

[homepage] http://www-lor.int-evry.fr/~puig/

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 3 Sep 2003 09:46:09 -0400

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.

not change the RFC process.  Among other things, I-Ds expire.

Brian

> -----Original Message-----
> From: Jean-Jacques Puig [mailto:[email-masked]]
> Sent: Wednesday, September 03, 2003 7:47 AM
> To: [email-masked]'
> 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
> 
> _______________________________________________
> This message was passed through 
> [email-masked], which is a sublist of 
> [email-masked]. Not all messages are passed. Decisions on what 
> to pass are made solely by Raffaele D'Albenzio.
>