[xml2rfc] seriesInfo for Internet Drafts

julian.reschke at gmx.de (Julian Reschke) Sun, 02 January 2005 07:34 UTC

From: "julian.reschke at gmx.de"
Date: Sun, 02 Jan 2005 07:34:25 +0000
Subject: [xml2rfc] seriesInfo for Internet Drafts
Message-ID: <41D8146E.3060501@gmx.de>
X-Date: Sun Jan 2 07:34:25 2005

Hi,

I'm currently working on a checker that takes a document and checks for 
the freshness of Internet Draft references (and yes, this is already 
available for RFC checks).

Converting <http://ftp.ietf.org/internet-drafts/all_id.txt> is quite 
simple (although of course it would be much more conventient if it would 
be available in XML format in the first place).

However, there doesn't seem to be a common way to specify Internet 
Drafts in seriesInfo elements; I've seen both "ID" and "Internet-Draft". 
Would it make sense to recommend a particular one, possibly in the 
RFC2629bis documentation?

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From julian.reschke at gmx.de  Sun Jan  2 16:58:36 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun Jan  2 07:58:56 2005
Subject: [xml2rfc] figure inside t really deprecated?
In-Reply-To: <1149DF22-5607-11D9-8818-000A95CA7FAE@dbc.mtview.ca.us>
References: <200412202025.iBKKPdX21286@windsor.research.att.com>
	<0757A9FE-5380-11D9-92FA-000A95CA7FAE@dbc.mtview.ca.us>
	<200412241710.iBOHACR25645@windsor.research.att.com>
	<1149DF22-5607-11D9-8818-000A95CA7FAE@dbc.mtview.ca.us>
Message-ID: <41D81A2C.10204@gmx.de>

Marshall Rose wrote:
> 
> On Dec 24, 2004, at 09:10, Bill Fenner wrote:
> 
>> Ok.  So is the advice to end the list(s), put the figure inside the
>> nearest section, and open the list(s) again (possibly requiring lots of
>> tricks and counters to get multiple levels of indentation right), or to
>> put the figures somewhere else and xref them from the list, or something
>> else I haven't thought of?
> 
> 
> i think it is a mistake to have figure artwork inside lists.

I can understand that the concept of having *figures* inside lists is 
problematic. However, having several lines of *artwork* (for instance 
for ABNFs or DTD fragments) seems to be very common.

Consider the example in 
<http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.9.3>...

One way to "fix" this would be to allow *artwork* in lists. On the other 
hand, the usage of a list in this example is mainly a workaround to get 
to a specific indentation style (where the sub-para is un-numbered and 
it's body is indented). Maybe a new section type would help us avoid 
these workarounds?

For instance:

<!ATTLIST section
           anchor      ID                 #IMPLIED
           title       %ATEXT;            #REQUIRED
           style       (numbered|indented) "numbered"
           toc         (include|exclude|default)
                                          "default">

?

Best regards, Julian


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From fenner at research.att.com  Sun Jan  2 10:55:23 2005
From: fenner at research.att.com (Bill Fenner)
Date: Sun Jan  2 10:55:33 2005
Subject: [xml2rfc] figure inside t really deprecated?
References: <200412202025.iBKKPdX21286@windsor.research.att.com>
	<0757A9FE-5380-11D9-92FA-000A95CA7FAE@dbc.mtview.ca.us>
	<200412241710.iBOHACR25645@windsor.research.att.com>
	<1149DF22-5607-11D9-8818-000A95CA7FAE@dbc.mtview.ca.us>
	<41D81A2C.10204@gmx.de>
Message-ID: <200501021855.j02ItOt20197@windsor.research.att.com>


>One way to "fix" this would be to allow *artwork* in lists. On the other 
>hand, the usage of a list in this example is mainly a workaround to get 
>to a specific indentation style (where the sub-para is un-numbered and 
>it's body is indented). Maybe a new section type would help us avoid 
>these workarounds?

The example that brought this up was using a list as a list, with a
mini state machine for a couple of a series of steps to try to make
the sequence of the steps more clear.  See list elements 3.b) and 3.c)
in section 3.3 of draft-ietf-proto-wgchair-doc-shepherding-01.txt .

Just for fun, I checked rfc3*.xml from
http://xml.resource.org/public/rfc/xml/
and found:
12 are OK
5 have <t><figure>
3 are not valid XML so libxml2 couldn't parse them

I asked if it was really the intent to deprecate this usage because
I thought it was useful, and I guess several authors find it so as
well.

  Bill
>From carl at media.org  Sun Jan  2 10:56:39 2005
From: carl at media.org (Carl Malamud)
Date: Sun Jan  2 10:56:49 2005
Subject: [xml2rfc] seriesInfo for Internet Drafts
In-Reply-To: <41D8146E.3060501@gmx.de>
Message-ID: <200501021856.j02Iud34015074@bulk.resource.org>

> Converting <http://ftp.ietf.org/internet-drafts/all_id.txt> is quite 
> simple (although of course it would be much more conventient if it would 
> be available in XML format in the first place).

This doesn't work?

http://xml.resource.org/public/rfc/bibxml3/index.xml

Best regards,

Carl
>From julian.reschke at gmx.de  Sun Jan  2 20:11:04 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun Jan  2 11:11:26 2005
Subject: [xml2rfc] seriesInfo for Internet Drafts
In-Reply-To: <200501021856.j02Iud34015074@bulk.resource.org>
References: <200501021856.j02Iud34015074@bulk.resource.org>
Message-ID: <41D84748.4090002@gmx.de>

