Subject: [xml2rfc] xml2rfc v1.15 released
From: [email-masked] (Marshall Rose)
Date: Tue, 31 Dec 2002 08:54:48 -0800

> need-lines is really not great about widows and orphans.  for example,
> one never even gets to touch the appended.
> 
> i think the general approach is a w&o parm which says 
>   o i want at least N lines
>   o please enforce

unfortunately, the authors' section is calculated using a different algorithm
which apparently got broken by a previous update. i've sent you a new copy of
xml2rfc that should fix it. tell me if it does.

/mtr

From: [email-masked] (Randy Bush)
Date: Tue, 31 Dec 2002 03:30:32 -0800
Subject: [xml2rfc] xml2rfc v1.15 released
References: <[email-masked]>
Message-ID: <[email-masked]>

need-lines is really not great about widows and orphans.  for example,
one never even gets to touch the appended.

i think the general approach is a w&o parm which says 
  o i want at least N lines
  o please enforce

randy

---

Authors' Addresses

   Randy Bush
   IIJ
   5147 Crystal Springs
   Bainbrisge Island, WA  98110
   US

   Phone: +1 206 780 0431
   EMail: [email-masked]

Bush & Damas              Expires May 2, 2003                   [Page 2]
^L
Internet-Draft       Delegation of 2.0.0.2.ip6.arpa        November 2002

   URI:   http://psg.com/~randy/

From: [email-masked] (Chris Newman)
Date: Fri, 20 Dec 2002 17:55:13 -0800
Subject: [xml2rfc] ABNF verification of RFC 2629
Message-ID: <[email-masked]>

If you paste RFC 2629 content into the ABNF validator at:

  http://www.apps.ietf.org/abnf.html

it will extract and validate only the subset of the content that is 
labelled with the tag: <artwork type="abnf">

        Enjoy,
        - Chris

From: [email-masked] (Chris Newman)
Date: Fri, 20 Dec 2002 17:51:37 -0800
Subject: [xml2rfc] potential updates to 2629
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Please also consider adding anchors to automatically numbered lists.  It'd 
be nice if I insert an item in the list not to have to manually renumber 
the xrefs to other items.

The features below sound like reasonable additions, although "type" doesn't 
seem like the right label for item 2.

We should also consider a registry for artwork types.

                - Chris

begin quotation by Marshall Rose on 2002/12/18 22:13 -0800:

> i've been talking with henning schulzrinne about a potential update to
> 2629.
> while it's true, on general principles, that i'm against adding much
> complexity to 2629, some good issues have been raised in looking at how
> folks use LaTeX to do RFCs.
>
> specifically, here are three potential additions. the purpose of this
> note is to solicit input from the xml2rfc community to see what everyone
> thinks:
>
>
> 1. add a new element for terminology, e.g.,
>
>       <term type="rfc2119">MUST</term>
>
> values for the "type" attribute will probably have to be defined in an
> IANA enumerated registry.
>
> there would also have to be optional attributes for anchor
> definition/targets in order to let the processor catch terms that aren't
> defined.
>
>
> 2. add a new optional attribute for paragraphs, e.g.,
>
>       <t type="Motivation">  ... </t>
>
> which, if present, generates a label and the associated indented text.
>
>
> 3. add some kind of table structure, e.g.,
>
>       <table>
>       <row><col>...</col><col>...</col><col>...</col></row>
>           ...
>       </table>
>
> where each <col/> element has a couple of optional attributes to denote
> column type (e.g., a heading) and alignment (e.g., left-justified).
>
>
> after studying this for a week, i think that this kind of functionality
> would be useful for rfc authors. however, i am concerned that we don't
> open the door here and invite a whole bunch of changes that are contrary
> to the basic simplicity of 2629.
>
> comments?
>
> /mtr
>
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc

From: [email-masked] (Graham Klyne)
Date: Thu, 19 Dec 2002 17:03:09 +0000
Subject: [xml2rfc] potential updates to 2629
In-Reply-To: <[email-masked]>
References: <Your message of "Wed, 18 Dec 2002 22:13:09 PST." <[email-masked]>
Message-ID: <[email-masked]>

