Subject: [xml2rfc] xref inside cref

From: [email-masked] (Noel Chiappa)
Date: Fri, 6 Jul 2012 14:56:56 -0400 (EDT)

It's very mildly unfortunate that cross section references (xref) inside a
cref don't work - not a big deal, one can always write it out the target
section name.

     Noel

---

From: Julian Reschke <[email-masked]>
Date: Fri, 06 Jul 2012 21:09:57 +0200

On 2012-07-06 20:56, Noel Chiappa wrote:
> ...

Indeed. You can run cleanup-for-DTD.xslt (contained in rfc2629.xslt) as 
a pre-processor, then you can.

Best regards, Julian

---

From: John C Klensin <[email-masked]>
Date: Mon, 23 Jul 2012 13:15:35 -0400

(catching up on past messages before asking a question)

--On Friday, July 06, 2012 14:56 -0400 Noel Chiappa
<[email-masked]> wrote:

> It's very mildly unfortunate that cross section references
> (xref) inside a cref don't work - not a big deal, one can
> always write it out the target section name.

For a variety of reasons, it is a lot more than mildly
unfortunate that <cref>s cannot contain just about anything that
<t> can contain, including <list> and <vspace> elements as well
as <xref> ones.  It is also unfortunately that they cannot be
explicitly anchored so that one can refer to one note from
within another.  If one had those things, it might actually be
possible to use xml2rfc for an incrementally-developed
collaborative document.

However,...

     john

---

From: Nico Williams <[email-masked]>
Date: Mon, 23 Jul 2012 12:42:12 -0500

> possible to use xml2rfc for an incrementally-developed

+1.  Because of this I just use <t> and add square brackets.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 23 Jul 2012 19:48:43 +0200

> possible to use xml2rfc for an incrementally-developed

I recommend opening a ticket in 
<http://trac.tools.ietf.org/tools/xml2rfc/trac/report>, component 
"vocabulary".

Best regards, Julian

---

From: John C Klensin <[email-masked]>
Date: Mon, 23 Jul 2012 14:19:12 -0400

--On Monday, July 23, 2012 12:42 -0500 Nico Williams
<[email-masked]> wrote:

>> unfortunate that <cref>s cannot contain just about anything
>> that <t> can contain, including <list> and <vspace> elements
>> as well as <xref> ones.  It is also unfortunately that they
>> cannot be explicitly anchored so that one can refer to one
>> note from within another.  If one had those things, it might
>> actually be possible to use xml2rfc for an
>> incrementally-developed collaborative document.
> 

Sure.  But, absent <t anchor="XXX"> (probably at least as hard
to even think about than it would be to implement, except
possibly as an element of a list), that leaves one without any
way to create a central way to keep track of these placeholders
and similar comments.  So IMnvHO, use of <t> [[ ... ]]</t> as a
substitute for <t><cref> ... </cref></t> is just substitution
one kludge for another one with a different set of drawbacks.

<rant>
If we really want to think about xml2rfc as the foundation for a
canonical submission format, one prerequisite, IMO, is to start
treating these kludges as serious deficiencies that need to be
fixed, rather than as little tricks that we tell each other
about and add to the oral tradition.
</rant>

    john

---

From: Nico Williams <[email-masked]>
Date: Mon, 23 Jul 2012 13:27:42 -0500

> one kludge for another one with a different set of drawbacks.

Agreed.

> about and add to the oral tradition.

LyX has fewer such deficiencies...  Why not use that?  (I know, just
kidding, sortof, maybe.)

---

From: Julian Reschke <[email-masked]>
Date: Mon, 23 Jul 2012 20:33:32 +0200

> one kludge for another one with a different set of drawbacks.

<cref> *does* take an anchor attribute; what's missing is a way to 
<xref>erence them.

> about and add to the oral tradition.

Indeed.

I've been working on experimental extensions for years, see 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#extensions>; 
but I'm not going to implement in the old TCL code.

The plan was that the new, python-based xml2rfc processor *can* be 
extended more easily; hopefully we'll get there soon (it appears that 
the RFC Production Center hasn't made the switch yet).

Best regards, Julian