--On Saturday, May 07, 2011 09:12 +0200 Julian Reschke
<[email protected]> wrote:

> On 07.05.2011 04:19, John C Klensin wrote:
>> ...
>> No.  If you look at 4409, you will see several citations, of
>> which one example is "[SMTP-MTA]".  In 4409, the corresponding
>> reference is:
>>     Postel... RFC 821...
>>     Partridge... RFC 974...
>>     Braden... RFC 1123...
>>     Klensin... RFC 2821...
>> i.e., "compound references" in the sense that one anchor
>> identifies a list of RFCs.  While 4409 doesn't use it, exactly
>> the same problem arises if one chooses to cite an STD or BCP
>> number that identifies multiple RFCs. That is the construction
>> to which I claim that xml2rfc is hostile -=the only elegant
>> way to do it in the current design would be
>>   <reference anchor="SMTP-MTA">
>>        <reference>...Postel... RFC 821...</reference>
>>        <reference>...Partridge... RFC 974...</reference>
>>        <reference>...Braden... RFC 1123...</reference>
>>        <reference>...Klensin... RFC 2821...</reference>
>>   </reference>
>> 
>> And neither nested reference elements nor reference elements
>> without anchors are permitted by the DTD.
>> ...
> 
> If this is used a lot, we should consider adding it. Is it?

Julian, 

This is probably not the right place to have the discussion.
The general reference-mess topic has been discussed on the
xml2rfc list several times and has never gone anywhere.  The
issue above was, and remains, one of the main topics.  The other
two are how one references a chapter in a book that is an edited
compilation by multiple authors and how one handles journal
articles.  Conventional styles for the first look something like:

          Jones, J., "The flavors of Kool-Aid", in Beelzebub,
        S., _Cults We Have Enjoyed_, Hades Publishing, 2012.
        Originally published in _Jonestown Chronicles_, November
        1978.

sometimes with chapter and/or page numbers.  Ordinarily, if two
articles are cited in the same book, either the second one
appears as

        Jones, M., "Optimal tub size", in Beelzebub, Op. Cit.
or, depending on the style manual,
        Jones, M., "Optimal tub size", in Beel2012.


Or the book is listed separately in the references and then
cited from both chapter references.  Those arrangements are hard
to set up, especially since one cannot put <xref> elements into
any of the elements of <reference>.

For the second, one normally sees the article's author, the
article title, the journal title, volume and issue numbers, a
date, and a range of page numbers.

To some extent, both can be faked with <seriesInfo>, but some of
the tricks I've seen to do it that way seriously violate generic
markup principles and require patching by the RFC Editor at the
nroff stage.  

>> The example you cite above is one of multiple citations at the
>> same point rather than a single compound citation..  And,
>> indeed, most style manuals (along with 4409) prefer
>> "[SMTP-MTA, ESMTP]" to "[SMTP-MTA][ESMTP]".  FWIW, I think
>> the tools should help us get thing right rather than forcing
>> us to do things that are wrong.  But so it goes.
> 
> You can do this with xmlrfc when using the tools from
> rfc2629.xslt as preprocessor, see, for example,
> <http://greenbytes.de/tech/webdav/rfc2629xslt/testcase.html#rf
> c.section.5.11>.

Right.  But I don't really care what shows up in I-Ds.  As far
as I know, the only way to do it for RFCs involves putting in a
comment, something like:
           <!-- RFC Editor: please fix this so it comes out as
        [Ref1,Ref2] and not [Ref1][Ref2] -->

Pretty easy to fix in the nroff, but it makes the idea of using
xml2rfc as a final markup form pretty delusional unless the
marked-up files are used with a really powerful style sheet or
equivalent (rfc2626.xslt is a major step in that direction but,
IMO, the answer to a different question).

> Finally, I think somewhere else I saw discussion about putting
> additional information into references... There's the
> <annotation> element for that.

I use <annotation> regularly for odd situations.  Indeed, my
first working/test versions of making XML from 4409 ended up
with arrangements like

 <reference anchor="SMTP-MTA">
      <front>
         <title>Simple Mail Transfer Protocol</title>
         <author initials="J." surname="Klensin" ></author>
         <date month="October" year="2001" />
      </front>
           <annotation>
      Postel, J., "Simple Mail Transfer Protocol", STD
      10, RFC 821, August 1982.

      Partridge, C., "Mail routing and the domain
      system", STD 10, RFC 974, January 1986.

      Braden, R., "Requirements for Internet Hosts -
      Application and Support", STD 3, RFC 1123, October
      1989.

      Klensin, J., "Simple Mail Transfer Protocol", RFC
      2821, April 2001. </annotation>
    </reference>

That was sufficient to get things to compile so that I could do
a diff on the substantive part, but it illustrates the major
problem with <annotation>, which is that one really needs it to
either behave like <t> or permit <t> in its content so that one
can format things, build lists, insert cross-references, etc.
(fwiw, the same comment applies to <cref>, which is also much
less useful than it might be because it requires CTEXT).  The
minor problem is that the break and vertical spacing associated
with <annotation> are appropriate in some situations and not in
others, resulting in more "please make this format in a
reasonable way" notes to the RFC Editor.

As far as whether it is "used a lot", there is an unfortunate
cause and effect interaction.  Make it hard enough to do things
the right way and all but the most stubborn people stop.  There
are lots of circumstances in which we should be referencing STDs
or BCPs, not RFCs, but the difficulties of doing that with
xml2rfc result in the choice not even being thought about.  Or
we have to result in notes to the RFC Editor... an approach that
is error-prone and extra work for everyone.  So it is not
possible to document how much it is used, much less how much it
would be used if doing so were logical and convenient.

best regards,
   john


_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam

Reply via email to