At 09:01 AM 12/19/02 -0500, Michael Richardson wrote:
>1) somehow simplify marking things as ASCII art, and provide ways to insert
>    alternate views (good for HTML and LaTeX formatted output)
>    (Or do we have this already?)

Yes, for example:

[[
       <figure>
         <artwork src="HomeNetwork.gif" alt="Illustration of home network 
elements"/>
       </figure>
]]

#g

-------------------
Graham Klyne
<[email-masked]>

From: [email-masked] (Scott W Brim)
Date: Thu, 19 Dec 2002 10:05:40 -0500
Subject: [xml2rfc] potential updates to 2629
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <20021219150540.GS1024@SBRIM-W2K1>

On Wed, Dec 18, 2002 10:13:09PM -0800, Marshall Rose allegedly wrote:
> 1. add a new element for terminology, e.g.,
>       
>       <term type="rfc2119">MUST</term>
>     
> values for the "type" attribute will probably have to be defined in an
> IANA enumerated registry.
> 
> there would also have to be optional attributes for anchor
> definition/targets in order to let the processor catch terms that aren't
> defined.

Is this essentially an indented paragraph with (optionally bold) label?
Why not just support a generic?

> 2. add a new optional attribute for paragraphs, e.g.,
>       
>       <t type="Motivation">  ... </t>
>       
> which, if present, generates a label and the associated indented text.

Same.  Is this just like the above under a different name, or with
different indentation, or a block paragraph with a bold first couple
words?  I believe in generics, not instances.

> 3. add some kind of table structure, e.g.,

Yes, I'd like simple tables.  Be ready for column spanning.

Thanks...Scott

From: [email-masked] (Michael Richardson)
Date: Thu, 19 Dec 2002 09:01:19 -0500
Subject: [xml2rfc] potential updates to 2629
In-Reply-To: Your message of "Wed, 18 Dec 2002 22:13:09 PST." <[email-masked]>
Message-ID: <[email-masked]>

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Marshall" == Marshall Rose <[email-masked]> writes:
    Marshall> after studying this for a week, i think that this kind of functionality
    Marshall> would be useful for rfc authors. however, i am concerned that we don't
    Marshall> open the door here and invite a whole bunch of changes that are contrary
    Marshall> to the basic simplicity of 2629.

  I would like to suggest a couple of other things. I respect your desire to
avoid creeping featurism here.

1) somehow simplify marking things as ASCII art, and provide ways to insert
   alternate views (good for HTML and LaTeX formatted output)
   (Or do we have this already?)

2) make sure that we can attach good labels to the art, so that we 
   distinguish the *type* of the diagram. I think of three diagram types
   that are useful:
	a) network diagrams
	b) packet diagrams
	c) time-sequence diagrams

   None of these produces any real difference in the content submitted to the
RFC editor, but has benefit when the .xml files are available otherwise.

3) a way to clearly mark pieces of text that are intended as machine readable.
	a) MIBs
	b) sample vectors	(I wouldn't mind of they of a standard
				format, too...)
	c) code samples (C, perl, whatever)

Again, to the RFC editor, this isn't much different than any other
preformatted text, but it becomes useful to others.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

From: [email-masked] (Graham Klyne)
Date: Thu, 19 Dec 2002 12:30:27 +0000
Subject: [xml2rfc] potential updates to 2629
In-Reply-To: <[email-masked]. ca.us>
Message-ID: <[email-masked]>

I'm responding from a perspective of recent use of XML2RFC to prepare 
non-RFC documents.  I'm finding it a useful way of preparing simple HTML 
documents, where the T0C and bibliography features have been particularly 
helpful.

At 10:13 PM 12/18/02 -0800, Marshall Rose wrote:
>
>1. add a new element for terminology, e.g.,
>
>       <term type="rfc2119">MUST</term>
>
>values for the "type" attribute will probably have to be defined in an
>IANA enumerated registry.
>
>there would also have to be optional attributes for anchor
>definition/targets in order to let the processor catch terms that aren't
>defined.

Hmmm... I'm unclear about the motivation for this.

>
>2. add a new optional attribute for paragraphs, e.g.,
>
>       <t type="Motivation">  ... </t>
>
>which, if present, generates a label and the associated indented text.
>