Carl Malamud wrote:
>>Converting <http://ftp.ietf.org/internet-drafts/all_id.txt> is quite 
>>simple (although of course it would be much more conventient if it would 
>>be available in XML format in the first place).
> 
> 
> This doesn't work?
> 
> http://xml.resource.org/public/rfc/bibxml3/index.xml
> 
> Best regards,
> 
> Carl

Interesting.

Several problems here:

- the XML is broken (Firefox says:

"XML Parsing Error: not well-formed
Location: http://xml.resource.org/public/rfc/bibxml3/index.xml
Line Number 75378, Column 86:<t>This paper shows that the currently 
defined per-message hop-by-hop mechanism doesn"

(how is this file being generated?)

- it doesn't contain information about drafts that have been published 
as RFC in the meantime


Maybe if we can fix those issues, it could be used...

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From fenner at research.att.com  Sun Jan  2 11:25:59 2005
From: fenner at research.att.com (Bill Fenner)
Date: Sun Jan  2 11:26:05 2005
Subject: [xml2rfc] seriesInfo for Internet Drafts
References: <200501021856.j02Iud34015074@bulk.resource.org>
	<41D84748.4090002@gmx.de>
Message-ID: <200501021926.j02JQ0E20591@windsor.research.att.com>


I think the index.xml that Carl pointed to has a different purpose - it
doesn't say when an I-D is expired or changed (e.g., all_id.txt lets
you warn when someone references draft-peterson-sip-identity that it
should change to draft-ietf-sip-identity, or when someone references
draft-fenner-traceroute-ipm that it's expired, or when someone
references draft-ietf-idmr-igmp-v3 that it's now RFC 3376).

  Bill
>From carl at media.org  Sun Jan  2 13:01:56 2005
From: carl at media.org (Carl Malamud)
Date: Sun Jan  2 13:02:17 2005
Subject: [xml2rfc] seriesInfo for Internet Drafts
In-Reply-To: <200501021926.j02JQ0E20591@windsor.research.att.com>
Message-ID: <200501022101.j02L1uT1007113@bulk.resource.org>

Hi Bill -

It seems that your sql database has all that is needed to
regenerate all_id.txt and more ... any chance you could
smop an index?  I bet lots of folks could use that.  I
know IETF corporate is supposed to generate that stuff,
but until they do, I don't think it would hurt to
have a non-authoritative xml feed.  

Regards,

Carl

> 
> I think the index.xml that Carl pointed to has a different purpose - it
> doesn't say when an I-D is expired or changed (e.g., all_id.txt lets
> you warn when someone references draft-peterson-sip-identity that it
> should change to draft-ietf-sip-identity, or when someone references
> draft-fenner-traceroute-ipm that it's expired, or when someone
> references draft-ietf-idmr-igmp-v3 that it's now RFC 3376).
> 
>   Bill
> 
>From fenner at research.att.com  Sun Jan  2 18:28:27 2005
From: fenner at research.att.com (Bill Fenner)
Date: Sun Jan  2 18:28:37 2005
Subject: [xml2rfc] seriesInfo for Internet Drafts
Message-ID: <200501030228.j032SRX25225@windsor.research.att.com>


>It seems that your sql database has all that is needed to
>regenerate all_id.txt and more ... any chance you could
>smop an index?

Yup, I could generate xml from my combo of all_id.txt and 1id_abstracts.txt
if that would be useful.  http://rtg.ietf.org/~fenner/ietf/id-combo.xml
is a draft... suggestions for form changes welcome, right now it's
basically a dump of the mysql data and field names.

  Bill
>From fenner at gmail.com  Sun Jan  2 18:37:03 2005
From: fenner at gmail.com (Bill Fenner)
Date: Sun Jan  2 18:37:13 2005
Subject: [xml2rfc] seriesInfo for Internet Drafts
In-Reply-To: <41D84748.4090002@gmx.de>
References: <200501021856.j02Iud34015074@bulk.resource.org>
	 <41D84748.4090002@gmx.de>
Message-ID: <ed6d469d05010218371acb2f7d@mail.gmail.com>

On Sun, 02 Jan 2005 20:11:04 +0100, Julian Reschke
<julian.reschke@gmx.de> wrote:
> - the XML is broken (Firefox says:
> 
> "XML Parsing Error: not well-formed
> Location: http://xml.resource.org/public/rfc/bibxml3/index.xml
> Line Number 75378, Column 86:<t>This paper shows that the currently
> defined per-message hop-by-hop mechanism doesn"

This is an encoding error; the next character is iso-8859-1 but the
XML doesn't have an encoding specified so it's assumed to be UTF-8.

  Bill
>From mrose at dbc.mtview.ca.us  Sun Jan  2 19:06:19 2005
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Sun Jan  2 19:06:27 2005
Subject: [xml2rfc] seriesInfo for Internet Drafts
In-Reply-To: <41D84748.4090002@gmx.de>
References: <200501021856.j02Iud34015074@bulk.resource.org>
	<41D84748.4090002@gmx.de>
Message-ID: <70A8EAE5-5D34-11D9-B4A6-000A95CA7FAE@dbc.mtview.ca.us>

>
>
> - the XML is broken (Firefox says:
>
> "XML Parsing Error: not well-formed
> Location: http://xml.resource.org/public/rfc/bibxml3/index.xml
> Line Number 75378, Column 86:<t>This paper shows that the currently 
> defined per-message hop-by-hop mechanism doesn"

as bill points out, encoding error. fixed now.


> - it doesn't contain information about drafts that have been published 
> as RFC in the meantime

true. it's automatically built from id-abstracts.txt

/mtr