Subject: [TOOLS-DEVELOPMENT] Fwd: Re: [xml2rfc] Keeping some authors off the front page ?

From: Dave Crocker <[email-masked]>
Date: Wed, 15 Jun 2011 13:27:24 -0700

In case the answer to the embedded question is no:  folks responsible for tools 
requirements decisions should track this list...

d/

-------- Original Message --------
Subject: Re: [xml2rfc] Keeping some authors off the front page ?
Date: Wed, 15 Jun 2011 15:58:45 +0200
From: Julian Reschke <[email-masked]>
To: John C Klensin <[email-masked]>
CC: [email-masked], RFC Editor <[email-masked]>

On 2011-06-15 15:38, John C Klensin wrote:
> ...
> But the common characteristic of all three of those things is
> that they are RFC Editor decisions about what to pick up and how
> to use it.  Unless things change, those decisions aren't even
> going to get reviewed this year.  I think our concern with
> XML2RFC ought to be to get the generic markup sufficiently right
> and specific to allow those RFC Editor decisions to evolve,
> rather than requiring elaborate heuristics or document-searching
> if they do.
> ...

Well, if these tool changes came for free, I'd agree.

Right now we have xml2rfc.tcl (with nobody except Tony being able to add
things), rfc2629.xslt (by me, willing to experiment), and the new tool
which is work-in-progress about which I don't know the current status
(are the developers reading this???).

>>> different.  That said, I can live with<contact>, although we'd
>>> probably want to call it something else since we usually don't
>>> list addresses for contributors.
>>
>> Address information is optional anyway.
>
> Sure.  But if one is going to paste information in from
> somewhere else (e.g., as part of a reference retrieved from a
> library), it may show up -- whether or not to display it should
> be a question for the style manual (see above) and/or the output
> processor.

That would be inconsistent with how <author> works today. Not sure that
it makes sense to diverge from that.

> ...
>> I'm with you in defining a specific container element.
>>
>> However: where does the requirement for Index placement come
>> from?
>
> Have a look at draft-hoffman-3536bis.   An index to terms in a
> document like that may be one of the more important types of
> index in the RFC Series.  Now, as you are looking, decide how
> you feel about its formatting and placement.  If you are nearly
> as repelled as I am, the requirement, and/or the requirement for

I'm not repelled at all. (There are lots of other things about the
RFC/ID format I *am* repelled of :-).

> some additional processing directives, should be clear.  To be
> fair to Paul, the decision to let xml2rfc build the index,
> rather than building it by hand and putting it in as artwork,
> was mine.  Of course, the artwork model would have caused its
> own positioning problems, since figures cannot appear in the
> <back>  element.

I don't think that building the index using artwork makes sense, unless
you can manage to generate it properly including page breaks and page
numbers.

That being said; the content model for sections inside <back> is the
same as inside <middle>.

> And then there is the production rule index for rfc5321bis,

URI?

> which I can do with your tools, but not with xml2rfc.  If one
> also decided to index other things there, like explanations of
> commands, one would end up with a need for two separate indexes.
> Another problem, but also another symptom that index and<iref>
> may need rethinking.

In HTTPbis, we put production rules under a common element, such as
"Grammar productions", and then use subitem for the actual entry...

Best regards, Julian
_______________________________________________
xml2rfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/xml2rfc

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net