Coupled with the previous case, this is beginning to look like a kind of 
style tagging, with paragraph- and character-range options.

One of the things I have briefly looked at was the possibility of replacing 
your internal CSS style sheet with a link to an external style sheet, but 
I've noticed that there is some style markup (e.g. the ToC colour and 
document title font) that are hard-coded into the HTML output.

I was thinking of suggesting a PI like:

   <?rfc stylesheet="URI">

which would replace the inline CSS stylesheet you normally generate with a 
link to the indicated URI.

So, I'm wondering if there's a simplification possible here by treating the 
new "type=" attribute on <term> and <t> as a style marker whose 
interpretation is handled separately -- in the case of HTML output, by 
reference to a stylesheet class.  I'm not sure if this relates sensibly to 
the latex use-case.  For plain text output I guess there may be a few 
recognized styles, and the rest be ignored.

While this may seem like an elaboration rather than a simplification, I'm 
thinking that this kind of approach might head off some future suggestions 
for enhancements.

>
>3. add some kind of table structure, e.g.,
>
>       <table>
>       <row><col>...</col><col>...</col><col>...</col></row>
>           ...
>       </table>
>
>where each <col/> element has a couple of optional attributes to denote
>column type (e.g., a heading) and alignment (e.g., left-justified).

Yes, I think a facility for tabular output is very useful.  As for optional 
attributes, maybe just "type=" as above, to hook into the same underlying 
styling mechanisms?

#g

-------------------
Graham Klyne
<[email-masked]>

From: [email-masked] (Marshall Rose)
Date: Wed, 18 Dec 2002 22:13:09 -0800
Subject: [xml2rfc] potential updates to 2629
Message-ID: <[email-masked]>

i've been talking with henning schulzrinne about a potential update to 2629.
    
while it's true, on general principles, that i'm against adding much
complexity to 2629, some good issues have been raised in looking at how
folks use LaTeX to do RFCs.

specifically, here are three potential additions. the purpose of this
note is to solicit input from the xml2rfc community to see what everyone
thinks:

1. add a new element for terminology, e.g.,
      
      <term type="rfc2119">MUST</term>
    
values for the "type" attribute will probably have to be defined in an
IANA enumerated registry.

there would also have to be optional attributes for anchor
definition/targets in order to let the processor catch terms that aren't
defined.

2. add a new optional attribute for paragraphs, e.g.,
      
      <t type="Motivation">  ... </t>
      
which, if present, generates a label and the associated indented text.

3. add some kind of table structure, e.g.,

      <table>
      <row><col>...</col><col>...</col><col>...</col></row>
          ...
      </table>
  
where each <col/> element has a couple of optional attributes to denote
column type (e.g., a heading) and alignment (e.g., left-justified).

after studying this for a week, i think that this kind of functionality
would be useful for rfc authors. however, i am concerned that we don't
open the door here and invite a whole bunch of changes that are contrary
to the basic simplicity of 2629.

comments?

/mtr

From: [email-masked] (Jeff Hodges)
Date: Tue, 17 Dec 2002 16:00:26 -0800
Subject: [xml2rfc] xml2sgml chokes on <list> element
Message-ID: <[email-masked]>

This is a multi-part message in MIME format.
--------------6EC03B8C0ABB8AD88D16C47E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

I've run the attached file, draft-hodges-test-docbook-xml2sgml-00.xml, thru
xml2sgml and it chokes on the <list> element. I can't easily attach the trace
output cuz it comes up in a window whose content isn't selectable (I'm running
xml2sgml on tcl installed on cygwin installed on windoze, fwiw). 

the input file, and the outut file, draft-hodges-test-docbook-xml2sgml-00.sgml,
are attached. 

possible to fix this?

thanks,

