From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Tue, 31 Dec 2002 08:54:48 -0800
Subject: [xml2rfc] xml2rfc v1.15 released
In-Reply-To: <E18TKbP-000Bro-00@roam.psg.com>
References: <20021209215923.5f75e87d.mrose+internet.xml2rfc@dbc.mtview.ca.us> <E18TKbP-000Bro-00@roam.psg.com>
Message-ID: <20021231085448.600a546e.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> 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: randy@psg.com (Randy Bush)
Date: Tue, 31 Dec 2002 03:30:32 -0800
Subject: [xml2rfc] xml2rfc v1.15 released
References: <20021209215923.5f75e87d.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <E18TKbP-000Bro-00@roam.psg.com>

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: randy@psg.com



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: Chris.Newman@Sun.COM (Chris Newman)
Date: Fri, 20 Dec 2002 17:55:13 -0800
Subject: [xml2rfc] ABNF verification of RFC 2629
Message-ID: <2147483647.1040406913@nifty-jr.west.sun.com>

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: Chris.Newman@Sun.COM (Chris Newman)
Date: Fri, 20 Dec 2002 17:51:37 -0800
Subject: [xml2rfc] potential updates to 2629
In-Reply-To: <20021218221309.61f3ebc9.mrose+internet.xml2rfc@dbc.mtview.ca.us>
References: <20021218221309.61f3ebc9.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <2147483647.1040406697@nifty-jr.west.sun.com>

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
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc




From: GK@ninebynine.org (Graham Klyne)
Date: Thu, 19 Dec 2002 17:03:09 +0000
Subject: [xml2rfc] potential updates to 2629
In-Reply-To: <200212191402.gBJE1Ktx001860@sandelman.ottawa.on.ca>
References: <Your message of "Wed, 18 Dec 2002 22:13:09 PST." <20021218221309.61f3ebc9.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <5.1.0.14.2.20021219170008.0438a830@127.0.0.1>

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
<GK@NineByNine.org>