JeffH
--------------6EC03B8C0ABB8AD88D16C47E
Content-Type: text/xml; charset=us-ascii;
 name="draft-hodges-test-docbook-xml2sgml-00.xml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-hodges-test-docbook-xml2sgml-00.xml"

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<rfc ipr="full2026" docName="draft-hodges-test-docbook-xml2sgml-00">
  <front>
    <title abbrev="test RFC2629">this is an RFC2629 input file to feed to xml2sgml to see what happens</title>
    <author initials="Jeff" surname="Hodges" fullname="Jeff Hodges">
      <organization>Sun Microsystems, Inc.</organization>
      <address>
        <postal>
          <street>4220 Network Circle, Bldg 22, USCA22-212</street>
          <city>Santa Clara</city>
          <region>CA</region>
          <code>95054</code>
          <country>US</country>
        </postal>
        <phone>+1 408.276.5467</phone>
        <email>[email-masked]</email>
      </address>
    </author>
    <date month="December" year="2002"/>
    <keyword>docbook</keyword>
    <keyword>I-D</keyword>
    <keyword>Internet-Draft</keyword>
    <keyword>XML</keyword>
    <keyword>eXtensible Markup Language</keyword>
    <abstract>
      <t>This memo is a test vehicle to see how conversion to sgml/docbook works.</t>
    </abstract>
  </front>
  <middle>
    <section title="Middle">
      <t>this is yet more text in the doc to see what happens here.</t>
    </section>
    <section title="The Overall Model">
      <figure>
        <preamble>The overall model is depicted in this figure..</preamble>
        <artwork><![CDATA[
        +------------------------------+
        |         bogus layer 1        |
        | . . . . . . . . . . . . . . .|
        |     sub-bogus layer 1a       |
        +------------------------------+
        |       some victim layer      |
        +------------------------------+
        |   innocent bystander layer   |
        +------------------------------+
        |         bedrock layer        |
        +------------------------------+
        ]]></artwork>
        <postamble>"42" is the obvious answer.</postamble>
      </figure>
      <t>this is a paragraph.</t>
      <t>A list is going to follow (style="symbol")...
        <list style="symbol">
          <t>first item.</t>
          <t>second item.</t>
          <t>third and last item.</t>
        </list>
      </t>
    </section>
    <section title="this is a subsection">
      <t>subsection text. 
      </t>
      <t>more subsection text.</t>
    </section>
    <section title="another subsection (peer to the preceding)">
      <section title="sub-subsection">
        <t>text. 
        </t>
        <t>more text.
        </t>
      </section>
    </section>
  </middle>
  <back>
    <section title="Acknowledgements">
      <t>This spec leverages all sorts of prior work in the interest of reuse and laziness.  
     </t>
    </section>
    <section title="References">
    </section>
  </back>
</rfc>

--------------6EC03B8C0ABB8AD88D16C47E
Content-Type: text/html; charset=us-ascii;
 name="draft-hodges-test-docbook-xml2sgml-00.sgml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-hodges-test-docbook-xml2sgml-00.sgml"

<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
<book>
<bookinfo>
<title>this is an RFC2629 input file to feed to xml2sgml to see what happens</title>
<author>
<othername role="initials">Jeff</othername>
<surname>Hodges</surname>
<affiliation>
<orgname>Sun Microsystems, Inc</orgname>
</affiliation>
</author>
<pubdate>December 2002</pubdate>
</bookinfo>
<preface>
<title>Abstract</title>
<para>
This memo is a test vehicle to see how conversion to sgml/docbook works.
</para>
</preface>
<chapter>
<title>Middle</title>
<para>
this is yet more text in the doc to see what happens here.
</para>
</chapter>
<chapter>
<title>The Overall Model</title>
<para>
The overall model is depicted in this figure..
</para>
<screen>

        +------------------------------+
        |         bogus layer 1        |
        | . . . . . . . . . . . . . . .|
        |     sub-bogus layer 1a       |
        +------------------------------+
        |       some victim layer      |
        +------------------------------+
        |   innocent bystander layer   |
        +------------------------------+
        |         bedrock layer        |
        +------------------------------+
        
</screen>
<para>
"42" is the obvious answer.
</para>
<para>
this is a paragraph.
</para>
<para>
A list is going to follow (style="symbol")...
        
--------------6EC03B8C0ABB8AD88D16C47E--

From: [email-masked] (Jeff Hodges)
Date: Tue, 17 Dec 2002 09:41:34 -0800
Subject: [xml2rfc] small bug in http://xml.resource.org/public/rfc/bibxml/index.xml
Message-ID: <[email-masked]>