From: swb@employees.org (Scott W Brim)
Date: Thu, 19 Dec 2002 10:05:40 -0500
Subject: [xml2rfc] potential updates to 2629
In-Reply-To: <20021218221309.61f3ebc9.mrose+internet.xml2rfc@dbc.mtview.ca.us>
References: <20021218221309.61f3ebc9.mrose+internet.xml2rfc@dbc.mtview.ca.us>
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: mcr@sandelman.ottawa.on.ca (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." <20021218221309.61f3ebc9.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <200212191402.gBJE1Ktx001860@sandelman.ottawa.on.ca>

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


>>>>> "Marshall" == Marshall Rose <mrose+internet.xml2rfc@dbc.mtview.ca.us> 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[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

		
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBPgHRLoqHRg3pndX9AQFV5AP/bdS9gHye10v3z8uM9Szb1BT2cAKeClxn
YiO0HMyYZaP0ZUFsNDxaRqYpIyCxKQ99tC0XgyCUV/pWIbg2o8hGoLmVC82L1OBB
Pn+jlKHti87Pvof3DTpJw2OcgZv3gYr3qlBUA7l/K0K57k5c3L7jWlnwv5iBe9P8
/QzSgNla/Kc=
=76IW
-----END PGP SIGNATURE-----


From: GK@ninebynine.org (Graham Klyne)
Date: Thu, 19 Dec 2002 12:30:27 +0000
Subject: [xml2rfc] potential updates to 2629
In-Reply-To: <20021218221309.61f3ebc9.mrose+internet.xml2rfc@dbc.mtview. ca.us>
Message-ID: <5.1.0.14.2.20021219121402.03a48e10@127.0.0.1>

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
<GK@NineByNine.org>



From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Wed, 18 Dec 2002 22:13:09 -0800
Subject: [xml2rfc] potential updates to 2629
Message-ID: <20021218221309.61f3ebc9.mrose+internet.xml2rfc@dbc.mtview.ca.us>

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: Jeff.Hodges@sun.com (Jeff Hodges)
Date: Tue, 17 Dec 2002 16:00:26 -0800
Subject: [xml2rfc] xml2sgml chokes on <list> element
Message-ID: <3DFFBA9A.B58AD345@sun.com>

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>Jeff.Hodges@Sun.com</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: Jeff.Hodges@sun.com (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: <3DFF61CE.BECA1D0B@sun.com>

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: julian.reschke@gmx.de (Julian Reschke)
Date: Tue, 10 Dec 2002 21:38:47 +0100
Subject: [xml2rfc] xml2rfc v1.15 released
In-Reply-To: <20021210112527.1bfcdb55.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <JIEGINCHMLABHJBIGKBCMEHDFPAA.julian.reschke@gmx.de>

> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of Marshall Rose
> Sent: Tuesday, December 10, 2002 8:25 PM
> To: Chris Newman
> Cc: mrose+internet.xml2rfc@dbc.mtview.ca.us;
> xml2rfc@lists.xml.resource.org
> 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: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Tue, 10 Dec 2002 11:25:27 -0800
Subject: [xml2rfc] xml2rfc v1.15 released
In-Reply-To: <2147483647.1039517700@h-192-18-127-205.red.iplanet.com>
References: <20021209215923.5f75e87d.mrose+internet.xml2rfc@dbc.mtview.ca.us> <2147483647.1039517700@h-192-18-127-205.red.iplanet.com>
Message-ID: <20021210112527.1bfcdb55.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> 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: Chris.Newman@Sun.COM (Chris Newman)
Date: Tue, 10 Dec 2002 10:55:00 -0800
Subject: [xml2rfc] xml2rfc v1.15 released
In-Reply-To: <20021209215923.5f75e87d.mrose+internet.xml2rfc@dbc.mtview.ca.us>
References: <20021209215923.5f75e87d.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <2147483647.1039517700@h-192-18-127-205.red.iplanet.com>

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: mrose+internet.xml2rfc@dbc.mtview.ca.us (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: <20021210102059.48d46bf1.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> 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: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Mon, 9 Dec 2002 21:59:23 -0800
Subject: [xml2rfc] xml2rfc v1.15 released
Message-ID: <20021209215923.5f75e87d.mrose+internet.xml2rfc@dbc.mtview.ca.us>

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: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Wed, 4 Dec 2002 19:59:16 -0800
Subject: [xml2rfc] Feature Request: needLines
In-Reply-To: <2147483647.1039024197@nifty-jr.west.sun.com>
References: <2147483647.1039007850@nifty-jr.west.sun.com> <20021204134455.719c1b0d.mrose+internet.xml2rfc@dbc.mtview.ca.us> <2147483647.1039024197@nifty-jr.west.sun.com>
Message-ID: <20021204195916.1e2e3d10.mrose+internet.xml2rfc@dbc.mtview.ca.us>

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: Chris.Newman@Sun.COM (Chris Newman)
Date: Wed, 04 Dec 2002 17:49:57 -0800
Subject: [xml2rfc] Feature Request: needLines
In-Reply-To: <20021204134455.719c1b0d.mrose+internet.xml2rfc@dbc.mtview.ca.us>
References: <2147483647.1039007850@nifty-jr.west.sun.com> <20021204134455.719c1b0d.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <2147483647.1039024197@nifty-jr.west.sun.com>

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: tony@att.com (Tony Hansen)
Date: Wed, 04 Dec 2002 17:22:44 -0500
Subject: [xml2rfc] Feature Request: needLines
In-Reply-To: <20021204134455.719c1b0d.mrose+internet.xml2rfc@dbc.mtview.ca.us>
References: <2147483647.1039007850@nifty-jr.west.sun.com> <20021204134455.719c1b0d.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <3DEE8034.3000305@att.com>

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
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc



From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Wed, 4 Dec 2002 14:00:00 -0800
Subject: [xml2rfc] V1.14: trouble with <figure anchor="something">
In-Reply-To: <20021204194757.000066a1.henrik@levkowetz.com>
References: <20021204194757.000066a1.henrik@levkowetz.com>
Message-ID: <20021204140000.288f58f5.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> 	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: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Wed, 4 Dec 2002 13:44:55 -0800
Subject: [xml2rfc] Feature Request: needLines
In-Reply-To: <2147483647.1039007850@nifty-jr.west.sun.com>
References: <2147483647.1039007850@nifty-jr.west.sun.com>
Message-ID: <20021204134455.719c1b0d.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> 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: chris.newman+xml2rfc@innosoft.com (Chris Newman)
Date: Wed, 04 Dec 2002 13:17:30 -0800
Subject: [xml2rfc] Feature Request: needLines
Message-ID: <2147483647.1039007850@nifty-jr.west.sun.com>

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: henrik@levkowetz.com (Henrik Levkowetz)
Date: Wed, 4 Dec 2002 19:47:57 +0100
Subject: [xml2rfc] V1.14: trouble with <figure anchor="something">
Message-ID: <20021204194757.000066a1.henrik@levkowetz.com>

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 henrik@ipunplugged.com 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

LS0tIHhtbDJyZmMudGNsCTIwMDItMTItMDQgMTk6MjA6MTEuMDAwMDAwMDAwICswMTAwCisrKyB4
bWwycmZjMi50Y2wJMjAwMi0xMi0wNCAxOToxOTo1Ni4wMDAwMDAwMDAgKzAxMDAKQEAgLTQ5OTMs
MTIgKzQ5OTMsMTIgQEAKICAgICAgICAgICAgIGlmIHshW2hhdmVfbGluZXMgJGxpbmVzXX0gew0K
ICAgICAgICAgICAgICAgICBlbmRfcGFnZV90eHQNCiAgICAgICAgICAgICB9DQotICAgICAgICAg
ICAgaWYge1tzdHJpbmcgY29tcGFyZSAkdGl0bGUgIiJdfSB7DQotICAgICAgICAgICAgICAgIHdy
aXRlX2xpbmVfdHh0ICIiDQotICAgICAgICAgICAgICAgIHdyaXRlX2xpbmVfdHh0IFwNCi0gICAg
ICAgICAgICAgICAgICAgICIgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0iDQotICAgICAgICAgICAgICAgIHdyaXRl
X2xpbmVfdHh0ICIiDQotICAgICAgICAgICAgfQ0KKyMgICAgICAgICAgICBpZiB7W3N0cmluZyBj
b21wYXJlICR0aXRsZSAiIl19IHsNCisjICAgICAgICAgICAgICAgIHdyaXRlX2xpbmVfdHh0ICIi
DQorIyAgICAgICAgICAgICAgICB3cml0ZV9saW5lX3R4dCBcDQorIyAgICAgICAgICAgICAgICAg
ICAgIiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLSINCisjICAgICAgICAgICAgICAgIHdyaXRlX2xpbmVfdHh0ICIi
DQorIyAgICAgICAgICAgIH0NCiAgICAgICAgIH0NCiANCiAgICAgICAgIGVuZCB7DQpAQCAtNTAw
OSwxMiArNTAwOSwyMiBAQAogICAgICAgICAgICAgICAgIH0gZWxzZSB7DQogICAgICAgICAgICAg
ICAgICAgICBzZXQgcHJlZml4ICIiDQogICAgICAgICAgICAgICAgIH0NCisJICAgIH0gZWxzZSB7
DQorICAgICAgICAgICAgICAgIGlmIHtbc3RyaW5nIGNvbXBhcmUgJGFuY2hvciAiIl19IHsNCisg
ICAgICAgICAgICAgICAgICAgIGFycmF5IHNldCBhdiAkeHJlZigkYW5jaG9yKQ0KKyAgICAgICAg
ICAgICAgICAgICAgc2V0IHByZWZpeCAiRmlndXJlICRhdih2YWx1ZSkiDQorICAgICAgICAgICAg
ICAgIH0gZWxzZSB7DQorICAgICAgICAgICAgICAgICAgICBzZXQgcHJlZml4ICIiDQorICAgICAg
ICAgICAgICAgIH0NCisJICAgIH0NCisgICAgICAgICAgICBpZiB7W3N0cmluZyBjb21wYXJlICRw
cmVmaXggIiJdfSB7DQorDQogICAgICAgICAgICAgICAgIHdyaXRlX2xpbmVfdHh0ICIiDQogICAg
ICAgICAgICAgICAgIHdyaXRlX3RleHRfdHh0ICIkcHJlZml4W2NoYXJzX2V4cGFuZCAkdGl0bGVd
IiBjDQogICAgICAgICAgICAgICAgIHdyaXRlX2xpbmVfdHh0ICIiDQotICAgICAgICAgICAgICAg
IHdyaXRlX2xpbmVfdHh0IFwNCi0gICAgICAgICAgICAgICAgICAgICIgICAtLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0i
DQotICAgICAgICAgICAgICAgIHdyaXRlX2xpbmVfdHh0ICIiDQorICMgICAgICAgICAgICAgICB3
cml0ZV9saW5lX3R4dCBcDQorICMgICAgICAgICAgICAgICAgICAgIiAgIC0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSIN
CisgIyAgICAgICAgICAgICAgIHdyaXRlX2xpbmVfdHh0ICIiDQogICAgICAgICAgICAgfQ0KICAg
ICAgICAgfQ0KICAgICB9DQpAQCAtNzA1OCwxMSArNzA2OCwxMSBAQAogICAgICAgICAgICAgICAg
IGVuZF9wYWdlX25yDQogICAgICAgICAgICAgfQ0KICAgICAgICAgICAgIGZsdXNoX3RleHQNCi0g
ICAgICAgICAgICBpZiB7W3N0cmluZyBjb21wYXJlICR0aXRsZSAiIl19IHsNCi0gICAgICAgICAg
ICAgICAgd3JpdGVfbGluZV9uciAiIg0KLSAgICAgICAgICAgICAgICB3cml0ZV9saW5lX25yIFwN
Ci0gICAgICAgICAgICAgICAgICAgICItLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0iDQotICAgICAgICAgICAgICAgIHdy
aXRlX2xpbmVfbnIgIiINCisjICAgICAgICAgICAgaWYge1tzdHJpbmcgY29tcGFyZSAkdGl0bGUg
IiJdfSB7DQorIyAgICAgICAgICAgICAgICB3cml0ZV9saW5lX25yICIiDQorIyAgICAgICAgICAg
ICAgICB3cml0ZV9saW5lX25yIFwNCisjICAgICAgICAgICAgICAgICAgICAiLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
Ig0KKyMgICAgICAgICAgICAgICAgd3JpdGVfbGluZV9uciAiIg0KICAgICAgICAgICAgIH0NCiAg
ICAgICAgIH0NCiANCkBAIC03MDc0LDEyICs3MDg0LDIxIEBACiAgICAgICAgICAgICAgICAgfSBl
bHNlIHsNCiAgICAgICAgICAgICAgICAgICAgIHNldCBwcmVmaXggIiINCiAgICAgICAgICAgICAg
ICAgfQ0KKwkgICAgfSBlbHNlIHsNCisgICAgICAgICAgICAgICAgaWYge1tzdHJpbmcgY29tcGFy
ZSAkYW5jaG9yICIiXX0gew0KKyAgICAgICAgICAgICAgICAgICAgYXJyYXkgc2V0IGF2ICR4cmVm
KCRhbmNob3IpDQorICAgICAgICAgICAgICAgICAgICBzZXQgcHJlZml4ICJGaWd1cmUgJGF2KHZh
bHVlKSINCisgICAgICAgICAgICAgICAgfSBlbHNlIHsNCisgICAgICAgICAgICAgICAgICAgIHNl
dCBwcmVmaXggIiINCisgICAgICAgICAgICAgICAgfQ0KKwkgICAgfQ0KKyAgICAgICAgICAgIGlm
IHtbc3RyaW5nIGNvbXBhcmUgJHByZWZpeCAiIl19IHsNCiAgICAgICAgICAgICAgICAgd3JpdGVf
bGluZV9uciAiIg0KICAgICAgICAgICAgICAgICB3cml0ZV90ZXh0X25yICIkcHJlZml4W2NoYXJz
X2V4cGFuZCAkdGl0bGVdIiBjDQogICAgICAgICAgICAgICAgIHdyaXRlX2xpbmVfbnIgIiINCi0g
ICAgICAgICAgICAgICAgd3JpdGVfbGluZV9uciBcDQotICAgICAgICAgICAgICAgICAgICAiLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tIg0KLSAgICAgICAgICAgICAgICB3cml0ZV9saW5lX25yICIiDQorIyAgICAgICAg
ICAgICAgICB3cml0ZV9saW5lX25yIFwNCisjICAgICAgICAgICAgICAgICAgICAiLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tIg0KKyMgICAgICAgICAgICAgICAgd3JpdGVfbGluZV9uciAiIg0KICAgICAgICAgICAgIH0N
CiAgICAgICAgIH0NCiAgICAgfQ0K

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