a nit here, fwiw. this file..

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

..contains a <title> element of..

  <title>The (unofficial) RFC Index (as of December 16, 2002)</title> 

..but xml2rfc chokes on it because it is > 42 chars long (IIRC), and demands an
"abbrev" xml attr for <title>, eg..

    <title abbrev="(unofficial) RFC Index">
      The (unofficial) RFC Index (as of December 13, 2002)
    </title>

JeffH

From: [email-masked] (Julian Reschke)
Date: Tue, 10 Dec 2002 21:38:47 +0100
Subject: [xml2rfc] xml2rfc v1.15 released
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Marshall Rose
> Sent: Tuesday, December 10, 2002 8:25 PM
> To: Chris Newman
> Cc: [email-masked];
> [email-masked]
> Subject: Re: [xml2rfc] xml2rfc v1.15 released
>
>
> > I was just testing this feature (sorry I forgot to test it
> earlier), and it
> > reported a line longer than 72 characters.  However, it reported the
> > position in the output document where the line length was exceeded, but
> > then failed to generate an output document at all.  In order to
> find the
> > offending line I had to switch strict to "no", find the
> offending line in
> > the output, find the matching source line, fix it in the source
> and switch
> > strict back to "yes".
>
> sort of reminds you of the  "information retrieval" department in the film
> brazil: "we're information retrieval, not information disbursement."
>
> let me take a look to see if i can fix that...

rfc2629.xslt will

- provide a warning and
- higlight the offending line in the output (red & bold)

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Marshall Rose)
Date: Tue, 10 Dec 2002 11:25:27 -0800
Subject: [xml2rfc] xml2rfc v1.15 released
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> I was just testing this feature (sorry I forgot to test it earlier), and it 
> reported a line longer than 72 characters.  However, it reported the 
> position in the output document where the line length was exceeded, but 
> then failed to generate an output document at all.  In order to find the 
> offending line I had to switch strict to "no", find the offending line in 
> the output, find the matching source line, fix it in the source and switch 
> strict back to "yes".

sort of reminds you of the  "information retrieval" department in the film
brazil: "we're information retrieval, not information disbursement."

let me take a look to see if i can fix that...

/mtr

From: [email-masked] (Chris Newman)
Date: Tue, 10 Dec 2002 10:55:00 -0800
Subject: [xml2rfc] xml2rfc v1.15 released
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

begin  quotation by Marshall Rose on 2002/12/9 21:59 -0800:
> <?rfc strict="yes" ?>
>
>     to enforce the numerous requirements set forth in the ID-nits document

I was just testing this feature (sorry I forgot to test it earlier), and it 
reported a line longer than 72 characters.  However, it reported the 
position in the output document where the line length was exceeded, but 
then failed to generate an output document at all.  In order to find the 
offending line I had to switch strict to "no", find the offending line in 
the output, find the matching source line, fix it in the source and switch 
strict back to "yes".  It might be better if the location of the offending 
line in the source document was reported instead.

However, the key point here is it found an I-D nit I had missed so that 
indicates the feature is very useful.

                Thanks,
                - Chris

From: [email-masked] (Marshall Rose)
Date: Tue, 10 Dec 2002 10:20:59 -0800
Subject: [xml2rfc] xml2rfc v1.15 released
In-Reply-To: <F92978223B01D311ACFF0008C71EE19D015DFA00@MCHH225E>
References: <F92978223B01D311ACFF0008C71EE19D015DFA00@MCHH225E>
Message-ID: <[email-masked]>

> is there any documentation available on the web describing all
> available 'features' not being described in RFC 2629 like
> <?rfc strict="yes" ?>
> and so on?

good point. it's in the README file in the .tgz/.zip distributions, but i've
also put a link to it on http://xml.resource.org/

/mtr

From: [email-masked] (Marshall Rose)
Date: Mon, 9 Dec 2002 21:59:23 -0800
Subject: [xml2rfc] xml2rfc v1.15 released
Message-ID: <[email-masked]>

besides the usual bugfixes:

<?rfc needLines="N" ?>
    
    to give a hint indicating how many contiguous lines are needed at
    this point in the output
    
<?rfc strict="yes" ?>
    
    to enforce the numerous requirements set forth in the ID-nits document
    
<?rfc iprnotified="yes" ?>
    
    to include the additional IPR-related boilerplate from Section
    10.4(d) of RFC 2026
    
downloads at http://xml.resource.org/

enjoy!
    
/mtr

From: [email-masked] (Marshall Rose)
Date: Wed, 4 Dec 2002 19:59:16 -0800
Subject: [xml2rfc] Feature Request: needLines
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

ok. i agree with you. i'll send you a version that supports

	<?rfc needLines='XX' ?>

tell me if it works the way you expect it to, and if so, i'll put it in the main
release.

/mtr

From: [email-masked] (Chris Newman)
Date: Wed, 04 Dec 2002 17:49:57 -0800
Subject: [xml2rfc] Feature Request: needLines
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

begin quotation by Marshall Rose on 2002/12/4 13:44 -0800:
> the <vspace/> thing was chosen over a needLines facility back in '99.
>
> the reason is that needLines only makes sense if you "know" about layout,
> and in particular, if you know you're rendering as text. in contrast,
> <vspace/> makes sense regardless of what your output format is, and, as a
> side-effect allows an escape-hatch for the "i really want a pagebreak"
> thing.

They are completely different functions.

vspace modifies the underlying document content by adding blank lines.

needLines tweaks the text formatter to improve section layout on pages, but 
has no impact on the underlying document content.

> in other words, it's a compromise that works better than the other
> compromises...

I asked for needLines because it's easy to implement, doesn't change the 
DTD and meets my requirements for text grouping.  vspace does not meet my 
requirements because it corrupts the document content when used for the 
purpose of page breaks.

There is another way to meet the requirement.  Namely to add a generalized 
grouping structure to the DTD and deprecate the specialized 
preamble/postamble support.  So instead of:

<artwork><preamble>...</preamble><figure>...</figure><postamble>...</postam
ble></artwork>

you would have:

<together><t>...</t><figure>...</figure><t>...</t></together>

but could also use the <together> construct in other contexts (e.g. group 
two related list items, group two related references, etc).  The semantics 
of "together" would be to identify text which should be layed out close 
together, preferably not on separate pages or separate columns.

Now since this is open source, you can tell me to go meet my own 
requirement if you don't want to satisfy it, but I'm doing my best to state 
the requirement clearly.

                - Chris

From: [email-masked] (Tony Hansen)
Date: Wed, 04 Dec 2002 17:22:44 -0500
Subject: [xml2rfc] Feature Request: needLines
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

The two seem like opposites. One says "give me at least this much white 
space" or "give me a page break here". Whereas the latter is widow 
control: "don't give me a page break unless there are fewer than this 
many lines of non-white space".

Just an observation; not a recommendation one way or the other.

	Tony

Marshall Rose wrote:
>>I'd like the equivalent of nroff's ".ne 3" (need 3 lines).  This tells the 
>>formatter to insert a pagebreak if there are fewer than 3 lines remaining 
>>on the current page.  This isn't actually document content and thus can be 
>>done with a processing instruction like:
>>
>>  <?rfc needLines="3"?>
>>
>>This is distinctly more useful than the construction:
>>
>>  <vspace blankLines="99" />
>>
>>which forces a pagebreak regardless of the current position on the page, 
>>and thus inherently violates a desirable property of XML: separation 
>>between document content/structure and formatting.
> 
> the <vspace/> thing was chosen over a needLines facility back in '99.
> 
> the reason is that needLines only makes sense if you "know" about layout, and
> in particular, if you know you're rendering as text. in contrast, <vspace/>
> makes sense regardless of what your output format is, and, as a side-effect
> allows an escape-hatch for the "i really want a pagebreak" thing.
> 
> in other words, it's a compromise that works better than the other
> compromises...
> 
> /mtr
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc

From: [email-masked] (Marshall Rose)
Date: Wed, 4 Dec 2002 14:00:00 -0800
Subject: [xml2rfc] V1.14: trouble with <figure anchor="something">
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> 	Anyhow, I attach a diff which changes the behaviour to always
> produce a "Figure N" label if there's an anchor specified, and comments
> out the dashed lines.

thanks, but your patch doesn't install on my system. in private email,
send me the entire proc for "figure_txt" and i'll figure out what
changes to make...

> 	Oh, and by the way, I had to read the code to figure out what
> the rules were with respect to generation of "Figure N" labels or not.
> It might be a good idea to mention the rules in the draft text about 
> figures.

ok, but tell me what you think the rules are.

/mtr

From: [email-masked] (Marshall Rose)
Date: Wed, 4 Dec 2002 13:44:55 -0800
Subject: [xml2rfc] Feature Request: needLines
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> I'd like the equivalent of nroff's ".ne 3" (need 3 lines).  This tells the 
> formatter to insert a pagebreak if there are fewer than 3 lines remaining 
> on the current page.  This isn't actually document content and thus can be 
> done with a processing instruction like:
> 
>   <?rfc needLines="3"?>
> 
> This is distinctly more useful than the construction:
> 
>   <vspace blankLines="99" />
> 
> which forces a pagebreak regardless of the current position on the page, 
> and thus inherently violates a desirable property of XML: separation 
> between document content/structure and formatting.

the <vspace/> thing was chosen over a needLines facility back in '99.

the reason is that needLines only makes sense if you "know" about layout, and
in particular, if you know you're rendering as text. in contrast, <vspace/>
makes sense regardless of what your output format is, and, as a side-effect
allows an escape-hatch for the "i really want a pagebreak" thing.

in other words, it's a compromise that works better than the other
compromises...

/mtr

From: [email-masked] (Chris Newman)
Date: Wed, 04 Dec 2002 13:17:30 -0800
Subject: [xml2rfc] Feature Request: needLines
Message-ID: <[email-masked]>

I'd like the equivalent of nroff's ".ne 3" (need 3 lines).  This tells the 
formatter to insert a pagebreak if there are fewer than 3 lines remaining 
on the current page.  This isn't actually document content and thus can be 
done with a processing instruction like:

  <?rfc needLines="3"?>

This is distinctly more useful than the construction:

  <vspace blankLines="99" />

which forces a pagebreak regardless of the current position on the page, 
and thus inherently violates a desirable property of XML: separation 
between document content/structure and formatting.

                - Chris

From: [email-masked] (Henrik Levkowetz)
Date: Wed, 4 Dec 2002 19:47:57 +0100
Subject: [xml2rfc] V1.14: trouble with <figure anchor="something">
Message-ID: <[email-masked]>

This is a multi-part message in MIME format.

--Multipart_Wed__4_Dec_2002_19:47:57_+0100_08a60718
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Marshall,

	I just now had occasion to use the <figure> anchor and title
attributes for the first time, and ran into what I consider a bug,
and also have a stylistic comment.

	The bug is that with the V 1.14 code, an anchor attribute and/or
reference through an <xref> tag won't force the actual figure to have
any labelling. It seems slightly useless to refer to e.g. "Figure 6" if
figure 6 has not received any label.

	Stylistically, I'm not at all fond of the dashed lines before
and after, which only gets added if there's a title attribute. The
style becomes inconsistent if you don't have a title on all figures,
and the dashed lines break up the flow of the text (in my eyes).

	Anyhow, I attach a diff which changes the behaviour to always
produce a "Figure N" label if there's an anchor specified, and comments
out the dashed lines.

	Oh, and by the way, I had to read the code to figure out what
the rules were with respect to generation of "Figure N" labels or not.
It might be a good idea to mention the rules in the draft text about 
figures.

	Regards,
		Henrik

-- 

Henrik Levkowetz +46708321608 [email-masked] www.ipunplugged.com
------------------------------------------------------------------------

--Multipart_Wed__4_Dec_2002_19:47:57_+0100_08a60718
Content-Type: application/octet-stream;
 name="figure-title.patch"
Content-Disposition: attachment;
 filename="figure-title.patch"
Content-Transfer-Encoding: base64

--Multipart_Wed__4_Dec_2002_19:47:57_+0100_08a60718--