From: Chris.Newman@Sun.COM (Chris Newman)
Date: Tue, 29 Apr 2003 15:07:44 -0700
Subject: [xml2rfc] text tables, proposal 3 (final?)
In-Reply-To: <20030428203516.31a4e7a5.mrose+internet.xml2rfc@dbc.mtview.ca.us>
References: <2147483647.1051184677@nifty-jr.west.sun.com> <20030428203516.31a4e7a5.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <2147483647.1051628864@nifty-jr.west.sun.com>

I believe all issues have been debated sufficiently.

                - Chris

begin quotation by Marshall Rose on 2003/4/28 20:35 -0700:

>> This is the third and hopefully final proposal for the addition of text
>> tables:
>> ...
>
> should i start coding now, or are there other issues?



From: Chris.Newman@Sun.COM (Chris Newman)
Date: Tue, 29 Apr 2003 15:06:20 -0700
Subject: [xml2rfc] text tables, proposal 3 (final?)
In-Reply-To: <JIEGINCHMLABHJBIGKBCOELJHCAA.julian.reschke@gmx.de>
References: <JIEGINCHMLABHJBIGKBCOELJHCAA.julian.reschke@gmx.de>
Message-ID: <2147483647.1051628780@nifty-jr.west.sun.com>

begin quotation by Julian Reschke on 2003/4/29 9:20 +0200:
> 1) Container elements for rows (I don't think that any additional discussion
> really would help resolving this, though, therefore I stopped). Keep in mind
> that we may want metadata on rows in a later extension, so where we put them
> then?

There are two ways to extend the present format to support metadata on rows: 1. 
have row-oriented metadata on the first table cell on the row apply to the 
entire row or 2. add optional row containers.  (no point in discussing the 
relative merits at this point).  Therefore the contention that the present 
format has inadequate extensibility does not hold.  Furthermore I honestly 
don't see the need ever arising for row-based metadata for such a narrowly 
focused document format.  So the additional complexity introduced by row 
containers has not been justified, thus we must not include them.

> 2) I think that optional right alignment really is required for those cases
> where numerical values should align -- I haven't seen a proposal how to live
> without that feature :-)

To summarize previous statements: The present proposal is to left-align all 
table cells including numbers.  Right alignment is a "nice to have" feature, 
but nobody has made a compelling argument that we need it.  Because is a 
low-complexity feature and a number of people have said it is a "nice-to-have" 
feature, then if Marshall feels like including it, I certainly wouldn't object. 
But if simplicity is a high priority in the design, that usually overrides 
"nice to have" features.

> 3) If the processor is supposed to wrap text inside table cells, we should
> offer a way to insert optional hyphenation (see my Unicode based proposal).

While I think your soft-hyphen proposal would be an excellent way to provide an 
optional hyphenation feature, it's not at all clear to me that we need the 
hyphenation feature.  Furthermore, this is a feature that could be added any 
time and does not need to be in the initial table proposal.  Thus I propose we 
add it if and when we determine there is a substantial need for it and not 
delay the base table proposal.

> 4) For now, we should resist the temptation to make table cells more complex
> than absolutely necessary (so please no structural/display based tags such
> as <t> or <vline).

You will note that neither <t> nor <vspace> is permitted in a <c> element in 
the third proposal.  I permitted "vspace" in my second proposal because I 
didn't see a reason to remove it when trimming the "t" element's DTD to create 
the "c" element.  When you rightfully questioned me on that feature, I could 
have made arguments for its inclusion.  But those arguments wouldn't have been 
compelling so I choose not to waste time and simply removed it from the final 
proposal.

                - Chris



From: tony@att.com (Tony Hansen)
Date: Tue, 29 Apr 2003 10:26:53 -0400
Subject: generating NROFF (tbl) tables, was: [xml2rfc] Text Tables in xml2rfc
In-Reply-To: <JIEGINCHMLABHJBIGKBCCEHJHBAA.julian.reschke@gmx.de>
References: <JIEGINCHMLABHJBIGKBCCEHJHBAA.julian.reschke@gmx.de>
Message-ID: <3EAE8BAD.8050704@att.com>

It's been a while, but tbl certainly can support multiple line cells. 
Look up T{ and T}. You'll see stuff like:

.TS
l | l.
Apples	20
Oranges	10
T{
Apples and
Oranges
T}	30
.TE

You can also toss in *roff directives within those lines, such as ".ad", 
".fi" and ".na".

Esentially, ANY time you want a block of text that tbl is to be allowed 
to freely wrap, stuff it in a T{T} block.

	Tony Hansen
	tony@att.com

Julian Reschke wrote:
> OK,
> 
> I have done some experiments with table extensions, both for HTML (simple)
> and NROFF (hard). Maybe somebody on this list knows more about nroff/tbl
> processing and can give me some help...
> 
> Nroff produces tables using "tbl" preprocessing (for instance see manual at:
> http://www.chemie.fu-berlin.de/cgi-bin/man/sgi_irix?tbl+1). This format
> seems to do just about all we need (including different types of
> justification). However, what it doesn't seem to be capable of is to break
> long table cells into multiple lines, such as:
> 
> Apples       20
> Oranges     10
> Apples and
> Oranges     30
> 
> So my first question is: is that a required feature? In which case we'd
> either need to be able to introduce line break hints, or live with the fact
> that we can't use "tbl". Marshall, are you planning to put that kind of
> formatting engine into your TCL code?
> 
> So maybe we should look at the requirements again:
> 
> - free the user from the task of aligning columns himself
> - enhance the markup so that better formatting can be created for output
> formats such as HTML, XSL-FO and PDF.
> 
> Optionally (to be discussed!):
> 
> - cell justification (I think we should have at least right- and
> left-justification) -- is justification per cell (HTML, tbl) or per column
> (simpler), though?
> - decorations (such as rules and boxes, see again tbl manual)
> 
> Regards,
> 
> Julian
> 
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc



From: julian.reschke@gmx.de (Julian Reschke)
Date: Tue, 29 Apr 2003 09:20:45 +0200
Subject: [xml2rfc] text tables, proposal 3 (final?)
In-Reply-To: <20030428203516.31a4e7a5.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <JIEGINCHMLABHJBIGKBCOELJHCAA.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, April 29, 2003 5:35 AM
> To: Chris Newman
> Cc: xml2rfc@lists.xml.resource.org
> Subject: Re: [xml2rfc] text tables, proposal 3 (final?)
>
>
> > This is the third and hopefully final proposal for the addition of text
> > tables:
> > ...
>
> should i start coding now, or are there other issues?
>
> /mtr

>From my p.o.v., the main issues are:

1) Container elements for rows (I don't think that any additional discussion
really would help resolving this, though, therefore I stopped). Keep in mind
that we may want metadata on rows in a later extension, so where we put them
then?

2) I think that optional right alignment really is required for those cases
where numerical values should align -- I haven't seen a proposal how to live
without that feature :-)

3) If the processor is supposed to wrap text inside table cells, we should
offer a way to insert optional hyphenation (see my Unicode based proposal).

4) For now, we should resist the temptation to make table cells more complex
than absolutely necessary (so please no structural/display based tags such
as <t> or <vline).

Julian

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



From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Mon, 28 Apr 2003 20:35:16 -0700
Subject: [xml2rfc] text tables, proposal 3 (final?)
In-Reply-To: <2147483647.1051184677@nifty-jr.west.sun.com>
References: <2147483647.1051184677@nifty-jr.west.sun.com>
Message-ID: <20030428203516.31a4e7a5.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> This is the third and hopefully final proposal for the addition of text
> tables:
> ...
    
should i start coding now, or are there other issues?
    
/mtr


From: Chris.Newman@Sun.COM (Chris Newman)
Date: Fri, 25 Apr 2003 08:50:53 -0700
Subject: [xml2rfc] text tables, proposal 3 (final?)
In-Reply-To: <5.1.0.14.2.20030425111935.00b8c570@127.0.0.1>
References: <5.1.0.14.2.20030425111935.00b8c570@127.0.0.1>
Message-ID: <2147483647.1051260653@dsl108-043.brandx.net>

begin quotation by Graham Klyne on 2003/4/25 11:24 +0100:
> I can accept a choice either way on the column alignment issue.

Ditto.

> A small question:  is column heading text permitted to wrap?  (I don't really
> mind what the answer is, though I'd have a preference for "yes" (i.e. just
> like <c>...</c> text).

yes.

> Again, just checking details, is it intended that just one "paragraph" of
> text is in any cell?  (i.e. no <t>...</t>, or other ways to break text.  I
> guess "yes", and that's fine with me.

yes.  I don't see a need for multiple paragraphs in a table cell.  If there was 
a compelling need, I'd address the problem by permitting vspace in a table 
cell, since that's how xml2rfc addresses the problem for list items.

                - Chris



From: GK@ninebynine.org (Graham Klyne)
Date: Fri, 25 Apr 2003 11:24:07 +0100
Subject: [xml2rfc] text tables, proposal 3 (final?)
In-Reply-To: <2147483647.1051184677@nifty-jr.west.sun.com>
Message-ID: <5.1.0.14.2.20030425111935.00b8c570@127.0.0.1>

At 11:44 24/04/2003 -0700, Chris Newman wrote:
>So at this point, the remaining questions: Do the 
>justifications/motivations for this outweigh the complexity?

It looks good to me.  I can accept a choice either way on the column 
alignment issue.  The justifications offered mostly look fairly compelling 
to me (6 less so).

A small question:  is column heading text permitted to wrap?  (I don't 
really mind what the answer is, though I'd have a preference for "yes" 
(i.e. just like <c>...</c> text).

Again, just checking details, is it intended that just one "paragraph" of 
text is in any cell?  (i.e. no <t>...</t>, or other ways to break text.  I 
guess "yes", and that's fine with me.

#g


-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E



From: aki.niemi@nokia.com (aki.niemi@nokia.com)
Date: Fri, 25 Apr 2003 12:41:34 +0300
Subject: [xml2rfc] text tables, proposal 3 (final?)
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194523B@esebe013.ntc.nokia.com>

Hi,

See inline.

 > Here is a proposed DTD modification:
 > 
 >     <!ELEMENT section     (t|figure|texttable|iref|section)*>
 >     <!ELEMENT texttable   (preamble?,ttcol+,c*,postamble?>
 >     <!ATTLIST texttable
 >               anchor      ID                 #IMPLIED
 >               title       %ATEXT;            "">
 >     <!ELEMENT ttcol       (%TEXT;)>
 >     <!ATTLIST ttcol
 >               width       %ATEXT;           #IMPLIED>
 >     <!ELEMENT c           (%TEXT;|xref|eref|iref)*>
 > 
 > And a "nice to have" feature if Marshall feels like it:
 > 
 >     <!ATTLIST ttcol
 >               width       %ATEXT;           #IMPLIED
 >               align       (left|right)      "left">
 > 
 > Justifications/Motivations:
 > 
 > 1. Tables are a commonly used feature in published RFCs.
 > 2. This syntax allows specification of a basic table 
 > structure in XML without
 >    excessive complexity or manual positioning of table cells.
 > 3. Tables in RFCs can contain text which is indexed or 
 > descriptions which
 >    reference other parts of the document. These features are 
 > not possible
 >    to achieve with artwork unless the references are 
 > manually numbered
 >    and indexes manually constructed.
 > 4. Tables in RFCs often contain word-wrapped text in columns which is
 >    extremely cumbersome to produce with some text editors.
 > 5. API specifications in RFCs do happen, and APIs often use tables of
 >    constants or error return values which need to be indexed.
 > 6. Common typographic practice numbers tables separately 
 > from figures and
 >    references them from within the main text of the specification.
 > 7. A structural representation rather than an artwork representation
 >    of tables permits a higher quality of output for HTML.
 > 
 > So at this point, the remaining questions: Do the 
 > justifications/motivations 
 > for this outweigh the complexity?  

I must admit that points 3 and 6 above are very convincing. In light of these arguments it actually makes sense to add this feature. In addition, I'd vote for the nice-to-have alignment feature, with maybe the following addition:

	  <!ATTLIST ttcol
                  width       %ATEXT;                  #IMPLIED
                  align       (left|right|center)      "left">

For example, tables 2 and 3 in RFC 3261 would probably suffer from not being able to center align cells.

Cheers,
Aki

 > Is Marshall willing to 
 > add this feature to 
 > the TCL implementation?
 > 
 >                 - Chris
 > 
 > _______________________________________________
 > xml2rfc mailing list
 > xml2rfc@lists.xml.resource.org
 > http://lists.xml.resource.org/mailman/listinfo/xml2rfc
 > 


From: henrik@levkowetz.com (Henrik Levkowetz)
Date: Fri, 25 Apr 2003 09:58:42 +0200
Subject: [xml2rfc] text tables, proposal 3 (final?)
In-Reply-To: <2147483647.1051184677@nifty-jr.west.sun.com>
References: <2147483647.1051184677@nifty-jr.west.sun.com>
Message-ID: <20030425095842.420c94f6.henrik@levkowetz.com>

Comparing table support with what is to me a sensible alternative,
doing the tables as artwork, my reactions are:

On Thu, 24 Apr 2003 11:44:37 -0700, Chris Newman <chris@greenhillroad.org> wrote:
> 1. Tables are a commonly used feature in published RFCs.
	Shrug

> 2. This syntax allows specification of a basic table structure in XML without
>    excessive complexity or manual positioning of table cells.
	Artwork would work about as well for me

> 3. Tables in RFCs can contain text which is indexed or descriptions which
>    reference other parts of the document. These features are not possible
>    to achieve with artwork unless the references are manually numbered
>    and indexes manually constructed.
	*This* is a *very* good reason. The minute I needed to <xref />
	from a table, I'd go *wild* over the opportunity to use table
	support instead of manual artwork!

> 4. Tables in RFCs often contain word-wrapped text in columns which is
>    extremely cumbersome to produce with some text editors.
	Shrug

> 5. API specifications in RFCs do happen, and APIs often use tables of
>    constants or error return values which need to be indexed.
	Shrug

> 6. Common typographic practice numbers tables separately from figures and
>    references them from within the main text of the specification.
	Yes, this makes sense. I buy this.

> 7. A structural representation rather than an artwork representation
>    of tables permits a higher quality of output for HTML.
	True, but not important

> So at this point, the remaining questions: Do the justifications/motivations 
> for this outweigh the complexity?  Is Marshall willing to add this feature to 
> the TCL implementation?


Most of all because of point 3. above, my viewpoint is "Marshall, would
you, please?"

	Henrik

-- 
  One way to pick a future is to believe it's inevitable. 
    --Richard Bach


From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Thu, 24 Apr 2003 20:33:13 -0700
Subject: [xml2rfc] text tables, proposal 3 (final?)
In-Reply-To: <2147483647.1051184677@nifty-jr.west.sun.com>
References: <2147483647.1051184677@nifty-jr.west.sun.com>
Message-ID: <20030424203313.76e91c38.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> So at this point, the remaining questions:
> Do the justifications/motivations for this outweigh the complexity?

i'd like to hear from a few folks on this.

    
> Is Marshall willing to add this feature to the TCL implementation?

sure.
    
/mtr


From: chris@greenhillroad.org (Chris Newman)
Date: Thu, 24 Apr 2003 11:44:37 -0700
Subject: [xml2rfc] text tables, proposal 3 (final?)
Message-ID: <2147483647.1051184677@nifty-jr.west.sun.com>

This is the third and hopefully final proposal for the addition of text tables:

<texttable>
  <ttcol width="10%">Title 1</ttcol>
  <ttcol width="40%">Title 2</ttcol>
  <ttcol>Title 3</ttcol>
  <c>column 1 text</c><c>column 2 text</c><c>column 3 text</c>
  <c>row 2 col 1  </c><c>row 2 col 2  </c><c>row 2 col 3  </c>
  <c>empty col:   </c><c>             </c><c>row 3 col 3  </c>
</texttable>

The outer entity is "texttable" (to distinguish from HTML <table>) and appears 
at the section content level as a parallel structure to figure.  A texttable 
contains one or more ttcol elements.  Column widths are only specified as 
percentages.  <ttcol> elements with omitted width attributes are all of equal 
width and consume the remaining width at the current indent level.  The sum of 
the width attributes on all the ttcol elements must not exceed 100%.  The text 
of a <ttcol> entity is the column title.  The number of <ttcol> elements 
determines the number of columns in the table.

The body of the table is made up of table cells each enclosed by <c> tags. 
Whitespace adjacent to <c> tags is stripped.  An empty cell has only whitespace 
within the <c> entity (e.g., "<c></c>" is equivalent to "<c>   </c>".  Text in 
a cell is left-aligned by default and word-wrapped as necessary to fit the 
column width.  The behavior when a word doesn't fit in a column is 
implementation dependent.  Column widths are not adjusted based on the text in 
the table cells.  The minimum width for a column in the text output is 1 
character.  An implementation may place other reasonable restrictions on tables 
(e.g., no more than 34 columns, row height may not exceed the usable height of 
one page in the text output).

The optional anchor and title attributes for texttable as well as the optional 
preamble and postamble elements have the same meaning as they do for figures, 
except that tables are enumerated separately from figures.

Here is a proposed DTD modification:

    <!ELEMENT section     (t|figure|texttable|iref|section)*>
    <!ELEMENT texttable   (preamble?,ttcol+,c*,postamble?>
    <!ATTLIST texttable
              anchor      ID                 #IMPLIED
              title       %ATEXT;            "">
    <!ELEMENT ttcol       (%TEXT;)>
    <!ATTLIST ttcol
              width       %ATEXT;           #IMPLIED>
    <!ELEMENT c           (%TEXT;|xref|eref|iref)*>

And a "nice to have" feature if Marshall feels like it:

    <!ATTLIST ttcol
              width       %ATEXT;           #IMPLIED
              align       (left|right)      "left">

Justifications/Motivations:

1. Tables are a commonly used feature in published RFCs.
2. This syntax allows specification of a basic table structure in XML without
   excessive complexity or manual positioning of table cells.
3. Tables in RFCs can contain text which is indexed or descriptions which
   reference other parts of the document. These features are not possible
   to achieve with artwork unless the references are manually numbered
   and indexes manually constructed.
4. Tables in RFCs often contain word-wrapped text in columns which is
   extremely cumbersome to produce with some text editors.
5. API specifications in RFCs do happen, and APIs often use tables of
   constants or error return values which need to be indexed.
6. Common typographic practice numbers tables separately from figures and
   references them from within the main text of the specification.
7. A structural representation rather than an artwork representation
   of tables permits a higher quality of output for HTML.

So at this point, the remaining questions: Do the justifications/motivations 
for this outweigh the complexity?  Is Marshall willing to add this feature to 
the TCL implementation?

                - Chris



From: GK@ninebynine.org (Graham Klyne)
Date: Thu, 24 Apr 2003 09:52:38 +0100
Subject: [xml2rfc] text tables proposal 2
In-Reply-To: <2147483647.1051119487@nifty-jr.west.sun.com>
References: <JIEGINCHMLABHJBIGKBCOEONHBAA.julian.reschke@gmx.de> <JIEGINCHMLABHJBIGKBCOEONHBAA.julian.reschke@gmx.de>
Message-ID: <5.1.0.14.2.20030424092748.02bd1d80@127.0.0.1>

At 17:38 23/04/2003 -0700, Chris Newman wrote:
>>left/right: sure.
>
>So far I've only heard assertions that left/right alignment is 
>useful.  Can anyone point to an example where the alignment is important 
>to the content of an RFC?  I can't think of a situation where it really 
>matters for anything but aesthetic reasons.  And given plain text is the 
>primary format for RFCs and has relatively poor aesthetics, I just don't 
>see it as a useful feature.  Please make an effort to convince me 
>otherwise if you want it.

Anything that aids legibility of a document, even in text, is helpful, so I 
wouldn't completely write off aesthetic concerns.  I'll also note that I 
have taken to using XML2RFC for preparing non-RFC documents, for which the 
HTML form is the only form I actually generate;  I appreciate it because 
(a) it focuses on content rather than irrelevant formatting, and (b) the 
associated bibliography is very useful.

I was planning to cite RFC2879 [1], which makes extensive use of tables for 
presenting features, but when I checked I realized that I never use right 
justification.  There is another in which I did use right justification 
(RFC2880 [2]), but in that case I think the tables concerned would in any 
case have been done as artwork rather than tables, if XML2RFC had been used.

So the best I can say is that when putting numbers into tables, I prefer to 
right-justify them so that the digit-positions are aligned.  For me, 
multiline values are always left justified.

At this point, I'd say that justification options aren't essential, even 
though I might still choose to include an option for allowing numbers to be 
right-justified in tables.

BTW, in another message, you asked for examples.  Here are a few:
- RFC 2045 [3], section 6.8
- RFC 2777 [4], sections 3.3, 5
- RFC 1321 [5], section 3.4
- RFC 1750 [6], section 5.2.1
IMO, none of these would be seriously affected if left-justified, but 
they're all examples of where authors chose to use right justification.

#g
--

[1] http://www.rfc-editor.org/rfc/rfc2879.txt

[2] http://www.rfc-editor.org/rfc/rfc2880.txt

[3] http://www.ietf.org/rfc/rfc2045.txt

[4] http://www.faqs.org/rfcs/rfc2777.html

[5] http://www.faqs.org/rfcs/rfc1321.html

[6] http://www.faqs.org/rfcs/rfc1750.html


-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E



From: aki.niemi@nokia.com (aki.niemi@nokia.com)
Date: Thu, 24 Apr 2003 11:13:57 +0300
Subject: [xml2rfc] Text Tables in xml2rfc
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945233@esebe013.ntc.nokia.com>

Hi,

I tend to agree with this. I won't have much use for texttable, and could very well live without xml2rfc necessarily having that feature at all.

Cheers,
Aki

 > -----Original Message-----
 > From: ext Scott W Brim [mailto:swb@employees.org]
 > Sent: 23 April, 2003 23:04
 > To: Julian Reschke
 > Cc: Chris Newman; xml2rfc@lists.xml.resource.org
 > Subject: Re: [xml2rfc] Text Tables in xml2rfc
 > 
 > 
 > On Tue, Apr 22, 2003 01:20:48PM -0700, Chris Newman allegedly wrote:
 > > begin  quotation by Scott W Brim on 2003/4/21 22:58 -0400:
 > > >On Mon, Apr 21, 2003 02:32:38PM -0700, Chris Newman 
 > allegedly wrote:
 > > >>begin quotation by Julian Reschke on 2003/4/19 10:00 +0200:
 > > >>> I'm talking about adjustment in table cells. For instance, if
 > > >>> table
 > > >>cells
 > > >>> contain numerical values, you will almost certainly 
 > want to have
 > > >>> them
 > > >>> right-justified.
 > > >>
 > > >>Does anyone else think this is a requirement?
 > > >
 > > >*if* you're going to do this at all, then yes -- and also
 > > >justification
 > > >around a decimal point or other character.
 > >
 > > Can you tell the list why this is important?
 > >
 > > Personally, I don't care if numbers in a table are left, 
 > right, center
 > > or decimal-point aligned as long as it is consistent throughout the
 > > entire column. Why is this feature important for authoring RFCs?
 > 
 > Personally I don't think any of this is warranted.  The 
 > great majority
 > of RFCs don't have tabular data.  In those that do, the table is
 > generated once and rarely edited.  (Sure, there may be exceptions.)
 > Anyway, in all those cases you can use any means you want to 
 > generate an
 > ascii table (including HTML), then cut and paste into 
 > artwork.  If you
 > have so much data that xml2rfc markup would be useful, then 
 > you're going
 > to want to automatically generate the xml2rfc version from 
 > authoritative
 > sources each time, not by hand, so the table markup language 
 > in xml2rfc
 > is just an intermediary form which a human will hardly have to mess
 > with, and a lot of these arguments are moot.  Marshall could use
 > valleytalk and not increase your level of effort -- you 
 > might even find
 > it entertaining.
 > 
 > Anyway, *IF* I were to use a table generator inside xml2rfc, I would
 > want it to be able to handle centering on arbitrary strings, 
 > including
 > ".".  Here are some examples:
 > 
 >   14.44    phase1 -> p2
 >    3.2          A -> gen
 >   14.2       INIT -> (note 3)
 > 
 > 
 > _______________________________________________
 > xml2rfc mailing list
 > xml2rfc@lists.xml.resource.org
 > http://lists.xml.resource.org/mailman/listinfo/xml2rfc
 > 


From: julian.reschke@gmx.de (Julian Reschke)
Date: Thu, 24 Apr 2003 09:56:18 +0200
Subject: [xml2rfc] Text Tables in xml2rfc
In-Reply-To: <2147483647.1051120789@nifty-jr.west.sun.com>
Message-ID: <JIEGINCHMLABHJBIGKBCIEABHCAA.julian.reschke@gmx.de>

> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of Chris Newman
> Sent: Thursday, April 24, 2003 3:00 AM
> To: Julian Reschke; xml2rfc@lists.xml.resource.org
> Subject: RE: [xml2rfc] Text Tables in xml2rfc
>
>
> begin quotation by Julian Reschke on 2003/4/23 21:39 +0200:
> > Well, I think we've had several people pointing out that the
restriction to
> > left-alignment alone is unacceptable.
>
> Nobody has made a technical argument for right alignment.  Only
assertions that
> it's needed.

Nobody has made technical arguments for tables in general, left alignment,
width settings or column headers either. However, (I think) all people that
did express an opinion said that they'd need both left and right adjustment.

> > So far I haven't been able to find out whether you
> >
> > - propose never to right-align (what about numerical values then???)
>
> I'd only left align.  I frequently see left-aligned columns of  numbers
and they
> don't bother me.  But if you can point to a couple published RFCs  where
right
> alignment of table text is important to the content of the RFC,  I'll
yield on
> this issue.

I just checked RFCs 3000 through 3009, of which only RFC3000 uses a table
(and in this case right alignment appears).

> >> > BTW: your proposal could be simplified to use even less tags  by
replacing
> >> > the cell boundary markers by -- for instance -- TAB characters.
> >>
> >> That would violate a basic principle of XML, and thus is not   relevant
to
> >> the discussion.
> >
> > Could you please be so kind to tell me *which* principle would  be
violated?
>
> The principle that tags are the way to represent content  structure in an
XML
> document.

So where is that stated?

And if this is such a basic principle, why do we have the artwork element in
which line breaks are significant? If line breaks can be significant, why
not TABs? And if tags are the only way to represent structure why then is
there a NMTOKENS content model for attributes (whitespace separated list of
tokens), which is quite popular in languages such as XML Schema or XSLT?

It's not that I *like* that approach for tables, I just wanted to show that
there are many approaches, and if the *only* metric would be ease of typing
and number of tags, this would be superior.

> ..

Julian

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



From: julian.reschke@gmx.de (Julian Reschke)
Date: Thu, 24 Apr 2003 09:42:31 +0200
Subject: [xml2rfc] text tables proposal 2
In-Reply-To: <5.1.0.14.2.20030423220014.02c04eb0@127.0.0.1>
Message-ID: <JIEGINCHMLABHJBIGKBCKEAAHCAA.julian.reschke@gmx.de>

> From: Graham Klyne [mailto:GK@ninebynine.org]
> Sent: Wednesday, April 23, 2003 11:03 PM
> To: Julian Reschke; Chris Newman; xml2rfc@lists.xml.resource.org
> Subject: RE: [xml2rfc] text tables proposal 2
>
>
> At 21:54 23/04/2003 +0200, Julian Reschke wrote:
> >I think an alternative would be to restrict the feature set not to allow
> >wrapping at all. Are there really many tables where wrapping
> table cells is
> >really needed?
>
> I think so.
>
> I would be quite happy if wrapping is restricted to spaces, and absent a
> suitable space than either (a) wrap at the position where overflow would
> occur, or (b) overflow to next column.  As an author, I'm happy to take
> responsibility for fixing the uglies here, but have found that
> wrapping can
> be useful (in a past life, when using Word to prepare RFCs).

Another alternative would be to allow the author to specify soft hyphens
(such as &#xAD;). This may be the simplest approach (implementation-wise)
that still can produce nicely wrapped columns.

Julian

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



From: Chris.Newman@Sun.COM (Chris Newman)
Date: Wed, 23 Apr 2003 17:59:49 -0700
Subject: [xml2rfc] Text Tables in xml2rfc
In-Reply-To: <JIEGINCHMLABHJBIGKBCMEOMHBAA.julian.reschke@gmx.de>
References: <JIEGINCHMLABHJBIGKBCMEOMHBAA.julian.reschke@gmx.de>
Message-ID: <2147483647.1051120789@nifty-jr.west.sun.com>

begin quotation by Julian Reschke on 2003/4/23 21:39 +0200:
> Well, I think we've had several people pointing out that the restriction to
> left-alignment alone is unacceptable.

Nobody has made a technical argument for right alignment.  Only assertions that 
it's needed.

> So far I haven't been able to find out whether you
>
> - propose never to right-align (what about numerical values then???)

I'd only left align.  I frequently see left-aligned columns of numbers and they 
don't bother me.  But if you can point to a couple published RFCs where right 
alignment of table text is important to the content of the RFC, I'll yield on 
this issue.

>> > BTW: your proposal could be simplified to use even less tags by replacing
>> > the cell boundary markers by -- for instance -- TAB characters.
>>
>> That would violate a basic principle of XML, and thus is not  relevant to
>> the discussion.
>
> Could you please be so kind to tell me *which* principle would be violated?

The principle that tags are the way to represent content structure in an XML 
document.

> Yes. I just disagree that this is the case here.

Yes, we disagree on the row container issue.  I don't think further discussion 
will help.

                - Chris



From: Chris.Newman@Sun.COM (Chris Newman)
Date: Wed, 23 Apr 2003 17:38:07 -0700
Subject: [xml2rfc] text tables proposal 2
In-Reply-To: <JIEGINCHMLABHJBIGKBCOEONHBAA.julian.reschke@gmx.de>
References: <JIEGINCHMLABHJBIGKBCOEONHBAA.julian.reschke@gmx.de>
Message-ID: <2147483647.1051119487@nifty-jr.west.sun.com>

begin  quotation by Julian Reschke on 2003/4/23 21:54 +0200:
> What is this ("An empty cell  has only whitespace within the <c> entity")
> supposed to mean?

That means that "<c></c>" and "<c>     </c>" are equivalent.

> I'm not sure that this suffices as definition. Text in <t> sections should
> never be hyphenated (see RFC2223bis-04), while it may be unavoidable in
> narrow columns. Leaving it to the xml2rfc processor means that it needs to
> implement hyphenation algorithms (do we really want that???).

We're getting too far into implementation details which Marshall should decide. 
Personally, I'd do very simple word wrapping.  If the word was too long, I'd 
break it just after the last character that fit in the cell.  Hyphenation would 
certainly be too much complexity and not worth the effort.

> In particular, I'm concerned about the presence of <vspace> here,
> because that's a very problematic RFC2629 feature already (it specifies
> formatting, not content).

OK, I'll drop vspace from the next (likely final) proposal.

> left/right: sure.

So far I've only heard assertions that left/right alignment is useful.  Can 
anyone point to an example where the alignment is important to the content of 
an RFC?  I can't think of a situation where it really matters for anything but 
aesthetic reasons.  And given plain text is the primary format for RFCs and has 
relatively poor aesthetics, I just don't see it as a useful feature.  Please 
make an effort to convince me otherwise if you want it.

> My primary concern is that this forces an xml2rfc processor to implement a
> multi-column render (at least when producing ASCII as output). This can
> become very tricky, especially when columns get narrow. Let's hear what MTR
> thinks.

One of my constraints for the proposal is that I'd be willing to implement it 
myself if I wrote a C language version of xml2rfc.  I've never suggested that 
the wrapping be optimal or even desirable when columns get narrow -- only that 
the output contains the text that was in the input file within reason.  And I 
expect MTR to pick some reasonable implementation limits.  For example, I would 
limit the implementation to 34 columns max, have a minimum width of 1 character 
per column in text output, and limit row height to a size which fits on one 
page.

> I think an alternative would be to restrict the feature set not to allow
> wrapping at all. Are there really many tables where wrapping table cells is
> really needed?

Both RFC 2822 (sec 6) and RFC 2706 use wrapped table text with xrefs.

This is used in many published RFCs and is important to enable correct 
rendering of RFC content.

                - Chris



From: GK@ninebynine.org (Graham Klyne)
Date: Wed, 23 Apr 2003 22:03:26 +0100
Subject: [xml2rfc] text tables proposal 2
In-Reply-To: <JIEGINCHMLABHJBIGKBCOEONHBAA.julian.reschke@gmx.de>
References: <2147483647.1051020060@nifty-jr.west.sun.com>
Message-ID: <5.1.0.14.2.20030423220014.02c04eb0@127.0.0.1>

At 21:54 23/04/2003 +0200, Julian Reschke wrote:
>I think an alternative would be to restrict the feature set not to allow
>wrapping at all. Are there really many tables where wrapping table cells is
>really needed?

I think so.

I would be quite happy if wrapping is restricted to spaces, and absent a 
suitable space than either (a) wrap at the position where overflow would 
occur, or (b) overflow to next column.  As an author, I'm happy to take 
responsibility for fixing the uglies here, but have found that wrapping can 
be useful (in a past life, when using Word to prepare RFCs).

#g


-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E



From: swb@employees.org (Scott W Brim)
Date: Wed, 23 Apr 2003 16:03:42 -0400
Subject: [xml2rfc] Text Tables in xml2rfc
Message-ID: <20030423200342.GA2128@sbrim-w2k>

On Tue, Apr 22, 2003 01:20:48PM -0700, Chris Newman allegedly wrote:
> begin  quotation by Scott W Brim on 2003/4/21 22:58 -0400:
> >On Mon, Apr 21, 2003 02:32:38PM -0700, Chris Newman allegedly wrote:
> >>begin quotation by Julian Reschke on 2003/4/19 10:00 +0200:
> >>> I'm talking about adjustment in table cells. For instance, if
> >>> table
> >>cells
> >>> contain numerical values, you will almost certainly want to have
> >>> them
> >>> right-justified.
> >>
> >>Does anyone else think this is a requirement?
> >
> >*if* you're going to do this at all, then yes -- and also
> >justification
> >around a decimal point or other character.
>
> Can you tell the list why this is important?
>
> Personally, I don't care if numbers in a table are left, right, center
> or decimal-point aligned as long as it is consistent throughout the
> entire column. Why is this feature important for authoring RFCs?

Personally I don't think any of this is warranted.  The great majority
of RFCs don't have tabular data.  In those that do, the table is
generated once and rarely edited.  (Sure, there may be exceptions.)
Anyway, in all those cases you can use any means you want to generate an
ascii table (including HTML), then cut and paste into artwork.  If you
have so much data that xml2rfc markup would be useful, then you're going
to want to automatically generate the xml2rfc version from authoritative
sources each time, not by hand, so the table markup language in xml2rfc
is just an intermediary form which a human will hardly have to mess
with, and a lot of these arguments are moot.  Marshall could use
valleytalk and not increase your level of effort -- you might even find
it entertaining.

Anyway, *IF* I were to use a table generator inside xml2rfc, I would
want it to be able to handle centering on arbitrary strings, including
".".  Here are some examples:

  14.44    phase1 -> p2
   3.2          A -> gen
  14.2       INIT -> (note 3)




From: julian.reschke@gmx.de (Julian Reschke)
Date: Wed, 23 Apr 2003 21:54:54 +0200
Subject: [xml2rfc] text tables proposal 2
In-Reply-To: <2147483647.1051020060@nifty-jr.west.sun.com>
Message-ID: <JIEGINCHMLABHJBIGKBCOEONHBAA.julian.reschke@gmx.de>

> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of Chris Newman
> Sent: Tuesday, April 22, 2003 11:01 PM
> To: xml2rfc@lists.xml.resource.org
> Subject: [xml2rfc] text tables proposal 2
>
>
> Based on list discussion, here is a second proposal:
>
> <texttable>
>   <ttcol width="10%">Title 1</ttcol>
>   <ttcol width="40%">Title 2</ttcol>
>   <ttcol>Title 3</ttcol>
>   <c>column 1 text</c><c>column 2 text</c><c>column 3 text</c>
>   <c>row 2 col 1  </c><c>row 2 col 2  </c><c>row 2 col 3  </c>
>   <c>empty col:   </c><c>             </c><c>row 3 col 3  </c>
> </texttable>
>
> The outer entity is "texttable" (to distinguish from HTML  <table>) and
may
> appear at the section content level or in place of the "<artwork>" in a
> "<figure>".  This must be followed by one or more ttcol elements.  Widths
are
> only specified as percentages.  <ttcol> with omitted width tag  are all of
equal
> width and consume the remaining width at the current indent  level.  The
text of
> a <ttcol> entity is the column title.  An empty <ttcol> entity  means
there is
> no title for that column.  The number of <ttcol> elements  determines the
number
> of columns in the table.  The body of the table is made up of  table cells
each
> enclosed by <c> tags.  Whitespace adjacent to tags is stripped.   An empty
cell
> has only whitespace within the <c> entity.  Text in a cell is wrapped as

What is this ("An empty cell  has only whitespace within the <c> entity")
supposed to mean?

> necessary to fit the column width.  Wrapping within a table cell  follows
same
> wrapping rules as for <t> text (wrapping between words preferred,  words
will be
> split if necessary).  Column widths are not adjusted based on the  text in
the

I'm not sure that this suffices as definition. Text in <t> sections should
never be hyphenated (see RFC2223bis-04), while it may be unavoidable in
narrow columns. Leaving it to the xml2rfc processor means that it needs to
implement hyphenation algorithms (do we really want that???).

> table cells.
>
> I'm not great at DTD's, but here's my best shot at describing this:
>
>     <!ELEMENT figure      (preamble?,(artwork|texttable),postamble?)>
>     <!ELEMENT section     (t|figure|iref|section|texttable)*>
>     <!ELEMENT texttable   (ttcol+,c*>
>     <!ELEMENT ttcol       (%TEXT;)>
>     <!ATTLIST ttcol
>               width       %ATEXT;           #IMPLIED>
>     <!ELEMENT c           (%TEXT;|xref|eref|iref|vspace)*>

I appreciate the change to use container elements, but I fear that you're
now putting in too many features  -- let's try to avoid this in the first
round. In particular, I'm concerned about the presence of <vspace> here,
because that's a very problematic RFC2629 feature already (it specifies
formatting, not content).

> (note: I was going to use <t> instead of <c> until I noticed that  <t>
permits
>  embedded lists and figures which would add too much structural
complexity)
>
> Changes from first proposal:
> * allow use of texttable in figure
> * switch from cell delimiters to cell containers for consistency  &
extensibility
> * clarify wrapping rules somewhat
> * clarify that the number of ttcol elements determines the number  of
columns
> * allow references from within the table to other parts of the RFC (a
>   significant value-add relative to artwork).

Yes. I'd also like to be able to have anchors everywhere, but I think this
is a separate dicussion (let's not try to do too many things at once).

> Open issues:
> * Is there a substantive need for column  left/right/center/decimal
alignment
>   capability for text RFC authoring?

left/right: sure.

> * How well does this balance the value it provides RFC authors with the
>   complexity it adds to xml2rfc?

My primary concern is that this forces an xml2rfc processor to implement a
multi-column render (at least when producing ASCII as output). This can
become very tricky, especially when columns get narrow. Let's hear what MTR
thinks.

I think an alternative would be to restrict the feature set not to allow
wrapping at all. Are there really many tables where wrapping table cells is
really needed?

> Comments?

It takes care of my biggest concern (the DTD for the table body), so this is
better. I'd still prefer containment for the table header and for the rows,
though.

Julian

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



From: julian.reschke@gmx.de (Julian Reschke)
Date: Wed, 23 Apr 2003 21:39:38 +0200
Subject: [xml2rfc] Text Tables in xml2rfc
In-Reply-To: <2147483647.1051017538@nifty-jr.west.sun.com>
Message-ID: <JIEGINCHMLABHJBIGKBCMEOMHBAA.julian.reschke@gmx.de>

> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of Chris Newman
> Sent: Tuesday, April 22, 2003 10:19 PM
> To: Julian Reschke; xml2rfc@lists.xml.resource.org
> Subject: RE: [xml2rfc] Text Tables in xml2rfc
>
>
> begin quotation by Julian Reschke on 2003/4/22 10:15 +0200:
> > Again, this is only true if you measure complexity by counting tags. I
> > already said that I believe this is wrong -- there are other  aspects
which
> > are equally important (see below).
>
> I measure complexity in this instance by at least the following  metrics,
in
> order of importance:
>  1. how hard it is to type in an arbitrary text editor (the user
> comes first)
>  2. how many lines of specification text it takes to describe the format
>  3. how complex the DTD is
>  4. how many silly states are permitted by the mechanism
>  5. the complexity of the complete code to implement the mechanism
>
> As far as I can tell, my proposal beats your alternative on all 5
metrics.  I'm
> curious what metrics you use for simplicity that produce such  different
results.

I agree that all these metrics are relevant, but -- surprise -- I disagree
that your proposal beats the "conventional one" in this regard.

Re 2) to compare this, we should actually write town the specification. We
haven't done that yet, so maybe we really need to do that.

Re 3) (I'm using different names to avoid confusion for now)

<!ELEMENT tab (head, body)>
<!ELEMENT head (column+)>
<!ELEMENT column #PCDATA>
<!ATTLIST column CDATA "left">
<!ELEMENT body (row+)>
<!ELEMENT row (cell+)>
<!ELEMENT cell #PCDATA>

This DTD admittingly has more elements, but IMHO a clearer content model.

Re 4) I think both can have mismatches between declared columns and the
actual number of cells that are present. With this DTD it will be easier to
detect which row is in error.

5) I think both are simple to implement (where I refer to your revised
proposal).

> > So if you feel this isn't needed? How are you going to align numerical
> > values then? By manually aligning with spaces? I thought that's  one of
the
> > things we want to get rid off.
>
> I couldn't care less whether numbers are left, right or center aligned in
> tables for any documents I produce.  As long as they are in  columns I
just
> don't care.  Since we're formatting RFCs with plain text as the  primary
output
> format, that sort of fine-grained control doesn't seem to be worth the
> complexity it adds to the format.

Well, I think we've had several people pointing out that the restriction to
left-alignment alone is unacceptable. So far I haven't been able to find out
whether you

- propose never to right-align (what about numerical values then???) or
- propose to insert aligning spaces into the document (in which case the
behaviour regarding whitespace would be radically different than in the
other parts of the DTD).

?

> Does anyone have a compelling technical reason for why it is important to
> provide this sort of control?

Yes, *if* a new feature releaves me from the task of aligning "manually" (by
adding spaces), I'd like to be able to use it for all kinds of tables I
need -- and numerical value columns are a fact of reality.

> > BTW: your proposal could be simplified to use even less tags by
replacing
> > the cell boundary markers by -- for instance -- TAB characters.
>
> That would violate a basic principle of XML, and thus is not  relevant to
the
> discussion.

Could you please be so kind to tell me *which* principle would be violated?

> > Extensibility: if we don't have proper container elemenrts, it  may be
harder
> > to extend the table engine at a later point of time.
>
> To restate: using delimiter tags means there is no place to  attach
attributes
> which apply to the data in a table cell.  It is bad design to  preclude a
form
> of extensibility which has potential legitimate use in the  future, even
if that
> form of extensibility is not deemed necessary in the present.  I  find
this
> argument in combination with the consistency argument to make a
compelling
> cause to use container rather than delimiter tags for cell content.

Great.

> > Robustness: in the absence of row tags, it will be extremely  easy to
mess up
> > a table by losing a single cell marker (or by accidentally  adding a
spurious
> > one)
>
> I regularly mess up HTML tables by forgetting the row containers  or
putting too

By "messing up" I meant the case where a table that *was* correct is broken
by manual edits (which is diffferent from not being able to produce a
correct table in the first place :-).

> many cells inside a row.  To me, the format is more robust  without the
row
> containers.

Nope. In your proosal, adding an extra cell moves all following cells by one
position to the right, which may be correct by the DTD, but certainly is
never what you indend.

> > Validation: a stronger content model will allow validators to catch more
> > input errors, and XML-aware editors may offer better editing  tools
(such as
> > moving around complete rows).
>
> I generally consider it better to use a simpler format which  disallows
errors
> by design rather than one which permits errors which a validator
> can detect.

Yes. I just disagree that this is the case here.

Julian

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



From: julian.reschke@gmx.de (Julian Reschke)
Date: Wed, 23 Apr 2003 21:19:04 +0200
Subject: [xml2rfc] text tables proposal 2
In-Reply-To: <2147483647.1051027663@nifty-jr.west.sun.com>
Message-ID: <JIEGINCHMLABHJBIGKBCKEOLHBAA.julian.reschke@gmx.de>

> -----Original Message-----
> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of Chris Newman
> Sent: Wednesday, April 23, 2003 1:08 AM
> To: Marshall Rose; xml2rfc@lists.xml.resource.org
> Subject: Re: [xml2rfc] text tables proposal 2
> 
> 
> begin quotation by Marshall Rose on 2003/4/22 15:02 -0700:
> > one minor comment: i guess i would prefer to see this as one of:
> >
> >     - an alternative to artwork (i.e., always inside a figure); or
> >     - parallel to figure (i.e., never inside a figure)
> >
> > having both just confuses me.
> 
> The valid motivation behind this change (noted by Julian) was to 
> allow tables 
> to be referenced the same way figures are referenced.  But your 
> complaint is 
> correct.  Now that you've made me think about it, the right 
> answer is that 
> tables and figures are parallel objects, because that's how 
> they're treated by 
> common typographical practice which enumerates figures and tables 
> independently 
> as parallel objects.  So that means texttable would need the same 
> structure as 
> a figure (since it's referenced in the same way), but would be 
> independent of 
> figure since tables are enumerated separately from figures.  The 
> result would 
> be:
> 
>     <!ELEMENT section     (t|figure|texttable|iref|section)*>
>     <!ELEMENT texttable   (preamble?,ttcol+,c*,postamble?>
>     <!ATTLIST texttable
>               anchor      ID                 #IMPLIED
>               title       %ATEXT;            "">
>     <!ELEMENT ttcol       (%TEXT;)>
>     <!ATTLIST ttcol
>               width       %ATEXT;           #IMPLIED>
>     <!ELEMENT c           (%TEXT;|xref|eref|iref|vspace)*>
> 
> How does that work?

Sounds OK (this particular change...).

Julian

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



From: julian.reschke@gmx.de (Julian Reschke)
Date: Wed, 23 Apr 2003 21:16:39 +0200
Subject: [xml2rfc] xml2rfc v1.18 imminent...
In-Reply-To: <20030423093649.29eac920.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <JIEGINCHMLABHJBIGKBCGEOLHBAA.julian.reschke@gmx.de>

> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of Marshall Rose
> Sent: Wednesday, April 23, 2003 6:37 PM
> Cc: xml2rfc@lists.xml.resource.org
> Subject: Re: [xml2rfc] xml2rfc v1.18 imminent...
>
>
> now that the startAt/counter controversy has been resolved, the only
> matters remaining fall into two categories:
>
>     - things that are extensions, e.g., <texttable/>
>
>     - what to do about unnumbered sections that have subsections
>
> v1.18 doesn't need to be held up because of the first category.

Yes, please let's move that into the next release.

> in terms of the second category, i have yet to hear from the rfc-editor
> regarding the matter. if we need to make a change to the content model
> to resolve this issue, then i'd prefer not to release v1.18.  to re-cap:
>
> old model:
>
>     <!ELEMENT middle      (section+)>
>     <!-- sections, if present, are appendices -->
>     <!ELEMENT back        (references*,section*)>
>
> new model:
>
>     <!ELEMENT middle      (section+,appendix*,section*)>
>     <!-- sections still allowed, for backwards-compatibility -->
>     <!ELEMENT back        (references*,section*)>
>
> the question is how long to wait for clarification. without a response
> from the rfc-editor, it seems that there are three alternatives:

Is there any pressure to do a release?

>     1. do not allow subsections in un-numbered sections.
>
>     2. if subsections appear in un-numbered sections, then force the
>        sections to be numbered, e.g., "X. Security Considerations".
>
>     3.do not allow un-numbered sections, even though it makes the TOC
>       look "funny" when they appear after any appendices.
>
> comments?

Given the fact that none of these options looks really attractive, I'd
propose that we try even harder to get constructive feedback from the RFC
editor (I already send an email, maybe more should follow :-).

Julian

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



From: henrik@levkowetz.com (Henrik Levkowetz)
Date: Wed, 23 Apr 2003 19:22:09 +0200
Subject: [xml2rfc] xml2rfc v1.18 imminent...
In-Reply-To: <20030423093649.29eac920.mrose+internet.xml2rfc@dbc.mtview.ca.us>
References: <20030416150021.3f00af70.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20030423093649.29eac920.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <20030423192209.22d4400e.henrik@levkowetz.com>

On Wed, 23 Apr 2003 09:36:49 -0700, Marshall Rose <mrose+internet.xml2rfc@dbc.mtview.ca.us> wrote:

>     1. do not allow subsections in un-numbered sections.
>
>     2. if subsections appear in un-numbered sections, then force the
>        sections to be numbered, e.g., "X. Security Considerations".
>     
>     3.do not allow un-numbered sections, even though it makes the TOC
>       look "funny" when they appear after any appendices.

My preferences:

	2. - This seems the most generic solution
	1. - I could live with this without feeling any hardship
	3. - I'd really not feel Ok with this alterernative

	Henrik

-- 
  A generation which ignores history has no past -- and no future.


From: swb@employees.org (Scott W Brim)
Date: Wed, 23 Apr 2003 12:43:14 -0400
Subject: [xml2rfc] xml2rfc v1.18 imminent...
In-Reply-To: <20030423093649.29eac920.mrose+internet.xml2rfc@dbc.mtview.ca.us>
References: <20030416150021.3f00af70.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20030423093649.29eac920.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <20030423164314.GJ2188@sbrim-w2k>

On Wed, Apr 23, 2003 09:36:49AM -0700, Marshall Rose allegedly wrote:
> the question is how long to wait for clarification. without a response
> from the rfc-editor, it seems that there are three alternatives:
>     
>     1. do not allow subsections in un-numbered sections.

Yes.

>     2. if subsections appear in un-numbered sections, then force the
>        sections to be numbered, e.g., "X. Security Considerations".

Hmm, silently?  Reluctantly acceptable.  It looks complicated.

>     3.do not allow un-numbered sections, even though it makes the TOC
>       look "funny" when they appear after any appendices.

No.


From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Wed, 23 Apr 2003 09:36:49 -0700
Subject: [xml2rfc] xml2rfc v1.18 imminent...
In-Reply-To: <20030416150021.3f00af70.mrose+internet.xml2rfc@dbc.mtview.ca.us>
References: <20030416150021.3f00af70.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <20030423093649.29eac920.mrose+internet.xml2rfc@dbc.mtview.ca.us>

now that the startAt/counter controversy has been resolved, the only
matters remaining fall into two categories:
    
    - things that are extensions, e.g., <texttable/>
    
    - what to do about unnumbered sections that have subsections
    
v1.18 doesn't need to be held up because of the first category.
    
in terms of the second category, i have yet to hear from the rfc-editor
regarding the matter. if we need to make a change to the content model
to resolve this issue, then i'd prefer not to release v1.18.  to re-cap:
    
old model:
    
    <!ELEMENT middle      (section+)>
    <!-- sections, if present, are appendices -->
    <!ELEMENT back        (references*,section*)>
    
new model:
    
    <!ELEMENT middle      (section+,appendix*,section*)>
    <!-- sections still allowed, for backwards-compatibility -->
    <!ELEMENT back        (references*,section*)>
    
the question is how long to wait for clarification. without a response
from the rfc-editor, it seems that there are three alternatives:
    
    1. do not allow subsections in un-numbered sections.
    
    2. if subsections appear in un-numbered sections, then force the
       sections to be numbered, e.g., "X. Security Considerations".
    
    3.do not allow un-numbered sections, even though it makes the TOC
      look "funny" when they appear after any appendices.

comments?

/mtr


From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Wed, 23 Apr 2003 08:01:41 -0700
Subject: [xml2rfc] text tables proposal 2
In-Reply-To: <2147483647.1051027663@nifty-jr.west.sun.com>
References: <2147483647.1051020060@nifty-jr.west.sun.com> <2147483647.1051027663@nifty-jr.west.sun.com>
Message-ID: <20030423080141.27695974.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> So that means texttable would need the
> same structure as a figure (since it's referenced in the same way), but would
> be independent of figure since tables are enumerated separately from figures.
> ...
> How does that work?

yep.

/mtr


From: Chris.Newman@Sun.COM (Chris Newman)
Date: Tue, 22 Apr 2003 16:07:43 -0700
Subject: [xml2rfc] text tables proposal 2
In-Reply-To: <2147483647.1051020060@nifty-jr.west.sun.com> <20030422150225.0a03a3af.mrose+mtr.netnews@dbc.mtview.ca.us>
References: <2147483647.1051020060@nifty-jr.west.sun.com>
Message-ID: <2147483647.1051027663@nifty-jr.west.sun.com>

begin quotation by Marshall Rose on 2003/4/22 15:02 -0700:
> one minor comment: i guess i would prefer to see this as one of:
>
>     - an alternative to artwork (i.e., always inside a figure); or
>     - parallel to figure (i.e., never inside a figure)
>
> having both just confuses me.

The valid motivation behind this change (noted by Julian) was to allow tables 
to be referenced the same way figures are referenced.  But your complaint is 
correct.  Now that you've made me think about it, the right answer is that 
tables and figures are parallel objects, because that's how they're treated by 
common typographical practice which enumerates figures and tables independently 
as parallel objects.  So that means texttable would need the same structure as 
a figure (since it's referenced in the same way), but would be independent of 
figure since tables are enumerated separately from figures.  The result would 
be:

    <!ELEMENT section     (t|figure|texttable|iref|section)*>
    <!ELEMENT texttable   (preamble?,ttcol+,c*,postamble?>
    <!ATTLIST texttable
              anchor      ID                 #IMPLIED
              title       %ATEXT;            "">
    <!ELEMENT ttcol       (%TEXT;)>
    <!ATTLIST ttcol
              width       %ATEXT;           #IMPLIED>
    <!ELEMENT c           (%TEXT;|xref|eref|iref|vspace)*>

How does that work?

                - Chris



From: mrose+mtr.netnews@dbc.mtview.ca.us (Marshall Rose)
Date: Tue, 22 Apr 2003 15:02:25 -0700
Subject: [xml2rfc] text tables proposal 2
In-Reply-To: <2147483647.1051020060@nifty-jr.west.sun.com>
References: <2147483647.1051020060@nifty-jr.west.sun.com>
Message-ID: <20030422150225.0a03a3af.mrose+mtr.netnews@dbc.mtview.ca.us>

> Based on list discussion, here is a second proposal:
> 
> <texttable>
>   <ttcol width="10%">Title 1</ttcol>
>   <ttcol width="40%">Title 2</ttcol>
>   <ttcol>Title 3</ttcol>
>   <c>column 1 text</c><c>column 2 text</c><c>column 3 text</c>
>   <c>row 2 col 1  </c><c>row 2 col 2  </c><c>row 2 col 3  </c>
>   <c>empty col:   </c><c>             </c><c>row 3 col 3  </c>
> </texttable>
    
one minor comment: i guess i would prefer to see this as one of:
    
    - an alternative to artwork (i.e., always inside a figure); or
    - parallel to figure (i.e., never inside a figure)
    
having both just confuses me.

/mtr


From: GK@ninebynine.org (Graham Klyne)
Date: Tue, 22 Apr 2003 22:50:39 +0100
Subject: [xml2rfc] text tables proposal 2
In-Reply-To: <2147483647.1051020060@nifty-jr.west.sun.com>
Message-ID: <5.1.0.14.2.20030422224529.01e9afb8@127.0.0.1>

At 14:01 22/04/2003 -0700, Chris Newman wrote

This is looking like a good trade-off of function/complexity to me...

[...]
>I'm not great at DTD's, but here's my best shot at describing this:
>
>    <!ELEMENT figure      (preamble?,(artwork|texttable),postamble?)>
>    <!ELEMENT section     (t|figure|iref|section|texttable)*>
>    <!ELEMENT texttable   (ttcol+,c*>
>    <!ELEMENT ttcol       (%TEXT;)>
>    <!ATTLIST ttcol
>              width       %ATEXT;           #IMPLIED>
>    <!ELEMENT c           (%TEXT;|xref|eref|iref|vspace)*>
>
>(note: I was going to use <t> instead of <c> until I noticed that <t> permits
>embedded lists and figures which would add too much structural complexity)

Yeah!

I like the idea of doing tables in figures.  A nit:  is it redundant to 
allow <texttable> as a direct child of <section>, since it looks as if a 
similar effect is available by putting it in a <figure> with no preamble or 
postamble?

[...]

>Open issues:
>* Is there a substantive need for column left/right/center/decimal alignment
>  capability for text RFC authoring?

I personally think that left/right could be useful.  Any more may be overkill.

#g


-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E



From: chris@greenhillroad.org (Chris Newman)
Date: Tue, 22 Apr 2003 14:01:00 -0700
Subject: [xml2rfc] text tables proposal 2
Message-ID: <2147483647.1051020060@nifty-jr.west.sun.com>

Based on list discussion, here is a second proposal:

<texttable>
  <ttcol width="10%">Title 1</ttcol>
  <ttcol width="40%">Title 2</ttcol>
  <ttcol>Title 3</ttcol>
  <c>column 1 text</c><c>column 2 text</c><c>column 3 text</c>
  <c>row 2 col 1  </c><c>row 2 col 2  </c><c>row 2 col 3  </c>
  <c>empty col:   </c><c>             </c><c>row 3 col 3  </c>
</texttable>

The outer entity is "texttable" (to distinguish from HTML <table>) and may 
appear at the section content level or in place of the "<artwork>" in a 
"<figure>".  This must be followed by one or more ttcol elements.  Widths are 
only specified as percentages.  <ttcol> with omitted width tag are all of equal 
width and consume the remaining width at the current indent level.  The text of 
a <ttcol> entity is the column title.  An empty <ttcol> entity means there is 
no title for that column.  The number of <ttcol> elements determines the number 
of columns in the table.  The body of the table is made up of table cells each 
enclosed by <c> tags.  Whitespace adjacent to tags is stripped.  An empty cell 
has only whitespace within the <c> entity.  Text in a cell is wrapped as
necessary to fit the column width.  Wrapping within a table cell follows same 
wrapping rules as for <t> text (wrapping between words preferred, words will be 
split if necessary).  Column widths are not adjusted based on the text in the 
table cells.

I'm not great at DTD's, but here's my best shot at describing this:

    <!ELEMENT figure      (preamble?,(artwork|texttable),postamble?)>
    <!ELEMENT section     (t|figure|iref|section|texttable)*>
    <!ELEMENT texttable   (ttcol+,c*>
    <!ELEMENT ttcol       (%TEXT;)>
    <!ATTLIST ttcol
              width       %ATEXT;           #IMPLIED>
    <!ELEMENT c           (%TEXT;|xref|eref|iref|vspace)*>

(note: I was going to use <t> instead of <c> until I noticed that <t> permits
 embedded lists and figures which would add too much structural complexity)

Changes from first proposal:
* allow use of texttable in figure
* switch from cell delimiters to cell containers for consistency & extensibility
* clarify wrapping rules somewhat
* clarify that the number of ttcol elements determines the number of columns
* allow references from within the table to other parts of the RFC (a
  significant value-add relative to artwork).

Open issues:
* Is there a substantive need for column left/right/center/decimal alignment
  capability for text RFC authoring?
* How well does this balance the value it provides RFC authors with the
  complexity it adds to xml2rfc?

Comments?

                - Chris



From: Chris.Newman@Sun.COM (Chris Newman)
Date: Tue, 22 Apr 2003 13:18:58 -0700
Subject: [xml2rfc] Text Tables in xml2rfc
In-Reply-To: <JIEGINCHMLABHJBIGKBCGEKFHBAA.julian.reschke@gmx.de>
References: <JIEGINCHMLABHJBIGKBCGEKFHBAA.julian.reschke@gmx.de>
Message-ID: <2147483647.1051017538@nifty-jr.west.sun.com>

begin quotation by Julian Reschke on 2003/4/22 10:15 +0200:
> Again, this is only true if you measure complexity by counting tags. I
> already said that I believe this is wrong -- there are other aspects which
> are equally important (see below).

I measure complexity in this instance by at least the following metrics, in 
order of importance:
 1. how hard it is to type in an arbitrary text editor (the user comes first)
 2. how many lines of specification text it takes to describe the format
 3. how complex the DTD is
 4. how many silly states are permitted by the mechanism
 5. the complexity of the complete code to implement the mechanism

As far as I can tell, my proposal beats your alternative on all 5 metrics.  I'm 
curious what metrics you use for simplicity that produce such different results.

> So if you feel this isn't needed? How are you going to align numerical
> values then? By manually aligning with spaces? I thought that's one of the
> things we want to get rid off.

I couldn't care less whether numbers are left, right or center aligned in 
tables for any documents I produce.  As long as they are in columns I just 
don't care.  Since we're formatting RFCs with plain text as the primary output 
format, that sort of fine-grained control doesn't seem to be worth the 
complexity it adds to the format.

Does anyone have a compelling technical reason for why it is important to 
provide this sort of control?

> BTW: your proposal could be simplified to use even less tags by replacing
> the cell boundary markers by -- for instance -- TAB characters.

That would violate a basic principle of XML, and thus is not relevant to the 
discussion.

> Extensibility: if we don't have proper container elemenrts, it may be harder
> to extend the table engine at a later point of time.

To restate: using delimiter tags means there is no place to attach attributes 
which apply to the data in a table cell.  It is bad design to preclude a form 
of extensibility which has potential legitimate use in the future, even if that 
form of extensibility is not deemed necessary in the present.  I find this 
argument in combination with the consistency argument to make a compelling 
cause to use container rather than delimiter tags for cell content.

> Robustness: in the absence of row tags, it will be extremely easy to mess up
> a table by losing a single cell marker (or by accidentally adding a spurious
> one)

I regularly mess up HTML tables by forgetting the row containers or putting too 
many cells inside a row.  To me, the format is more robust without the row 
containers.

> Validation: a stronger content model will allow validators to catch more
> input errors, and XML-aware editors may offer better editing tools (such as
> moving around complete rows).

I generally consider it better to use a simpler format which disallows errors 
by design rather than one which permits errors which a validator can detect.

                - Chris



From: gk@ninebynine.org (Graham Klyne)
Date: Tue, 22 Apr 2003 17:23:37 +0100
Subject: [xml2rfc] Text Tables in xml2rfc
In-Reply-To: <2147483647.1050680207@nifty-jr.west.sun.com>
References: <JIEGINCHMLABHJBIGKBCOEALHBAA.julian.reschke@gmx.de> <5.1.0.14.2.20030417083559.02972f18@127.0.0.1> <JIEGINCHMLABHJBIGKBCGEBAHBAA.julian.reschke@gmx.de> <20030417110438.78738895.henrik@levkowetz.com> <JIEGINCHMLABHJBIGKBCOEALHBAA.julian.reschke@gmx.de>
Message-ID: <5.1.0.14.2.20030422170003.02d475a0@127.0.0.1>

At 15:36 18/04/2003 -0700, Chris Newman wrote:
>begin quotation by Graham Klyne on 2003/4/17 8:41 +0100:
>>It seems to me a little at odds with normal XML practice to use <cell/> as a
>>separator rather than a container.
>>...
>>   <c>column 1 text</c><c>column 2 text</c><c>column 3 text</c>
>>...
>
>Can you elaborate some more?  As far as I can tell, the content divider 
>model is permitted and used in XML (e.g., xhtml's <br/> tag).  Absent 
>justification, I'd lean in the direction of the model with half as many 
>tags to type.  But unlike row tags, I might be willing to compromise on 
>the column tags if I'm missing some knowledge about why XML practice 
>prefers container tags to delimiter tags.

I don't think you're missing any knowledge here.  It's a small matter, not 
worth a religious war, but here's some vague rationale for what I said...

To my mind the design of XML anticipates that elements are primarily used 
as containers.   The syntax <elem/> is specifically defined as a shorthand 
for <elem></elem>, and is called an "empty" element.  So, when using XML, I 
come to expect that elements are used to enclose or represent values, 
rather than to merely act as separators of other data.  In the XML data 
model, I think of an element as a node in a tree, and expect to find 
associated data contained in sub-branches from that node.

<c>...</c> would be conceptually more like <t>...</t>.   (I did think of 
suggesting <t>...</t> for cell contents, but couldn't decide if one might 
want to leave room for multiple paragraphs in a single cell.)

I don't claim that your design was in any sense wrong, just not quite 
consistent with the way I have come to see XML used, so it's mainly down to 
personal perception.  And I did recognize the "half as many tags" advantage 
when I said I could see why you might prefer your approach.

...

You mention XHTML's <br/> tag:  I think:
(a) <br/> actually represents some content (a line break), rather than 
being just a separator.  <hr/> would be another example.
(b) it's existence is in part due to HTML legacy.

...

Having said all that, I did just think of a possible practical reason to 
prefer elements-as-containers.  If one considers that a design is not 
final, which part is more likely to be subject to some future enhancement 
to its content model?  The separator or the cell content?  I think the 
latter.  (Julian raised the example of left- or right- justification of 
text within a cell.)

Using XML, I submit it's easier to extend the content model of an element 
than some character data, and especially to do so in a backward compatible 
fashion.  There are ifs and maybes here, but it suggests to me that putting 
cell content in a container element is a more open-ended design.

#g


-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E



From: GK@ninebynine.org (Graham Klyne)
Date: Tue, 22 Apr 2003 16:53:38 +0100
Subject: [xml2rfc] non-artwork text in figures
In-Reply-To: <JIEGINCHMLABHJBIGKBCGEDMHBAA.julian.reschke@gmx.de>
References: <JIEGINCHMLABHJBIGKBCEEDLHBAA.julian.reschke@gmx.de>
Message-ID: <5.1.0.14.2.20030422164851.030d29a0@127.0.0.1>

At 09:53 18/04/2003 +0200, Julian Reschke wrote:
>Feedback appreciated,

1. I don't see a great need for this.  YMMV.

2. It doesn't play very well with the feature of using a link-to-graphic 
for HTML output.  (That's a feature I have used.)

3. I think the use-cases suggested by your examples would be better handled 
by tables, which are a separate design discussion.

#g
--


>Hi,
>
>here's another thing I frequently wished was possible.
>
>Currently, people use figures and artwork to put in protocol definitions
>such as BNFs (for instance see [1]). The problem here is that the <artwork>
>doesn't allow any markup inside, so you can't link from/to anchors within
>that figure. However, this would be *extremely* useful, because it would
>allow you hyperlink between the various protocol definitions.
>
>One way to fix this would be to simply allow markup within the artwork
>element. So instead of:
>
><figure><preamble>
><iref item="unreserved" primary="true"/>
><iref item="mark" primary="true"/>
>    Data characters that are allowed in a URI but do not have a reserved
>    purpose are called unreserved.  These include upper and lower case
>    letters, decimal digits, and a limited set of punctuation marks and
>    symbols.
><iref item="URI grammar" subitem="unreserved" primary="true"/>
><iref item="URI grammar" subitem="mark" primary="true"/>
></preamble><artwork>
>    unreserved  = ALPHA / DIGIT / mark
>
>    mark        = "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")"
></artwork></figure>
>
>one could use:
>
><figure><preamble>
><iref item="unreserved" primary="true"/>
><iref item="mark" primary="true"/>
>    Data characters that are allowed in a URI but do not have a reserved
>    purpose are called unreserved.  These include upper and lower case
>    letters, decimal digits, and a limited set of punctuation marks and
>    symbols.
><iref item="URI grammar" subitem="unreserved" primary="true"/>
><iref item="URI grammar" subitem="mark" primary="true"/>
></preamble><artwork>
>    <t anchor="grammar-unreserved">unreserved</t>  = ALPHA / DIGIT / <xref
>target="grammar-mark">mark</xref>
>
>    <t anchor="grammar-mark">mark</t>        = "-" / "_" / "." / "!" / "~" /
>"*" / "'" / "(" / ")"
></artwork></figure>
>
>
>This would require the following changes:
>
>- change content model for <artwork> to %TEXT (or add a new element for
>that)
>- allow <t> to have anchors (that should be a no-brainer)
>- possibly a way to instruct <xref> not to add any user-visible text (just
>the linking information)
>
>
>Another use-case that would benefit from that extension is when text in
>figures refers to references, such as (see RFC2518,
><http://greenbytes.de/tech/webdav/rfc2518.html#HEADER_Timeout>, section
>9.8):
>
>    TimeOut = "Timeout" ":" 1#TimeType
>    TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other)
>    DAVTimeOutVal = 1*digit
>    Other = "Extend" field-value   ; See section 4.2 of [RFC2068]
>
>
>Feedback appreciated,
>
>Julian
>
>
>[1]
><http://cvs.apache.org/viewcvs.cgi/*checkout*/ietf-uri/rev-2002/rfc2396bis.h
>tml?rev=HEAD&content-type=text/html>
>
>--
><green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
>_______________________________________________
>xml2rfc mailing list
>xml2rfc@lists.xml.resource.org
>http://lists.xml.resource.org/mailman/listinfo/xml2rfc

-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E



From: GK@ninebynine.org (Graham Klyne)
Date: Tue, 22 Apr 2003 16:46:06 +0100
Subject: [xml2rfc] xml2rfc v1.18 imminent...
In-Reply-To: <20030417175933.3456e190.mrose+internet.xml2rfc@dbc.mtview. ca.us>
References: <JIEGINCHMLABHJBIGKBCGECEHBAA.julian.reschke@gmx.de> <20030417100031.50d3021a.mrose+internet.xml2rfc@dbc.mtview.ca.us> <JIEGINCHMLABHJBIGKBCGECEHBAA.julian.reschke@gmx.de>
Message-ID: <5.1.0.14.2.20030422164425.02caeea8@127.0.0.1>

At 17:59 17/04/2003 -0700, Marshall Rose wrote:
> > Can we get back to the issue which styles are defined and what they mean
> > then?
>
>sure:
>
>    emph: indicates emphasis;
>
>    strong: indicates stronger emphasis; and,
>
>    verb: indicates sample input for programs.

"verb" is not obvious to me.  How about "entry"?

(Just a suggestion, I don't care deeply.)

#g


-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E



From: GK@ninebynine.org (Graham Klyne)
Date: Tue, 22 Apr 2003 16:35:57 +0100
Subject: [xml2rfc] xml2rfc v1.18 imminent...
In-Reply-To: <20030417090925.3d180187.mrose+internet.xml2rfc@dbc.mtview. ca.us>
References: <5.1.0.14.2.20030416235657.00b78330@127.0.0.1> <20030416150021.3f00af70.mrose+internet.xml2rfc@dbc.mtview.ca.us> <5.1.0.14.2.20030416235657.00b78330@127.0.0.1>
Message-ID: <5.1.0.14.2.20030422162615.02d5a008@127.0.0.1>

It seems to me there is a bug in the requirements, then.

It would seem wrong to me if, say, "IANA considerations" was not permitted 
to have subsections.

This in turn suggests that the "IANA considerations" section should be 
numbered.

(ditto security considerations.)

That said, I suppose if we have no constructive dialog about this, the 
problem might be solved by an additional level of indirection ... follow 
the rules you suggest, and if the actual considerations involve multiple 
subsections then add text like "IANA considerations are covered in section 
x.x" in the pro forma section at the end.  (I suppose that might even be 
automated, by looking for section headers in the main body text ;-)

#g
--

At 09:09 17/04/2003 -0700, Marshall Rose wrote:
> > Hmmm... using numbers-letters-numbers looks rather odd to me.
>
>i agree. the rfc-editor just doesn't number them, which works fine right until
>you have subsections...
>
>
> > My current suggestion is that sections that come after appendices get
> > section "numbers" that follow on from the appendix labelling, e.g.
> >
> >      1. Introduction
> >      2. Specification
> >      3. Example
> >      A. Acknowledgements
> >      B. IANA Considerations
> >      C. Security Considerations
> >      C.1  Confidentiality
> >      C.2  Traffic Analysis
> >
> > This, to me, seems like a logical conclusion of requiring that these
> > sections always appear at the end of the document.  If there are no
> > appendices, then the special sections might be numbered or lettered -- I'm
> > agnostic on that.
>
>
>the fundamental problem that i had when defining rfc2629 and writing 
>xml2rfc is
>the fact that the publication process is primarily a manual process. what this
>means is that rules are consistently applied in theory, but not in practice.
>it's not that the rules are ignored, it's just that things slip through
>the cracks because a person is enforcing them instead of a program.
>
>for example, if you study rfc2223 very carefully, you will find some places
>where it does not conform to rfc2223. was this on purpose? probably not. it's
>just an artifact of a process that is essentially manual rather automated.
>
>the issue with the numbering is a derivative of this situation. sure, not
>numbering things like "*Considerations" is fine, right until you have
>subsections. when you have to write code that implements these rules, this 
>kind
>of gap in the input domain becomes obvious. perhaps the obvious thing is to do
>this:
>
>         1. sections which appear after appendices are unnumbered
>         2. sections which appear after appendices may not have subsections
>
>/mtr
>_______________________________________________
>xml2rfc mailing list
>xml2rfc@lists.xml.resource.org
>http://lists.xml.resource.org/mailman/listinfo/xml2rfc

-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E



From: aki.niemi@nokia.com (aki.niemi@nokia.com)
Date: Tue, 22 Apr 2003 14:07:38 +0300
Subject: [xml2rfc] 1.15 format style list numbering does not reset
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194522C@esebe013.ntc.nokia.com>

[snip]

 > Resetting counters is problematic for other reasons as well. 
 > For instance,
 > numbering depends on ordering, and ordering can easily break 
 > when paragraphs
 > are moved around. For instance, if you have two lists, where 
 > the first has a
 > "startAt=1", and then move the second list before the first 
 > list, the result
 > almost certainly won't be what you wanted. It's simply a 
 > better processing
 > model to explicitly name what should be counted, for instance:
 > 
 > 	<list style="format R%" counter="requirements">
 > 
 > This will also allow to use the same format string for 
 > different counters.

This looks like a very compelling reason indeed to go with "counter" instead of "startAt". I want to have as little dependency to ordering as possible. Often times especially with requirements documents, the above case happens a lot as requirements tend to get moved around.

Cheers,
Aki


From: julian.reschke@gmx.de (Julian Reschke)
Date: Tue, 22 Apr 2003 10:15:10 +0200
Subject: [xml2rfc] Text Tables in xml2rfc
In-Reply-To: <2147483647.1050935558@nifty-jr.west.sun.com>
Message-ID: <JIEGINCHMLABHJBIGKBCGEKFHBAA.julian.reschke@gmx.de>

> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of Chris Newman
> Sent: Monday, April 21, 2003 11:33 PM
> To: Julian Reschke; xml2rfc@lists.xml.resource.org
> Subject: RE: [xml2rfc] Text Tables in xml2rfc
>
>
> To respond to some of your comments about my proposal:
>
> > Then let's discuss which of the proposals is more complex. My  claim is
that
> > the well-known model of rows and cells being containers is  indeed
simpler.
>
> This is an assertion, not technical evidence for simplicity.  My  proposal
is
> simpler because it has less than half as many tags as HTML tables.

Again, this is only true if you measure complexity by counting tags. I
already said that I believe this is wrong -- there are other aspects which
are equally important (see below).

> > I'm talking about adjustment in table cells. For instance, if  table
cells
> > contain numerical values, you will almost certainly want to have them
> > right-justified.
>
> Does anyone else think this is a requirement?

So if you feel this isn't needed? How are you going to align numerical
values then? By manually aligning with spaces? I thought that's one of the
things we want to get rid off.

> > Note that the table system used by nroff (tbl) indeed supports
> > left-adjustment, right-adjustment and centering (and I think  aligning
...
>
> xml2rfc was never intended to achieve feature parity with nroff  or HTML,
so
> that's a non-argument.

Yes. It wasn't meant to be an argument. I was just summarizing results from
tests with nroff, and thought that people might be interested.

> begin quotation by Julian Reschke on 2003/4/19 20:36 +0200:
> >> When people say they believe something is unnnecessarily  complex and
they
> >> find it difficult to use, let's take that statement at face value, OK?
> >
> > With all respect: not OK if it's affecting design decisions.

(What I *meant* to say here is that of course one should listen to these
statements, but that shouldn't mean that design decisions should be based
*only* on these statements)

> Standards work has to have a heavy bias in the direction of  simplicity to
be
> effective.  Otherwise design-by-committee takes over and we end  up with
an
> unusable complex mess.  So in a well-run standards community, if  you want
more
> complexity you have to come up with substantive technical  justifications
(so
> far, your consistency point is the only one).

Again, this is because you seem to use "number-of-tags-to-type" as single
measure of complexity. I clearly disagree.

BTW: your proposal could be simplified to use even less tags by replacing
the cell boundary markers by -- for instance -- TAB characters.

> begin quotation by Julian Reschke on 2003/4/19 21:28 +0200:
> > Other things to consider are:
> >
> > - extensibility
> > - robustness during edits (cut & paste, moving document  fragments
around)
> > - better programmatic validation (we're currently stuck with DTDs, so it
> > makes sense to have a format where a validating XML processor can give
> > useful error messages)
> > - and last but not least optionally better editing support for  those
that do
> > happen to have a "fancy" editor
>
> Can you elaborate on how these issues apply to the table cell  discussion?
I
> suspect there may be one or more substantive issues in this list

OK, I'll try.

Extensibility: if we don't have proper container elemenrts, it may be harder
to extend the table engine at a later point of time.

Robustness: in the absence of row tags, it will be extremely easy to mess up
a table by losing a single cell marker (or by accidentally adding a spurious
one)

Validation: a stronger content model will allow validators to catch more
input errors, and XML-aware editors may offer better editing tools (such as
moving around complete rows).

Here's another question to the proposed content model: is whitespace
significant? Are carriage returns significant? In the example:

<texttable>
  <ttcol width="10%">Title 1</ttcol>
  <ttcol width="40%">Title 2</ttcol>
  <ttcol>Title 3</ttcol>
  column 1 text<cell />column 2 text<cell />column 3 text<cell />
  row 2 col 1  <cell />row 2 col 2  <cell />row 2 col 3  <cell />
  empty col:   <cell />             <cell />row 3 col 3
</texttable>

does the last cell contain a carriage return?

> > In which case we'd either need to be able to introduce line break hints,
or live  with the fact
> > that we can't use "tbl".
>
> I wouldn't use tbl for the nroff.  xml2nroff is already a  pre-processor,
so why
> introduce another pre-processor step -- especially if we need all  the
machinery
> for the text output anyway?  The nroff output is only there as  input to
the RFC
> editors, and they'll probably be happier with .nf/.fi artwork
> than with tbl.

Yes, but it struck me as simple way to implement tables with existing
technology. Therefore I tried.

This basically means that an RFC2629 processor that produces plain text will
have to implement a multicolumn table formatter (including answers to nasty
problems such as table cells that contain *words* that are too wide).
Therefore we should at least consider to leave that one out.

> > So maybe we should look at the requirements again:
> >
> > - free the user from the task of aligning columns himself
> > - enhance the markup so that better formatting can be created for output
> > formats such as HTML, XSL-FO and PDF.
>
> I'd say the primary goal is: "A mechanism to create simple tables  that's
faster
> than ASCII art and works in any text editor"

Yes, but that's a bit vague, right? Therefore I'd prefer to write down what
we really want to achieve.

> > - cell justification (I think we should have at least right- and
> > left-justification) -- is justification per cell (HTML, tbl) or  per
column
> > (simpler), though?
> > - decorations (such as rules and boxes, see again tbl manual)
>
> I don't think either is necessary as part of the format.  Simplicity is a
> primary goal here.

Again, that depends on how you define simplicity. For instance, if you say
that you don't want cell adjustment to keep the *format* simpler, this means
that *authoring* these tables may be harder.

Julian

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



From: swb@employees.org (Scott W Brim)
Date: Mon, 21 Apr 2003 22:58:39 -0400
Subject: [xml2rfc] Text Tables in xml2rfc
In-Reply-To: <2147483647.1050935558@nifty-jr.west.sun.com>
References: <JIEGINCHMLABHJBIGKBCKEFPHBAA.julian.reschke@gmx.de> <2147483647.1050935558@nifty-jr.west.sun.com>
Message-ID: <20030422025839.GX1612@sbrim-w2k>

On Mon, Apr 21, 2003 02:32:38PM -0700, Chris Newman allegedly wrote:
> begin quotation by Julian Reschke on 2003/4/19 10:00 +0200:
> >I'm talking about adjustment in table cells. For instance, if table cells
> >contain numerical values, you will almost certainly want to have them
> >right-justified.
> 
> Does anyone else think this is a requirement?

*if* you're going to do this at all, then yes -- and also justification
around a decimal point or other character.



From: Chris.Newman@Sun.COM (Chris Newman)
Date: Mon, 21 Apr 2003 14:32:38 -0700
Subject: [xml2rfc] Text Tables in xml2rfc
In-Reply-To: <JIEGINCHMLABHJBIGKBCKEFPHBAA.julian.reschke@gmx.de> <JIEGINCHMLABHJBIGKBCEEGKHBAA.julian.reschke@gmx.de> <JIEGINCHMLABHJBIGKBCGEGLHBAA.julian.reschke@gmx.de> <JIEGINCHMLABHJBIGKBCEEGOHBAA.julian.reschke@gmx.de> <JIEGINCHMLABHJBIGKBCGEHFHBAA.julian.reschke@gmx.de> <JIEGINCHMLABHJBIGKBCCEHJHBAA.julian.reschke@gmx.de>
References: <JIEGINCHMLABHJBIGKBCKEFPHBAA.julian.reschke@gmx.de>
Message-ID: <2147483647.1050935558@nifty-jr.west.sun.com>

To respond to some of your comments about my proposal:

begin quotation by Julian Reschke on 2003/4/19 10:00 +0200:
> So we need to trade-off less typing and a sane XML content model :-)

This is not a technical response.

> Then let's discuss which of the proposals is more complex. My claim is that
> the well-known model of rows and cells being containers is indeed simpler.

This is an assertion, not technical evidence for simplicity.  My proposal is 
simpler because it has less than half as many tags as HTML tables.

> I'm talking about adjustment in table cells. For instance, if table cells
> contain numerical values, you will almost certainly want to have them
> right-justified.

Does anyone else think this is a requirement?

> Note that the table system used by nroff (tbl) indeed supports
> left-adjustment, right-adjustment and centering (and I think aligning ...

xml2rfc was never intended to achieve feature parity with nroff or HTML, so 
that's a non-argument.

>> I wouldn't object if texttables could optionally be in the  "figure" content
>> model.  But not all tables are figures.
> Yes.

So we agree on this point.  Unless there are other comments, I'll assume rough 
consensus.

> Of course it's *possible* to design the language that way. However, most XML
> languages are designed differently, and so is RFC2629's XML. For instance,
> the same argument would apply to list items, sections and so on. They all
> are containers, and thus we should stay consistent with that.

Consistency is a substantive argument for the container model.  I don't find it 
compelling by itself, but it is substantive.

> It seems that you prefer almost no structure to a simple structure. Yes,
> HTML tables have simple structure. They consist of rows, and each row
> consists of cells. I don't think you can get a table structure much simpler
> than that.

It's certainly true that the data model for tables is row containers with cell 
containers.  But with xml2rfc we are defining a document markup syntax rather 
than a data structure syntax.  The former needs to represent the data in such a 
way that it's easy to type and the data structure can be derived.  I'd agree 
with you immediately if we were designing a data structure format.

begin quotation by Julian Reschke on 2003/4/19 20:36 +0200:
>> When people say they believe something is unnnecessarily complex and they
>> find it difficult to use, let's take that statement at face value, OK?
>
> With all respect: not OK if it's affecting design decisions.

Standards work has to have a heavy bias in the direction of simplicity to be 
effective.  Otherwise design-by-committee takes over and we end up with an 
unusable complex mess.  So in a well-run standards community, if you want more 
complexity you have to come up with substantive technical justifications (so 
far, your consistency point is the only one).

begin quotation by Julian Reschke on 2003/4/19 21:28 +0200:
> Other things to consider are:
>
> - extensibility
> - robustness during edits (cut & paste, moving document fragments around)
> - better programmatic validation (we're currently stuck with DTDs, so it
> makes sense to have a format where a validating XML processor can give
> useful error messages)
> - and last but not least optionally better editing support for those that do
> happen to have a "fancy" editor

Can you elaborate on how these issues apply to the table cell discussion?  I 
suspect there may be one or more substantive issues in this list.

begin quotation by Julian Reschke on 2003/4/20 12:25 +0200:
> However, what it doesn't seem to be capable of is to break
> long table cells into multiple lines, such as:
>
> Apples       20
> Oranges     10
> Apples and
> Oranges     30
>
> So my first question is: is that a required feature?

I'd say yes.  That's a major value-add over hand-editing artwork tables, and 
the requirement prevents a silly state (where the document contains a 
syntactically valid table which can't be formatted for text output).

> In which case we'd
> either need to be able to introduce line break hints, or live with the fact
> that we can't use "tbl".

I wouldn't use tbl for the nroff.  xml2nroff is already a pre-processor, so why 
introduce another pre-processor step -- especially if we need all the machinery 
for the text output anyway?  The nroff output is only there as input to the RFC 
editors, and they'll probably be happier with .nf/.fi artwork than with tbl.

> So maybe we should look at the requirements again:
>
> - free the user from the task of aligning columns himself
> - enhance the markup so that better formatting can be created for output
> formats such as HTML, XSL-FO and PDF.

I'd say the primary goal is: "A mechanism to create simple tables that's faster 
than ASCII art and works in any text editor"

> - cell justification (I think we should have at least right- and
> left-justification) -- is justification per cell (HTML, tbl) or per column
> (simpler), though?
> - decorations (such as rules and boxes, see again tbl manual)

I don't think either is necessary as part of the format.  Simplicity is a 
primary goal here.

                - Chris



From: julian.reschke@gmx.de (Julian Reschke)
Date: Sun, 20 Apr 2003 12:25:50 +0200
Subject: generating NROFF (tbl) tables, was: [xml2rfc] Text Tables in xml2rfc
In-Reply-To: <JIEGINCHMLABHJBIGKBCGEHFHBAA.julian.reschke@gmx.de>
Message-ID: <JIEGINCHMLABHJBIGKBCCEHJHBAA.julian.reschke@gmx.de>

OK,

I have done some experiments with table extensions, both for HTML (simple)
and NROFF (hard). Maybe somebody on this list knows more about nroff/tbl
processing and can give me some help...

Nroff produces tables using "tbl" preprocessing (for instance see manual at:
http://www.chemie.fu-berlin.de/cgi-bin/man/sgi_irix?tbl+1). This format
seems to do just about all we need (including different types of
justification). However, what it doesn't seem to be capable of is to break
long table cells into multiple lines, such as:

Apples       20
Oranges     10
Apples and
Oranges     30

So my first question is: is that a required feature? In which case we'd
either need to be able to introduce line break hints, or live with the fact
that we can't use "tbl". Marshall, are you planning to put that kind of
formatting engine into your TCL code?

So maybe we should look at the requirements again:

- free the user from the task of aligning columns himself
- enhance the markup so that better formatting can be created for output
formats such as HTML, XSL-FO and PDF.

Optionally (to be discussed!):

- cell justification (I think we should have at least right- and
left-justification) -- is justification per cell (HTML, tbl) or per column
(simpler), though?
- decorations (such as rules and boxes, see again tbl manual)

Regards,

Julian

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



From: henrik@levkowetz.com (Henrik Levkowetz)
Date: Sun, 20 Apr 2003 11:19:42 +0200
Subject: [xml2rfc] Text Tables in xml2rfc
In-Reply-To: <JIEGINCHMLABHJBIGKBCGEHFHBAA.julian.reschke@gmx.de>
References: <20030420002351.4a6bd86a.henrik@levkowetz.com> <JIEGINCHMLABHJBIGKBCGEHFHBAA.julian.reschke@gmx.de>
Message-ID: <20030420111942.1de784ee.henrik@levkowetz.com>

On Sun, 20 Apr 2003 10:12:59 +0200, "Julian Reschke" <julian.reschke@gmx.de> wrote:
> Henrik,
> 
> I didn't say that this aspect should be ignored. All I said is that there
> are *other* important aspects that need to be considered as well, and thus a
> statement like "it's easier to type, thus we'll use that format" IMHO
...<snip>...

	I'm taking my response to this off-list.

	Henrik

-- 
  What is the difference between snowmen and snowwomen?
    Snowballs.


From: julian.reschke@gmx.de (Julian Reschke)
Date: Sun, 20 Apr 2003 10:12:59 +0200
Subject: [xml2rfc] Text Tables in xml2rfc
In-Reply-To: <20030420002351.4a6bd86a.henrik@levkowetz.com>
Message-ID: <JIEGINCHMLABHJBIGKBCGEHFHBAA.julian.reschke@gmx.de>

> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of Henrik
> Levkowetz
> Sent: Sunday, April 20, 2003 12:24 AM
> To: Julian Reschke
> Cc: xml2rfc@lists.xml.resource.org
> Subject: Re: [xml2rfc] Text Tables in xml2rfc
>
>
> On Sat, 19 Apr 2003 20:36:48 +0200, "Julian Reschke"
> <julian.reschke@gmx.de> wrote:
>
> > > When people say they believe something is unnnecessarily
> complex and they
> > > find it difficult to use, let's take that statement at face value, OK?
> >
> > With all respect: not OK if it's affecting design decisions.
>
> To me, this statement is *really, really* bothersome.
>
> If the users of a tool experiences thinks in a certain manner, that is
> exactly what is relevant in designing the user interface. In this case,
> the complexity of the XML.

Henrik,

I didn't say that this aspect should be ignored. All I said is that there
are *other* important aspects that need to be considered as well, and thus a
statement like "it's easier to type, thus we'll use that format" IMHO
indicates the wrong way of designing an XML language. If ease of  typing
would be the only aspect, I'd (honestly!) recommend using something like
SGML (more optional end tags, less escaping) or even NROFF.

> If you don't care about the users' experience, you may end up with a
> tool you think is great, with the world's greatest design, but *no*
> users.

I do care. However, robustness and extensibility are important for the
user's experience as well. Robustness means that users can easily move
document sections around without messing things up. Extensibility means that
we are able to extend elements in a logical way at a later point (instead of
having to introduce nasty hacks).

Let me also note that these aspects clearly have influenced the current
state of the syntax, so I don't understand why they would suddenly be
unimportant.

Finally, I'm really surprised that a discussion about elements-as-markers
vs. elements-as-container (that's where we started?) can lead to such a
heated debate. Could we *please* try to get back to a technical discussion?

Julian

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



From: henrik@levkowetz.com (Henrik Levkowetz)
Date: Sun, 20 Apr 2003 00:23:51 +0200
Subject: [xml2rfc] Text Tables in xml2rfc
In-Reply-To: <JIEGINCHMLABHJBIGKBCGEGLHBAA.julian.reschke@gmx.de>
References: <01KUWRLFJRWQ002DEU@mauve.mrochek.com> <JIEGINCHMLABHJBIGKBCGEGLHBAA.julian.reschke@gmx.de>
Message-ID: <20030420002351.4a6bd86a.henrik@levkowetz.com>

On Sat, 19 Apr 2003 20:36:48 +0200, "Julian Reschke" <julian.reschke@gmx.de> wrote:

> > When people say they believe something is unnnecessarily complex and they
> > find it difficult to use, let's take that statement at face value, OK?
> 
> With all respect: not OK if it's affecting design decisions. 

To me, this statement is *really, really* bothersome. 

If the users of a tool experiences thinks in a certain manner, that is
exactly what is relevant in designing the user interface. In this case,
the complexity of the XML.

If you don't care about the users' experience, you may end up with a
tool you think is great, with the world's greatest design, but *no*
users.

	Henrik

-- 
  It is far more impressive when others discover your good
  qualities without your help.


From: julian.reschke@gmx.de (Julian Reschke)
Date: Sat, 19 Apr 2003 21:28:07 +0200
Subject: [xml2rfc] Text Tables in xml2rfc
In-Reply-To: <01KUWT4WKQXY002DEU@mauve.mrochek.com>
Message-ID: <JIEGINCHMLABHJBIGKBCEEGOHBAA.julian.reschke@gmx.de>

> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of
> ned.freed@mrochek.com
> Sent: Saturday, April 19, 2003 9:03 PM
> To: Julian Reschke
> Cc: xml2rfc@lists.xml.resource.org
> Subject: RE: [xml2rfc] Text Tables in xml2rfc
>
>
> ...
>
> Then it appears we have nothing to say to each other, since IMO it is
> precisely such assessments that should best inform our design choices.
>
> ...

There are a lot of things to consider when designing XML formats. One is of
course ease of typing. However, that's *not* the single relevant metric, and
selecting a specific format just because it's easier to type IMHO almost
always is a bad idea.

Other things to consider are:

- extensibility
- robustness during edits (cut & paste, moving document fragments around)
- better programmatic validation (we're currently stuck with DTDs, so it
makes sense to have a format where a validating XML processor can give
useful error messages)
- and last but not least optionally better editing support for those that do
happen to have a "fancy" editor

Julian

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



From: ned.freed@mrochek.com (ned.freed@mrochek.com)
Date: Sat, 19 Apr 2003 12:03:21 -0700 (PDT)
Subject: [xml2rfc] Text Tables in xml2rfc
In-Reply-To: "Your message dated Sat, 19 Apr 2003 20:36:48 +0200" <JIEGINCHMLABHJBIGKBCGEGLHBAA.julian.reschke@gmx.de>
References: <01KUWRLFJRWQ002DEU@mauve.mrochek.com> <JIEGINCHMLABHJBIGKBCGEGLHBAA.julian.reschke@gmx.de>
Message-ID: <01KUWT4WKQXY002DEU@mauve.mrochek.com>

> > From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com]
> > Sent: Saturday, April 19, 2003 8:21 PM
> > To: Julian Reschke
> > Cc: xml2rfc@lists.xml.resource.org
> > ...
> > Let's please not turn this into a "everything would be better if  you use
> this
> > tool or a better tool" discussion. Such discussions litter the archives of
> > countless IETF lists and have never proved to be productive.

> Oh well. That's not what I said.

> I just wanted to clarify that MTR is wrong when he assumes that I'm using
> fancy XML tools. A plain text editor is just fine. But even many plain text
> editors nowadays come with basic XML (or HTML) support, such as for closing
> tags. So saying that we can't do this or that because closing tags is too
> cumbersome doesn't really make sense.

> > When people say they believe something is unnnecessarily complex and they
> > find it difficult to use, let's take that statement at face value, OK?

> With all respect: not OK if it's affecting design decisions. Is it suddenly
> forbidden to mention that there's a big variety of free text editing tools
> that make editing XML less painful? People may not be aware of the fact that
> a simple freeware editor combined with Mozilla or IE makes an almost WYSIWYG
> editing environment.

Then it appears we have nothing to say to each other, since IMO it is
precisely such assessments that should best inform our design choices.

As for the notion that people are unaware that such tools exist: Please.
This is simply insulting.

				Ned


From: julian.reschke@gmx.de (Julian Reschke)
Date: Sat, 19 Apr 2003 20:36:48 +0200
Subject: [xml2rfc] Text Tables in xml2rfc
In-Reply-To: <01KUWRLFJRWQ002DEU@mauve.mrochek.com>
Message-ID: <JIEGINCHMLABHJBIGKBCGEGLHBAA.julian.reschke@gmx.de>

> From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com]
> Sent: Saturday, April 19, 2003 8:21 PM
> To: Julian Reschke
> Cc: xml2rfc@lists.xml.resource.org
> ...
> Let's please not turn this into a "everything would be better if  you use
this
> tool or a better tool" discussion. Such discussions litter the archives of
> countless IETF lists and have never proved to be productive.

Oh well. That's not what I said.

I just wanted to clarify that MTR is wrong when he assumes that I'm using
fancy XML tools. A plain text editor is just fine. But even many plain text
editors nowadays come with basic XML (or HTML) support, such as for closing
tags. So saying that we can't do this or that because closing tags is too
cumbersome doesn't really make sense.

> When people say they believe something is unnnecessarily complex and they
> find it difficult to use, let's take that statement at face value, OK?

With all respect: not OK if it's affecting design decisions. Is it suddenly
forbidden to mention that there's a big variety of free text editing tools
that make editing XML less painful? People may not be aware of the fact that
a simple freeware editor combined with Mozilla or IE makes an almost WYSIWYG
editing environment.

One of the subjects of this mailing list is discussing changes in future
RFC2629 revisions. That's what we're doing here, and I fail to see a problem
with that.

To be honest, I might agree if we'd be discussing to-XML-or-not-to-XML. But
we already do XML, and separate end tags are already required for almost all
of RFC2629's XML elements. I don't see why adding another one changes
things.

Julian

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



From: ned.freed@mrochek.com (ned.freed@mrochek.com)
Date: Sat, 19 Apr 2003 11:20:46 -0700 (PDT)
Subject: [xml2rfc] Text Tables in xml2rfc
In-Reply-To: "Your message dated Sat, 19 Apr 2003 19:54:29 +0200" <JIEGINCHMLABHJBIGKBCEEGKHBAA.julian.reschke@gmx.de>
References: <20030419104115.25019ce6.mrose+internet.xml2rfc@dbc.mtview.ca.us> <JIEGINCHMLABHJBIGKBCEEGKHBAA.julian.reschke@gmx.de>
Message-ID: <01KUWRLFJRWQ002DEU@mauve.mrochek.com>

> Marshall,

> thanks for the feedback and the attempt to clarify. My take is that you may
> see things way too pessimistic.

> Anyway, ...:

> > for example, you use xml editing tools. the traditional community that
> > creates rfcs -- the core consituency for 2629 -- doesn't.

> Not really. I use a "HTML-Kit", a free plain text editor that happens to be
> capable of closing the "previous" open tag [1]. Nothing fancy. Other popular
> editors such as Emacs can do that as well.

> Note that it also allows almost real-time display of the HTML version (just
> press F8 and the XML document is opened in the system's browser which of
> course must be XSLT-capable, such as Mozilla or IE).

Let's please not turn this into a "everything would be better if you use this
tool or a better tool" discussion. Such discussions litter the archives of
countless IETF lists and have never proved to be productive.

When people say they believe something is unnnecessarily complex and they
find it difficult to use, let's take that statement at face value, OK?

				Ned


From: julian.reschke@gmx.de (Julian Reschke)
Date: Sat, 19 Apr 2003 19:54:29 +0200
Subject: [xml2rfc] Text Tables in xml2rfc
In-Reply-To: <20030419104115.25019ce6.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <JIEGINCHMLABHJBIGKBCEEGKHBAA.julian.reschke@gmx.de>

Marshall,

thanks for the feedback and the attempt to clarify. My take is that you may
see things way too pessimistic.

Anyway, ...:

> for example, you use xml editing tools. the traditional community that
> creates rfcs -- the core consituency for 2629 -- doesn't.

Not really. I use a "HTML-Kit", a free plain text editor that happens to be
capable of closing the "previous" open tag [1]. Nothing fancy. Other popular
editors such as Emacs can do that as well.

Note that it also allows almost real-time display of the HTML version (just
press F8 and the XML document is opened in the system's browser which of
course must be XSLT-capable, such as Mozilla or IE).

Julian

[1] <http://www.chami.com/html-kit/>

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



From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Sat, 19 Apr 2003 10:41:15 -0700
Subject: [xml2rfc] Text Tables in xml2rfc
In-Reply-To: <JIEGINCHMLABHJBIGKBCKEFPHBAA.julian.reschke@gmx.de>
References: <2147483647.1050680207@nifty-jr.west.sun.com> <JIEGINCHMLABHJBIGKBCKEFPHBAA.julian.reschke@gmx.de>
Message-ID: <20030419104115.25019ce6.mrose+internet.xml2rfc@dbc.mtview.ca.us>

julian - let's make this discussion more abstract for a moment.
    
the reason that you continue to get pushback from chris, myself, etc.,
is that your perspective on the rfc2629 environment is fundamentally
different than ours.
    
for example, you use xml editing tools. the traditional community that
creates rfcs -- the core consituency for 2629 -- doesn't.
    
the in the few months before 2629 was published, i had many, many
arguments with senior guys in the core constituency about why xml needed
closing tags...
    
after nearly four years, the rfc editor still won't accept rfcs in xml
format. in fact, they often start with text, edit it down to nroff,
and re-generate the text. if you give them nroff, then they may start
with that.
    
my point here is that you are so far ahead of the curve in your
expectations, etc., that half the time folks in the core constituency
can't understand what you're asking for.
    
over time the core constituency will become more sophisticated. but
right now, you are running far, far ahead of what their concerns are.
    
/mtr


From: julian.reschke@gmx.de (Julian Reschke)
Date: Sat, 19 Apr 2003 10:00:33 +0200
Subject: [xml2rfc] Text Tables in xml2rfc
In-Reply-To: <2147483647.1050680207@nifty-jr.west.sun.com>
Message-ID: <JIEGINCHMLABHJBIGKBCKEFPHBAA.julian.reschke@gmx.de>

> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of Chris Newman
> Sent: Saturday, April 19, 2003 12:37 AM
> To: xml2rfc@lists.xml.resource.org; Julian Reschke; Graham Klyne; Henrik
> Levkowetz
> Subject: RE: [xml2rfc] Text Tables in xml2rfc
>
>
> begin quotation by Julian Reschke on 2003/4/17 8:52 +0200:
> >> * Hand editing the <tr><td></td></tr> structure for HTML tables  is
awkward with
> >>   a text editor, thus that structure is not appropriate for xml2rfc
from the
> >>   ease-of-use standpoint.
> >
> > Not agreed. It's a very logical content model that everybody's aware of.
>
> I'll agree it's a logical content model that everybody is aware of, I even
> maintain several web pages with tables using BBEdit.  From  personal
experience
> it has poor usability in a text editor.  xml2rfc can be simpler and
better.

So we need to trade-off less typing and a sane XML content model :-)

> >> The outer entity is "texttable" (to distinguish from HTML   <table>).
This
> > must
> >
> > Why do we need to distinguish???
>
> Because we do not want to implement the HTML table model.  All  the
complexity
> relating to automatically sized column widths, missing cells,  column
spanning,
> column groups and various and sundry spacing options.  It's just  _way_
too
> complex to match xml2rfc's design goals.  I can't keep half of  the HTML
table
> features in my head and I rarely use most of them.

Nobody ever said we need all of them. I'd just prefer to just subset HTML
(with the benefit of re-use of existing knowledge and specs), instead of
re-inventing everything. But MTR has clarified why he doesn't want that, so
let's close that discussion.

> > - The structure doesn't have container elements for rows - why? Row
> > processing depends on the number of previously found ttcol  elements.
With
> > this structure, input errors (mismatches between column titles and cell
> > count) can not be detected.
>
> Row elements are unnecessary complexity and poor for usability.   I can't
see
> any possible way to justify that complexity.

If they are that unnecessary, why is it they are so popular then? HTML,
XSL:FO and DocBook have them. They all seem to agree that the logical
structure of the table should be reflected in the markup.

> > - Why aren't the cells container elements? (This and the  previous one
make
> > it extremely hard to process this structure using XSLT).
>
> Again, for simplicity.  A typical table layout with my proposal  requires
half
> as many tags with delimiter rather than container elements.  And  just
saying it
> makes it hard for XSLT could simply mean that XSLT needs to be  improved
in this
> area.  Good standards design means that additional complexity  requires
strong
> justification, whereas simplifications require minimal or no
justification.  So
> you need to justify your position better if you want it to stick.

Then let's discuss which of the proposals is more complex. My claim is that
the well-known model of rows and cells being containers is indeed simpler.

> > - how do I left/right adjust (I think this is a minimal requirement for
most
> > tables)?
>
> Are you talking about the entire table or about the layout of  text within
the
> table.  And why does it matter?  Please justify the complexity
> you propose.

I'm talking about adjustment in table cells. For instance, if table cells
contain numerical values, you will almost certainly want to have them
right-justified. The only way to achieve this with your proposal seems to be
by manually inserting whitespace infront of the values.

Note that the table system used by nroff (tbl) indeed supports
left-adjustment, right-adjustment and centering (and I think aligning
decimal values). I think it would be good if an RFC2629 processor that
produces nroff output could simply forward these parameters.

(Related: I note that tbl doesn't seem to support user-defined widths, so if
we want to be able to support nroff, we may have to make the support for the
width parameter optional)

> > - How are tables counted / labelled? Shouldn't this be in the "figure"
> > content model?
>
> I wouldn't object if texttables could optionally be in the  "figure"
content
> model.  But not all tables are figures.

Yes.

> begin quotation by Graham Klyne on 2003/4/17 8:41 +0100:
> > It seems to me a little at odds with normal XML practice to use
> <cell/> as a
> > separator rather than a container.
> > ...
> >   <c>column 1 text</c><c>column 2 text</c><c>column 3 text</c>
> > ...
>
> Can you elaborate some more?  As far as I can tell, the content  divider
model
> is permitted and used in XML (e.g., xhtml's <br/> tag).  Absent
justification,
> I'd lean in the direction of the model with half as many tags to  type.
But
> unlike row tags, I might be willing to compromise on the column  tags if
I'm
> missing some knowledge about why XML practice prefers container tags to
> delimiter tags.

Of course it's *possible* to design the language that way. However, most XML
languages are designed differently, and so is RFC2629's XML. For instance,
the same argument would apply to list items, sections and so on. They all
are containers, and thus we should stay consistent with that.

Note that in many cases people use <br> tags because they haven't understood
HTML paragraphs and/or CSS.

BTW: I use a text editor with tag completion. I'd recommend to do that as
well :-)

> begin quotation by Henrik Levkowetz on 2003/4/17 11:04 +0200:
> >> * HTML tables are _extremely_ complex to implement and don't  map well
to
> >> plain text display, and thus unsuitable for xml2rfc
> >
> > I think I disagree. *Rendering* of HTML tables is complex.  Writing them
is
> > straightforward.
>
> They are complex to render, they have a complex structure and  data model,
and
> while straightforward to edit (I edit them all the time in  BBEdit) they
are
> also cumbersome to edit.

It seems that you prefer almost no structure to a simple structure. Yes,
HTML tables have simple structure. They consist of rows, and each row
consists of cells. I don't think you can get a table structure much simpler
than that.

Julian

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



From: Chris.Newman@Sun.COM (Chris Newman)
Date: Fri, 18 Apr 2003 15:36:47 -0700
Subject: [xml2rfc] Text Tables in xml2rfc
In-Reply-To: <JIEGINCHMLABHJBIGKBCOEALHBAA.julian.reschke@gmx.de> <5.1.0.14.2.20030417083559.02972f18@127.0.0.1> <JIEGINCHMLABHJBIGKBCGEBAHBAA.julian.reschke@gmx.de> <20030417110438.78738895.henrik@levkowetz.com>
References: <JIEGINCHMLABHJBIGKBCOEALHBAA.julian.reschke@gmx.de>
Message-ID: <2147483647.1050680207@nifty-jr.west.sun.com>

begin quotation by Julian Reschke on 2003/4/17 8:52 +0200:
>> * Hand editing the <tr><td></td></tr> structure for HTML tables  is
> awkward with
>>   a text editor, thus that structure is not appropriate for  xml2rfc from
> the
>>   ease-of-use standpoint.
>
> Not agreed. It's a very logical content model that everybody's aware of.

I'll agree it's a logical content model that everybody is aware of, I even 
maintain several web pages with tables using BBEdit.  From personal experience 
it has poor usability in a text editor.  xml2rfc can be simpler and better.

>> The outer entity is "texttable" (to distinguish from HTML  <table>).  This
> must
>
> Why do we need to distinguish???

Because we do not want to implement the HTML table model.  All the complexity 
relating to automatically sized column widths, missing cells, column spanning, 
column groups and various and sundry spacing options.  It's just _way_ too 
complex to match xml2rfc's design goals.  I can't keep half of the HTML table 
features in my head and I rarely use most of them.

> - The structure doesn't have container elements for rows - why? Row
> processing depends on the number of previously found ttcol elements. With
> this structure, input errors (mismatches between column titles and cell
> count) can not be detected.

Row elements are unnecessary complexity and poor for usability.  I can't see 
any possible way to justify that complexity.

> - Why aren't the cells container elements? (This and the previous one make
> it extremely hard to process this structure using XSLT).

Again, for simplicity.  A typical table layout with my proposal requires half 
as many tags with delimiter rather than container elements.  And just saying it 
makes it hard for XSLT could simply mean that XSLT needs to be improved in this 
area.  Good standards design means that additional complexity requires strong 
justification, whereas simplifications require minimal or no justification.  So 
you need to justify your position better if you want it to stick.

> - how do I left/right adjust (I think this is a minimal requirement for most
> tables)?

Are you talking about the entire table or about the layout of text within the 
table.  And why does it matter?  Please justify the complexity you propose.

> - How are tables counted / labelled? Shouldn't this be in the "figure"
> content model?

I wouldn't object if texttables could optionally be in the "figure" content 
model.  But not all tables are figures.

begin quotation by Graham Klyne on 2003/4/17 8:41 +0100:
> It seems to me a little at odds with normal XML practice to use <cell/> as a
> separator rather than a container.
> ...
>   <c>column 1 text</c><c>column 2 text</c><c>column 3 text</c>
> ...

Can you elaborate some more?  As far as I can tell, the content divider model 
is permitted and used in XML (e.g., xhtml's <br/> tag).  Absent justification, 
I'd lean in the direction of the model with half as many tags to type.  But 
unlike row tags, I might be willing to compromise on the column tags if I'm 
missing some knowledge about why XML practice prefers container tags to 
delimiter tags.

begin quotation by Henrik Levkowetz on 2003/4/17 11:04 +0200:
>> * HTML tables are _extremely_ complex to implement and don't map well to
>> plain text display, and thus unsuitable for xml2rfc
>
> I think I disagree. *Rendering* of HTML tables is complex. Writing them is
> straightforward.

They are complex to render, they have a complex structure and data model, and 
while straightforward to edit (I edit them all the time in BBEdit) they are 
also cumbersome to edit.

>> * Using artwork for tables makes them a pain to edit.  This is contrary to a
>>   primary purpose of xml2rfc -- making RFCs/drafts simple to edit.
>
> I clearly disagree. Artwork is much easier to get exactly right for text
> output than using a table support feature.

> But I like TeX's simple table generation format better. I think
> you've taken some clues from that in your proposal :-)

Actually, I haven't.  Do you have any suggestions from TeX that might make my 
proposal simpler?

                - Chris





From: henrik@levkowetz.com (Henrik Levkowetz)
Date: Fri, 18 Apr 2003 23:19:07 +0200
Subject: [xml2rfc] 1.15 format style list numbering does not reset
In-Reply-To: <20030418101506.094af4f6.mrose+internet.xml2rfc@dbc.mtview.ca.us>
References: <20030418102643.05024022.henrik@levkowetz.com> <JIEGINCHMLABHJBIGKBCGEDNHBAA.julian.reschke@gmx.de> <20030418101506.094af4f6.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <20030418231907.698ccd03.henrik@levkowetz.com>

> if there isn't a compelling reason, then perhaps if we all agree that
> the matter is closed, then henrik would be willing to change his
> documents to use counter= instead of startAt=, and i'll ship him a new
> version so he can test it out...

That's OK by me.

	Henrik

-- 
  Being generous is inborn; being altruistic is a learned perversity. No
  resemblance -- 


From: julian.reschke@gmx.de (Julian Reschke)
Date: Fri, 18 Apr 2003 21:48:40 +0200
Subject: [xml2rfc] accomodating draft-rfc-editor-rfc2223bis-04.txt
In-Reply-To: <20030418120313.031e2ed7.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <JIEGINCHMLABHJBIGKBCOEFCHBAA.julian.reschke@gmx.de>

> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of Marshall Rose
> Sent: Friday, April 18, 2003 9:03 PM
> To: Julian Reschke
> Cc: mcr@sandelman.ottawa.on.ca; xml2rfc@lists.xml.resource.org
> Subject: Re: [xml2rfc] accomodating draft-rfc-editor-rfc2223bis-04.txt
>
>
> > I'd say not necessarily if we start with a minimal list.
>
> sure, the road to hell always starts with good intentions...

Yes.

> > It will be a pain, agreed. But in this particular example, lining up
isn't
> > really important. If you have a figure that requires that  things line
up,
> > either just don't use markup, or accept the penalty in usability.
>
> well, this sort of trade-off adds complexity...

Which?

> > > right now, <figure/> allows an anchor= attribute, so if you  put abnf
in
> > > <artwork/> you can reference it elsewhere.
> >
> > Yes, but I can only put one *single* anchor there. If an BNF fragment
> > defines multiple terms, I'd like to be able to do that. For instance, it
> > would be really convenient if I could identify any given BNF  term
defined in
> > a specific RFC by using a well-defined fragment identifier, such as:
> >
> > 	rfc2396#bnf.uri-reference
> >
> > Right now I can't.
>
> you're thinking about rendering html, not text. if you look at rendering
> text, the anchor on a <figure/> gets expanded to "Figure X".

- anchors are useful even when they aren't referenced from inside the
document (you may want to reference them from outside)
- referencing this kind of anchor from within the document may work by using
the xref variant with text content (no computed text is generated), or by
allowing the anchor to specify the text itself.

> what label would get rendered in text mode, e.g., "line Y of Figure X" ?

I'd ignore the issue and tell the user to use the xref variant with text
content.

> this is the same reason why <t/> doesn't have anchors, there's no
> meaningful way to generate a label when rendering text.

In these particular cases, no text need to be computed at all:

- in text mode, anchors and references just get displayed as if the
addtional data would be absent
- in other modes (such as HTML or XSL:FO/PDF), the anchors become link
targets, and references become links

So yes, this doesn't affect at all the text output mode. But it still would
be convenient to have when generating output for more capable formats.

I agree that documents must be written in a way such that the text version
provides all information required to understand what it specifies. However,
*most* of the time people look at HTML versions (at least that's my
experience), and this change would make these versions (XSL-FO/PDF as well)
both better navigatable (by adding more in-document links) and referencable
(through URI#fragment).

Julian

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



From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Fri, 18 Apr 2003 12:03:13 -0700
Subject: [xml2rfc] accomodating draft-rfc-editor-rfc2223bis-04.txt
In-Reply-To: <JIEGINCHMLABHJBIGKBCEEFBHBAA.julian.reschke@gmx.de>
References: <20030418103301.014168cb.mrose+internet.xml2rfc@dbc.mtview.ca.us> <JIEGINCHMLABHJBIGKBCEEFBHBAA.julian.reschke@gmx.de>
Message-ID: <20030418120313.031e2ed7.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> > unfortunately, this falls into the "very painful" category, because once
> > you go down the path of allowing markup in <artwork/>, you have to ask
> > yourself which elements to allow, and, inenvitably, you'll get the list
> > wrong.
> 
> I'd say not necessarily if we start with a minimal list.
    
sure, the road to hell always starts with good intentions...

    
> > combine this with the fact that <artwork/> is supposed to preserve
> > linebreaks, and it becomes next to impossible to edit it so that "things
> > line up the way you want".
> 
> It will be a pain, agreed. But in this particular example, lining up isn't
> really important. If you have a figure that requires that things line up,
> either just don't use markup, or accept the penalty in usability.

well, this sort of trade-off adds complexity...
    
    
> > certainly, i've wanted to be able to use <xref/>, <eref/>, and <iref/>
> > inside artwork, but the lining-up problem always stops me from wanting
> > to go down that path.
> >
> > right now, <figure/> allows an anchor= attribute, so if you put abnf in
> > <artwork/> you can reference it elsewhere.
> 
> Yes, but I can only put one *single* anchor there. If an BNF fragment
> defines multiple terms, I'd like to be able to do that. For instance, it
> would be really convenient if I could identify any given BNF term defined in
> a specific RFC by using a well-defined fragment identifier, such as:
> 
> 	rfc2396#bnf.uri-reference
> 
> Right now I can't.

you're thinking about rendering html, not text. if you look at rendering
text, the anchor on a <figure/> gets expanded to "Figure X".
    
what label would get rendered in text mode, e.g., "line Y of Figure X" ?
    
this is the same reason why <t/> doesn't have anchors, there's no
meaningful way to generate a label when rendering text.

/mtr


From: julian.reschke@gmx.de (Julian Reschke)
Date: Fri, 18 Apr 2003 20:39:56 +0200
Subject: [xml2rfc] accomodating draft-rfc-editor-rfc2223bis-04.txt
In-Reply-To: <20030418103301.014168cb.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <JIEGINCHMLABHJBIGKBCEEFBHBAA.julian.reschke@gmx.de>

> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of Marshall Rose
> Sent: Friday, April 18, 2003 7:33 PM
> To: Michael Richardson
> Cc: xml2rfc@lists.xml.resource.org
> Subject: Re: [xml2rfc] accomodating draft-rfc-editor-rfc2223bis-04.txt
>
>
> > Hi,
> >
> > here's another thing I frequently wished was possible.
> >
> > Currently, people use figures and artwork to put in protocol definitions
> > such as BNFs (for instance see [1]). The problem here is that
> the <artwork>
> > doesn't allow any markup inside, so you can't link from/to
> anchors within
> > that figure. However, this would be *extremely* useful, because it would
> > allow you hyperlink between the various protocol definitions.
>
> unfortunately, this falls into the "very painful" category, because once
> you go down the path of allowing markup in <artwork/>, you have to ask
> yourself which elements to allow, and, inenvitably, you'll get the list
> wrong.

I'd say not necessarily if we start with a minimal list.

> combine this with the fact that <artwork/> is supposed to preserve
> linebreaks, and it becomes next to impossible to edit it so that "things
> line up the way you want".

It will be a pain, agreed. But in this particular example, lining up isn't
really important. If you have a figure that requires that things line up,
either just don't use markup, or accept the penalty in usability.

> certainly, i've wanted to be able to use <xref/>, <eref/>, and <iref/>
> inside artwork, but the lining-up problem always stops me from wanting
> to go down that path.
>
> right now, <figure/> allows an anchor= attribute, so if you put abnf in
> <artwork/> you can reference it elsewhere.

Yes, but I can only put one *single* anchor there. If an BNF fragment
defines multiple terms, I'd like to be able to do that. For instance, it
would be really convenient if I could identify any given BNF term defined in
a specific RFC by using a well-defined fragment identifier, such as:

	rfc2396#bnf.uri-reference

Right now I can't.

I guess I'll implement that as an extension (that will need to be stripped
out of the document if it's going to be DTD-validated and/or processed using
xml2rfc).

Julian


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



From: julian.reschke@gmx.de (Julian Reschke)
Date: Fri, 18 Apr 2003 20:31:14 +0200
Subject: [xml2rfc] 1.15 format style list numbering does not reset
In-Reply-To: <20030418101506.094af4f6.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <JIEGINCHMLABHJBIGKBCKEFAHBAA.julian.reschke@gmx.de>

For the record: I agree with all the statements about RFC2629's purpose.

What I don't see is how these statements relate to the following issue:

> > Independantly of that: if RFC2629 is supposed to be a  well-defined
format
> > rather than something which happens to be processed by one specific
> > implementation, it will need to take into account valid  concerns of
other
> > implementors, right?

Marshall's TCL-based implementation is just one of many (at least two). I
have no problem to agree that it's the reference implementation. However,
the *format* should be defined in an implementation-independant way. As
RFC2629 uses XML as base format, it should be as as XML-friendly as
possible. One of the most popular tools to process XML is XSLT, which
happens to be a functional language and thus isn't good in handling things
that depend on a specific execution order.

Resetting counters is problematic for other reasons as well. For instance,
numbering depends on ordering, and ordering can easily break when paragraphs
are moved around. For instance, if you have two lists, where the first has a
"startAt=1", and then move the second list before the first list, the result
almost certainly won't be what you wanted. It's simply a better processing
model to explicitly name what should be counted, for instance:

	<list style="format R%" counter="requirements">

This will also allow to use the same format string for different counters.

BTW: I *am* using XSLT to transform documents to plain text (via nroff/ms,
as suggested by the RFC editor). The stylesheet however isn't well-tested,
so I haven't released it yet. People who want to give it a try please email
me.

Julian

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



From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Fri, 18 Apr 2003 10:33:01 -0700
Subject: [xml2rfc] accomodating draft-rfc-editor-rfc2223bis-04.txt
In-Reply-To: <200304020000.h3200FUK006477@marajade.sandelman.ottawa.on.ca>
References: <20030331161522.3b3e8eef.mrose+internet.xml2rfc@dbc.mtview.ca.us> <200304020000.h3200FUK006477@marajade.sandelman.ottawa.on.ca>
Message-ID: <20030418103301.014168cb.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> Hi,
> 
> here's another thing I frequently wished was possible.
> 
> Currently, people use figures and artwork to put in protocol definitions
> such as BNFs (for instance see [1]). The problem here is that the <artwork>
> doesn't allow any markup inside, so you can't link from/to anchors within
> that figure. However, this would be *extremely* useful, because it would
> allow you hyperlink between the various protocol definitions.
    
unfortunately, this falls into the "very painful" category, because once
you go down the path of allowing markup in <artwork/>, you have to ask
yourself which elements to allow, and, inenvitably, you'll get the list
wrong.
    
combine this with the fact that <artwork/> is supposed to preserve
linebreaks, and it becomes next to impossible to edit it so that "things
line up the way you want".
    
certainly, i've wanted to be able to use <xref/>, <eref/>, and <iref/>
inside artwork, but the lining-up problem always stops me from wanting
to go down that path.
    
right now, <figure/> allows an anchor= attribute, so if you put abnf in
<artwork/> you can reference it elsewhere.

/mtr


From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Fri, 18 Apr 2003 10:15:06 -0700
Subject: [xml2rfc] 1.15 format style list numbering does not reset
In-Reply-To: <JIEGINCHMLABHJBIGKBCGEDNHBAA.julian.reschke@gmx.de>
References: <20030418102643.05024022.henrik@levkowetz.com> <JIEGINCHMLABHJBIGKBCGEDNHBAA.julian.reschke@gmx.de>
Message-ID: <20030418101506.094af4f6.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> Independantly of that: if RFC2629 is supposed to be a well-defined format
> rather than something which happens to be processed by one specific
> implementation, it will need to take into account valid concerns of other
> implementors, right?

of course.
    
fundamentally some things matter more than others.
    
for example, the primary purpose of the format is to render things as
ascii as described by rfc2223, etc.
    
a secondary purpose is to have stuff that is useful for people writing
rfcs.
    
another secondary purpose is to be accessible for people writing rfcs.
    
if we didn't care about those things, rfc2629 would simply tell people
to use docbook...

hence, to the extent that an implementation is doing things above and
beyond that, those have to be considered of less importance...

    
now, with respect to the issue at hand:
    
can someone illuminate a reason to restart a counter to a value other
than "1"?
    
if there is a compelling reason, then i think we need to keep startAt.
    
if there isn't a compelling reason, then perhaps if we all agree that
the matter is closed, then henrik would be willing to change his
documents to use counter= instead of startAt=, and i'll ship him a new
version so he can test it out...
    
/mtr

    


From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Fri, 18 Apr 2003 08:59:24 -0700
Subject: [xml2rfc] xml2rfc v1.18 imminent...
In-Reply-To: <JIEGINCHMLABHJBIGKBCKEDLHBAA.julian.reschke@gmx.de>
References: <20030417175933.3456e190.mrose+internet.xml2rfc@dbc.mtview.ca.us> <JIEGINCHMLABHJBIGKBCKEDLHBAA.julian.reschke@gmx.de>
Message-ID: <20030418085924.18eb7d91.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> 1) OK, would you please add that to the documentation? The one I saw said
> that implementations should support these three values without saying what 2
> of them mean :-)

sure.


> 2) out-of-curiosity: what does "verb" stand for? (If it's for input, why not
> call it "input"?)

verb is short for verbatim, which elderly fans of LaTeX will recognize, e.g.,

	\begin{verbatim}
	...
	\end{verbatim}

or

	Here is an \verb|example|

/mtr


From: henrik@levkowetz.com (Henrik Levkowetz)
Date: Fri, 18 Apr 2003 11:18:11 +0200
Subject: [xml2rfc] 1.15 format style list numbering does not reset
In-Reply-To: <JIEGINCHMLABHJBIGKBCGEDNHBAA.julian.reschke@gmx.de>
References: <20030418102643.05024022.henrik@levkowetz.com> <JIEGINCHMLABHJBIGKBCGEDNHBAA.julian.reschke@gmx.de>
Message-ID: <20030418111811.20d4046b.henrik@levkowetz.com>

On Fri, 18 Apr 2003 10:43:22 +0200, "Julian Reschke" <julian.reschke@gmx.de> wrote:
> > > No, we didn't resolve this. The discussion just died away.
> >
> > The way I remember it, the creator and maintainer of xml2rfc - Marshall -
> > said effectively "Well, we'll do it this way." which is of course his
> > right to do. But I could be wrong. That doesn't resolve the conflicting
> > views, but it does settle the question with respect to xml2rfc.
> 
> Can you point to that message? All I can see is a statement saying that he
> was adding this for testing purposes. It's not mentioned in the latest DTD
> either.

No, the memory of this box doesn't go that far back.

> Independantly of that: if RFC2629 is supposed to be a well-defined format
> rather than something which happens to be processed by one specific
> implementation, it will need to take into account valid concerns of other
> implementors, right?

I guess so, with the caveat that the primary output is text, and the purpose
is production of drafts.

	Henrik

-- 
  A mathematician is a machine for converting coffee into theorems. 
    -- Paul Erdös


From: julian.reschke@gmx.de (Julian Reschke)
Date: Fri, 18 Apr 2003 10:43:22 +0200
Subject: [xml2rfc] 1.15 format style list numbering does not reset
In-Reply-To: <20030418102643.05024022.henrik@levkowetz.com>
Message-ID: <JIEGINCHMLABHJBIGKBCGEDNHBAA.julian.reschke@gmx.de>

> From: Henrik Levkowetz [mailto:henrik@levkowetz.com]
> Sent: Friday, April 18, 2003 10:27 AM
> To: Julian Reschke
> Cc: xml2rfc@lists.xml.resource.org
> Subject: Re: [xml2rfc] 1.15 format style list numbering does not reset
>
>
> ...
>
> ...<snip>...
> > > to other ways of achieving this, but I 1) thought we had this
>  resolved
> > once
> > > before, 2) I have drafts which use this, and would hate to loose
> > > the feature.
> >
> > No, we didn't resolve this. The discussion just died away.
>
> The way I remember it, the creator and maintainer of xml2rfc - Marshall -
> said effectively "Well, we'll do it this way." which is of course his
> right to do. But I could be wrong. That doesn't resolve the conflicting
> views, but it does settle the question with respect to xml2rfc.

Can you point to that message? All I can see is a statement saying that he
was adding this for testing purposes. It's not mentioned in the latest DTD
either.

Independantly of that: if RFC2629 is supposed to be a well-defined format
rather than something which happens to be processed by one specific
implementation, it will need to take into account valid concerns of other
implementors, right?

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



From: henrik@levkowetz.com (Henrik Levkowetz)
Date: Fri, 18 Apr 2003 10:26:43 +0200
Subject: [xml2rfc] 1.15 format style list numbering does not reset
In-Reply-To: <JIEGINCHMLABHJBIGKBCKEDKHBAA.julian.reschke@gmx.de>
References: <20030418011919.7b84308c.henrik@levkowetz.com> <JIEGINCHMLABHJBIGKBCKEDKHBAA.julian.reschke@gmx.de>
Message-ID: <20030418102643.05024022.henrik@levkowetz.com>

On Fri, 18 Apr 2003 09:08:00 +0200, "Julian Reschke" <julian.reschke@gmx.de> wrote:
> > Possibly. If it's really not needed, how do you provide for a choice of
> > both non-resetting and resetting counters?  (I think you're digging a hole
> > for yourself here ,,:-)
> 
> My point being that you don't need "resetting" counters if you can just
> create a new counter. Use case, please.

True. Never disputed this. I could work with either. But so could you, I
suspect; although yes, you've stated clearly that you prefer creating
new counters to resetting an old one.

...<snip>...
> > to other ways of achieving this, but I 1) thought we had this  resolved
> once
> > before, 2) I have drafts which use this, and would hate to loose
> > the feature.
> 
> No, we didn't resolve this. The discussion just died away.

The way I remember it, the creator and maintainer of xml2rfc - Marshall -
said effectively "Well, we'll do it this way." which is of course his
right to do. But I could be wrong. That doesn't resolve the conflicting
views, but it does settle the question with respect to xml2rfc.

	Henrik


From: julian.reschke@gmx.de (Julian Reschke)
Date: Fri, 18 Apr 2003 09:53:15 +0200
Subject: [xml2rfc] non-artwork text in figures
In-Reply-To: <JIEGINCHMLABHJBIGKBCEEDLHBAA.julian.reschke@gmx.de>
Message-ID: <JIEGINCHMLABHJBIGKBCGEDMHBAA.julian.reschke@gmx.de>

Hi,

here's another thing I frequently wished was possible.

Currently, people use figures and artwork to put in protocol definitions
such as BNFs (for instance see [1]). The problem here is that the <artwork>
doesn't allow any markup inside, so you can't link from/to anchors within
that figure. However, this would be *extremely* useful, because it would
allow you hyperlink between the various protocol definitions.

One way to fix this would be to simply allow markup within the artwork
element. So instead of:

<figure><preamble>
<iref item="unreserved" primary="true"/>
<iref item="mark" primary="true"/>
   Data characters that are allowed in a URI but do not have a reserved
   purpose are called unreserved.  These include upper and lower case
   letters, decimal digits, and a limited set of punctuation marks and
   symbols.
<iref item="URI grammar" subitem="unreserved" primary="true"/>
<iref item="URI grammar" subitem="mark" primary="true"/>
</preamble><artwork>
   unreserved  = ALPHA / DIGIT / mark

   mark        = "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")"
</artwork></figure>

one could use:

<figure><preamble>
<iref item="unreserved" primary="true"/>
<iref item="mark" primary="true"/>
   Data characters that are allowed in a URI but do not have a reserved
   purpose are called unreserved.  These include upper and lower case
   letters, decimal digits, and a limited set of punctuation marks and
   symbols.
<iref item="URI grammar" subitem="unreserved" primary="true"/>
<iref item="URI grammar" subitem="mark" primary="true"/>
</preamble><artwork>
   <t anchor="grammar-unreserved">unreserved</t>  = ALPHA / DIGIT / <xref
target="grammar-mark">mark</xref>

   <t anchor="grammar-mark">mark</t>        = "-" / "_" / "." / "!" / "~" /
"*" / "'" / "(" / ")"
</artwork></figure>


This would require the following changes:

- change content model for <artwork> to %TEXT (or add a new element for
that)
- allow <t> to have anchors (that should be a no-brainer)
- possibly a way to instruct <xref> not to add any user-visible text (just
the linking information)


Another use-case that would benefit from that extension is when text in
figures refers to references, such as (see RFC2518,
<http://greenbytes.de/tech/webdav/rfc2518.html#HEADER_Timeout>, section
9.8):

   TimeOut = "Timeout" ":" 1#TimeType
   TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other)
   DAVTimeOutVal = 1*digit
   Other = "Extend" field-value   ; See section 4.2 of [RFC2068]


Feedback appreciated,

Julian


[1]
<http://cvs.apache.org/viewcvs.cgi/*checkout*/ietf-uri/rev-2002/rfc2396bis.h
tml?rev=HEAD&content-type=text/html>

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



From: julian.reschke@gmx.de (Julian Reschke)
Date: Fri, 18 Apr 2003 09:27:39 +0200
Subject: [xml2rfc] xml2rfc v1.18 imminent...
In-Reply-To: <20030417175933.3456e190.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <JIEGINCHMLABHJBIGKBCKEDLHBAA.julian.reschke@gmx.de>

> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of Marshall Rose
> Sent: Friday, April 18, 2003 3:00 AM
> To: Julian Reschke
> Cc: xml2rfc@lists.xml.resource.org
> Subject: Re: [xml2rfc] xml2rfc v1.18 imminent...
>
>
> > Can we get back to the issue which styles are defined and what they mean
> > then?
>
> sure:
>
>    emph: indicates emphasis;
>
>    strong: indicates stronger emphasis; and,
>
>    verb: indicates sample input for programs.

1) OK, would you please add that to the documentation? The one I saw said
that implementations should support these three values without saying what 2
of them mean :-)

2) out-of-curiosity: what does "verb" stand for? (If it's for input, why not
call it "input"?)

Julian

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



From: julian.reschke@gmx.de (Julian Reschke)
Date: Fri, 18 Apr 2003 09:22:57 +0200
Subject: [xml2rfc] xml2rfc v1.18 imminent...
In-Reply-To: <20030417174557.4923ea55.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <JIEGINCHMLABHJBIGKBCEEDLHBAA.julian.reschke@gmx.de>

> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of Marshall Rose
> Sent: Friday, April 18, 2003 2:46 AM
> To: Henrik Levkowetz
> Cc: xml2rfc@lists.xml.resource.org
> Subject: Re: [xml2rfc] xml2rfc v1.18 imminent...
>
>
> > One possible solution, although not particularly elegant, would
> be to use the
> > name of a section in the <xref /> generation if no section number was
> > available:
> >
> >   ... see <xref target="security.cons" /> ...
> >
> > which renders as
> >
> >   ... see "Security Considerations" ...
>
> which is a good hack, providing that it's unambiguous (e.g., two
> subsections with the same name).
>
> but, this may be the best solution.

Hm.

So what's the algorithm to compute section numbers then?

- /middle/section are numbered when appearing before an appendix element
(digits)
- /middle/appendix are numbered (letters)
- /middle/section are un-numbered when appearing after an appendix element
(digits)
- /back/section are not numbered (?)

I'd like to have this distinction well-defined, and possibly more easy to
detect during processing. Doing checks on previous appendix elements is
surely possible, but wouldn't it be much much easier to assign a new element
name, such as:

	<!ELEMENT middle      (section+, appendix*, unnumbered-section*)>

?

Julian

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



From: julian.reschke@gmx.de (Julian Reschke)
Date: Fri, 18 Apr 2003 09:08:00 +0200
Subject: [xml2rfc] 1.15 format style list numbering does not reset
In-Reply-To: <20030418011919.7b84308c.henrik@levkowetz.com>
Message-ID: <JIEGINCHMLABHJBIGKBCKEDKHBAA.julian.reschke@gmx.de>

> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of Henrik
> Levkowetz
> Sent: Friday, April 18, 2003 1:19 AM
> Cc: mrose+internet.xml2rfc@dbc.mtview.ca.us; julian.reschke@gmx.de;
> xml2rfc@lists.xml.resource.org
> Subject: Re: [xml2rfc] 1.15 format style list numbering does not reset
>
>
> ...
>
> > However I think that this design (startAt attribute) really makes
processing
> > very unclear. I wrote:
>
> Disagree.
>
> > "So what does that mean if a document contains lists with and without
> > startAt? Where should the counter start for a list where "startAt" is
> > missing, but there was a previous list where startAt was specified?"
> >
> > From your reply:
> >
> > ----
> > The way I've understood it, <list> elements with style "format ....."
has
> > one counter per unique format string, and this counter is not  reset
between
> > <list> invocations, by default.
> >
> > The startAt attribute would not change the incrementation
characteristics
> > for the counter, only change the current value. So
> >
> >     <list style="format [%d]">
> >        <t>Able</t>
> >        <t>Baker</t>
> >     </list>
> >
> >     <list startAt="1" style="format [%d]">
> >        <t>Charlie</t>
> >        <t>Delta</t>
> >     </list>
> >
> >     <list style="format [%d]">
> >        <t>Echo</t>
> >        <t>Foxtrot</t>
> >     </list>
> >
> > produces:
> >
> >    [1] Able
> >
> >    [2] Baker
> >
> >    [1] Charlie
> >
> >    [2] Delta
> >
> >    [3] Echo
> >
> >    [4] Foxtrot
> > ----
> >
> > This has the problem that it introduces state where it's really  not
needed.
> > I'd call that bad design, at least in a document format.
>
> Possibly. If it's really not needed, how do you provide for a choice of
> both non-resetting and resetting counters?  (I think you're digging a hole
> for yourself here ,,:-)

My point being that you don't need "resetting" counters if you can just
create a new counter. Use case, please.

> > Having explicit counters would make the whole thing more robust
("startAt"
> > may be required to set an initial value for a counter, but using it to
> > "reset" a counter definitively is a bad idea, and I'll likely not be
able to
> > implement that in XSLT).
>
> Meaning you haven't been able to implement the current behaviour?  Oh,
well,
> I'm sorry about that, but the end of it, as far as I'm concerned, is that
> I have a real nead for format style lists with the same format which are
> reset for each new list, instead of continuing to count up. I'm not
adverse

Well, that's no problem. I made a proposal that enables you to do that
without introducing unnecessary state.

> to other ways of achieving this, but I 1) thought we had this  resolved
once
> before, 2) I have drafts which use this, and would hate to loose
> the feature.

No, we didn't resolve this. The discussion just died away.

Julian

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



From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Thu, 17 Apr 2003 17:59:33 -0700
Subject: [xml2rfc] xml2rfc v1.18 imminent...
In-Reply-To: <JIEGINCHMLABHJBIGKBCGECEHBAA.julian.reschke@gmx.de>
References: <20030417100031.50d3021a.mrose+internet.xml2rfc@dbc.mtview.ca.us> <JIEGINCHMLABHJBIGKBCGECEHBAA.julian.reschke@gmx.de>
Message-ID: <20030417175933.3456e190.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> Can we get back to the issue which styles are defined and what they mean
> then?

sure:
    
   emph: indicates emphasis;

   strong: indicates stronger emphasis; and,

   verb: indicates sample input for programs.

/mtr


From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Thu, 17 Apr 2003 17:45:57 -0700
Subject: [xml2rfc] xml2rfc v1.18 imminent...
In-Reply-To: <20030418010333.56956277.henrik@levkowetz.com>
References: <20030416150021.3f00af70.mrose+internet.xml2rfc@dbc.mtview.ca.us> <5.1.0.14.2.20030416235657.00b78330@127.0.0.1> <20030417090925.3d180187.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20030417184620.38d25ea5.henrik@levkowetz.com> <20030417100403.12ca3297.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20030418010333.56956277.henrik@levkowetz.com>
Message-ID: <20030417174557.4923ea55.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> One possible solution, although not particularly elegant, would be to use the
> name of a section in the <xref /> generation if no section number was
> available:
> 
>   ... see <xref target="security.cons" /> ...
>
> which renders as
>    
>   ... see "Security Considerations" ...

which is a good hack, providing that it's unambiguous (e.g., two
subsections with the same name).
    
but, this may be the best solution.
    
/mtr
    


From: henrik@levkowetz.com (Henrik Levkowetz)
Date: Fri, 18 Apr 2003 01:19:19 +0200
Subject: [xml2rfc] 1.15 format style list numbering does not reset
In-Reply-To: <JIEGINCHMLABHJBIGKBCKECDHBAA.julian.reschke@gmx.de>
References: <20030417185452.3d547c63.henrik@levkowetz.com> <JIEGINCHMLABHJBIGKBCKECDHBAA.julian.reschke@gmx.de>
Message-ID: <20030418011919.7b84308c.henrik@levkowetz.com>

On Thu, 17 Apr 2003 19:09:38 +0200, "Julian Reschke" <julian.reschke@gmx.de> wrote:
> > Replace the name of the counter in your proposed resolution with a
> > suitably transformed or hashed version of the format string, and the
> > current version and your proposal have the same characteristics and can
> > be implemented in the same way.
> 
> Unless you want the same format string, but different counters, right?

Yes, but nobody has asked for that.

> > I.e., it should be possible to implement the two in the same way
> > exactly, as long as it's possible to hash or transform the format string
> > to something which can be used as a global variable name.
> 
> I agree that this in particular isn't a problem.

Ok, good.

> However I think that this design (startAt attribute) really makes processing
> very unclear. I wrote:

Disagree.

> "So what does that mean if a document contains lists with and without
> startAt? Where should the counter start for a list where "startAt" is
> missing, but there was a previous list where startAt was specified?"
> 
> From your reply:
> 
> ----
> The way I've understood it, <list> elements with style "format ....." has
> one counter per unique format string, and this counter is not reset between
> <list> invocations, by default.
> 
> The startAt attribute would not change the incrementation characteristics
> for the counter, only change the current value. So
> 
>     <list style="format [%d]">
>        <t>Able</t>
>        <t>Baker</t>
>     </list>
> 
>     <list startAt="1" style="format [%d]">
>        <t>Charlie</t>
>        <t>Delta</t>
>     </list>
> 
>     <list style="format [%d]">
>        <t>Echo</t>
>        <t>Foxtrot</t>
>     </list>
> 
> produces:
> 
>    [1] Able
> 
>    [2] Baker
> 
>    [1] Charlie
> 
>    [2] Delta
> 
>    [3] Echo
> 
>    [4] Foxtrot
> ----
> 
> This has the problem that it introduces state where it's really not needed.
> I'd call that bad design, at least in a document format.

Possibly. If it's really not needed, how do you provide for a choice of 
both non-resetting and resetting counters?  (I think you're digging a hole
for yourself here ,,:-)

> Having explicit counters would make the whole thing more robust ("startAt"
> may be required to set an initial value for a counter, but using it to
> "reset" a counter definitively is a bad idea, and I'll likely not be able to
> implement that in XSLT).

Meaning you haven't been able to implement the current behaviour? Oh, well,
I'm sorry about that, but the end of it, as far as I'm concerned, is that
I have a real nead for format style lists with the same format which are
reset for each new list, instead of continuing to count up. I'm not adverse
to other ways of achieving this, but I 1) thought we had this resolved once
before, 2) I have drafts which use this, and would hate to loose the feature.


	Henrik

-- 
  "All's fair in love and war" -- what a contemptible lie. 


From: henrik@levkowetz.com (Henrik Levkowetz)
Date: Fri, 18 Apr 2003 01:03:33 +0200
Subject: [xml2rfc] xml2rfc v1.18 imminent...
In-Reply-To: <20030417100403.12ca3297.mrose+internet.xml2rfc@dbc.mtview.ca.us>
References: <20030416150021.3f00af70.mrose+internet.xml2rfc@dbc.mtview.ca.us> <5.1.0.14.2.20030416235657.00b78330@127.0.0.1> <20030417090925.3d180187.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20030417184620.38d25ea5.henrik@levkowetz.com> <20030417100403.12ca3297.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <20030418010333.56956277.henrik@levkowetz.com>

On Thu, 17 Apr 2003 10:04:03 -0700, Marshall Rose <mrose+internet.xml2rfc@dbc.mtview.ca.us> wrote:
> 
> > I could live with this.  But however it is solved, I think it would be
> > good to have an attribute which explicitly would turn on or off numbering
> > for a section. (And following 2. above, would limit that section to not
> > having subsections).
> 
> time for the other shoe to drop:
> 
>     the problem with having un-numbered sections is when you've got an
>     <xref/> referring to it and you're generating text
>     
> in other words, un-numbered sections are problematic...

Agreed.

One possible solution, although not particularly elegant, would be to use the name
of a section in the <xref /> generation if no section number was available:

  ... for a discussion of possible threaths, see <xref target="security.cons" />...
which renders as
  ... for a discussion of possible threaths, see Section "Security Considerations" ...


	Henrik


From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Thu, 17 Apr 2003 11:35:29 -0700
Subject: [xml2rfc] 1.15 format style list numbering does not reset
In-Reply-To: <JIEGINCHMLABHJBIGKBCEECIHBAA.julian.reschke@gmx.de>
References: <20030417110319.18a82767.mrose+internet.xml2rfc@dbc.mtview.ca.us> <JIEGINCHMLABHJBIGKBCEECIHBAA.julian.reschke@gmx.de>
Message-ID: <20030417113529.676f2f6e.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> I was under the impression that continous numbering for the "fornat" style
> wasn't properly specified. Looking at the last release, it is (if you count
> examples) :-).

thanks.

    
> So back to startAt, which *is* new and experimental. My main problem here is
> that processing this gets ridiculous complicated when you try that from a
> functional programming language such as XSLT. That's why I made the
> "counter" suggestion.
> 
> Maybe we can combine both approaches.
> 
> In the absence of explicit counters, all list items with the same "format"
> style have an implicit global counter. This takes care of existing usage.

sure, we can say that the value of the counter attribute defaults to the
format style, e.g.,
    
    <list style='format R%d:'>
    
is identical to
    
    <list style='format R%d:' counter='R%d:'>
    
    
> *If* a counter attribute is present, it defines a global counter. This
> should take care of the requirement of being able to restart a specific
> format at 1.
> 
> Do we really have a requirement to reset the counter to anything != 1?  If
> not, we're done.

well, that's the question. anyone have an answer?
    
/mtr


From: julian.reschke@gmx.de (Julian Reschke)
Date: Thu, 17 Apr 2003 20:15:54 +0200
Subject: [xml2rfc] 1.15 format style list numbering does not reset
In-Reply-To: <20030417110319.18a82767.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <JIEGINCHMLABHJBIGKBCEECIHBAA.julian.reschke@gmx.de>

> -----Original Message-----
> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of Marshall Rose
> Sent: Thursday, April 17, 2003 8:03 PM
> To: Julian Reschke
> Cc: xml2rfc@lists.xml.resource.org
> Subject: Re: [xml2rfc] 1.15 format style list numbering does not reset
>
>
> > Well, are we making design decisions based on the current
> behaviour of an
> > experimental feature that (as far as I remember) never was specificied
> > precisely? I hope not.
>
> we're not talking about
>
>     startAt
>
> we're talking about
>
>     style="format R%d"
>
> and that is neither experimental, nor poorly-specified.

Sorry.

I was under the impression that continous numbering for the "fornat" style
wasn't properly specified. Looking at the last release, it is (if you count
examples) :-).

So back to startAt, which *is* new and experimental. My main problem here is
that processing this gets ridiculous complicated when you try that from a
functional programming language such as XSLT. That's why I made the
"counter" suggestion.

Maybe we can combine both approaches.

In the absence of explicit counters, all list items with the same "format"
style have an implicit global counter. This takes care of existing usage.

*If* a counter attribute is present, it defines a global counter. This
should take care of the requirement of being able to restart a specific
format at 1.

Do we really have a requirement to reset the counter to anything != 1?  If
not, we're done.

Julian

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



From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Thu, 17 Apr 2003 11:03:19 -0700
Subject: [xml2rfc] 1.15 format style list numbering does not reset
In-Reply-To: <JIEGINCHMLABHJBIGKBCKECEHBAA.julian.reschke@gmx.de>
References: <20030417100710.4fed562f.mrose+internet.xml2rfc@dbc.mtview.ca.us> <JIEGINCHMLABHJBIGKBCKECEHBAA.julian.reschke@gmx.de>
Message-ID: <20030417110319.18a82767.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> Well, are we making design decisions based on the current behaviour of an
> experimental feature that (as far as I remember) never was specificied
> precisely? I hope not.

we're not talking about
    
    startAt
    
we're talking about
    
    style="format R%d"
    
and that is neither experimental, nor poorly-specified.
    
/mtr


From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Thu, 17 Apr 2003 10:31:36 -0700
Subject: [xml2rfc] xml2rfc v1.18 imminent...
In-Reply-To: <20030417171636.GX2000@sbrim-w2k>
References: <20030416150021.3f00af70.mrose+internet.xml2rfc@dbc.mtview.ca.us> <5.1.0.14.2.20030416235657.00b78330@127.0.0.1> <20030417090925.3d180187.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20030417184620.38d25ea5.henrik@levkowetz.com> <20030417100403.12ca3297.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20030417171636.GX2000@sbrim-w2k>
Message-ID: <20030417103136.4c923e08.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> On Thu, Apr 17, 2003 10:04:03AM -0700, Marshall Rose allegedly wrote:
> > time for the other shoe to drop:
> > 
> >     the problem with having un-numbered sections is when you've got an
> >     <xref/> referring to it and you're generating text
> >     
> > in other words, un-numbered sections are problematic...
> 
> The unnumbered sections we have, such as References and IPR boilerplate
> certainly don't need to have subsections, or xrefs to them.  Appendices
> can (must) have identifiers, which can be just letters.

i agree. although from the 2629 perspective, References and IPR aren't sections.

the problem comes down to the "*Considerations" sections which the rfc editor
likes to:

	1. put after appendices
	2. not number them

and that works great right until:

	- there's a subsection, or
	- you try to xref them and render text

/mtr


From: swb@employees.org (Scott W Brim)
Date: Thu, 17 Apr 2003 13:16:36 -0400
Subject: [xml2rfc] xml2rfc v1.18 imminent...
In-Reply-To: <20030417100403.12ca3297.mrose+internet.xml2rfc@dbc.mtview.ca.us>
References: <20030416150021.3f00af70.mrose+internet.xml2rfc@dbc.mtview.ca.us> <5.1.0.14.2.20030416235657.00b78330@127.0.0.1> <20030417090925.3d180187.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20030417184620.38d25ea5.henrik@levkowetz.com> <20030417100403.12ca3297.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <20030417171636.GX2000@sbrim-w2k>

On Thu, Apr 17, 2003 10:04:03AM -0700, Marshall Rose allegedly wrote:
> time for the other shoe to drop:
> 
>     the problem with having un-numbered sections is when you've got an
>     <xref/> referring to it and you're generating text
>     
> in other words, un-numbered sections are problematic...

The unnumbered sections we have, such as References and IPR boilerplate
certainly don't need to have subsections, or xrefs to them.  Appendices
can (must) have identifiers, which can be just letters.



From: julian.reschke@gmx.de (Julian Reschke)
Date: Thu, 17 Apr 2003 19:13:01 +0200
Subject: [xml2rfc] 1.15 format style list numbering does not reset
In-Reply-To: <20030417100710.4fed562f.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <JIEGINCHMLABHJBIGKBCKECEHBAA.julian.reschke@gmx.de>

> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of Marshall Rose
> Sent: Thursday, April 17, 2003 7:07 PM
> To: Julian Reschke
> Cc: xml2rfc@lists.xml.resource.org
> Subject: Re: [xml2rfc] 1.15 format style list numbering does not reset
>
>
> > And my proposed resolution is here:
> >
> <http://lists.xml.resource.org/pipermail/xml2rfc/2003-February/000
> 455.html>
>
> and the problem in doing
>
>     1) list counters are local and start with 1, unless:
>
>     2) there's a "counter" attribute on the list that identifies a
>     global counter variable.
>
>     So the code for the original requirement (global counter of
>     requirements) would be written as:
>
>     <list style="format R%d" counter="requirements">
>
> but that breaks the way people have been using
>
>     style="format R%d"
>
> for the last year...
>
> as kludgy as it may seem, startAt has the advantag of not breaking
> anything...

Well, are we making design decisions based on the current behaviour of an
experimental feature that (as far as I remember) never was specificied
precisely? I hope not.

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



From: julian.reschke@gmx.de (Julian Reschke)
Date: Thu, 17 Apr 2003 19:10:51 +0200
Subject: [xml2rfc] xml2rfc v1.18 imminent...
In-Reply-To: <20030417100031.50d3021a.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <JIEGINCHMLABHJBIGKBCGECEHBAA.julian.reschke@gmx.de>

> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of Marshall Rose
> Sent: Thursday, April 17, 2003 7:01 PM
> To: Julian Reschke
> Cc: xml2rfc@lists.xml.resource.org
> Subject: Re: [xml2rfc] xml2rfc v1.18 imminent...
>
>
> julian - let me explain my thinking:
>
>     2629bis will neer define an element whose name is the same as an
>     element in html
>
> that's why you see <t/> instead of <p/>, etc., etc.
>
> ...

That's fine.

Can we get back to the issue which styles are defined and what they mean
then?

:-)


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



From: julian.reschke@gmx.de (Julian Reschke)
Date: Thu, 17 Apr 2003 19:09:38 +0200
Subject: [xml2rfc] 1.15 format style list numbering does not reset
In-Reply-To: <20030417185452.3d547c63.henrik@levkowetz.com>
Message-ID: <JIEGINCHMLABHJBIGKBCKECDHBAA.julian.reschke@gmx.de>

> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of Henrik
> Levkowetz
> Sent: Thursday, April 17, 2003 6:55 PM
> Cc: mrose+internet.xml2rfc@dbc.mtview.ca.us; julian.reschke@gmx.de;
> xml2rfc@lists.xml.resource.org
> Subject: Re: [xml2rfc] 1.15 format style list numbering does not reset
>
>
> On Thu, 17 Apr 2003 18:34:03 +0200, "Julian Reschke"
> <julian.reschke@gmx.de> wrote:
> > I think a *change* is required.
> >
> > The problem was stated here:
> >
> <http://lists.xml.resource.org/pipermail/xml2rfc/2003-February/000
> 451.html>
> >
> > And my proposed resolution is here:
> >
> <http://lists.xml.resource.org/pipermail/xml2rfc/2003-February/000
> 455.html>
>
> Replace the name of the counter in your proposed resolution with a
> suitably transformed or hashed version of the format string, and the
> current version and your proposal have the same characteristics and can
> be implemented in the same way.

Unless you want the same format string, but different counters, right?

> I.e., it should be possible to implement the two in the same way
> exactly, as long as it's possible to hash or transform the format string
> to something which can be used as a global variable name.

I agree that this in particular isn't a problem.

However I think that this design (startAt attribute) really makes processing
very unclear. I wrote:

"So what does that mean if a document contains lists with and without
startAt? Where should the counter start for a list where "startAt" is
missing, but there was a previous list where startAt was specified?"

>From your reply:

----
The way I've understood it, <list> elements with style "format ....." has
one counter per unique format string, and this counter is not reset between
<list> invocations, by default.

The startAt attribute would not change the incrementation characteristics
for the counter, only change the current value. So

    <list style="format [%d]">
       <t>Able</t>
       <t>Baker</t>
    </list>

    <list startAt="1" style="format [%d]">
       <t>Charlie</t>
       <t>Delta</t>
    </list>

    <list style="format [%d]">
       <t>Echo</t>
       <t>Foxtrot</t>
    </list>

produces:

   [1] Able

   [2] Baker

   [1] Charlie

   [2] Delta

   [3] Echo

   [4] Foxtrot
----

This has the problem that it introduces state where it's really not needed.
I'd call that bad design, at least in a document format.

Having explicit counters would make the whole thing more robust ("startAt"
may be required to set an initial value for a counter, but using it to
"reset" a counter definitively is a bad idea, and I'll likely not be able to
implement that in XSLT).

Julian


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



From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Thu, 17 Apr 2003 10:07:10 -0700
Subject: [xml2rfc] 1.15 format style list numbering does not reset
In-Reply-To: <JIEGINCHMLABHJBIGKBCCECAHBAA.julian.reschke@gmx.de>
References: <20030417092529.149459de.mrose+internet.xml2rfc@dbc.mtview.ca.us> <JIEGINCHMLABHJBIGKBCCECAHBAA.julian.reschke@gmx.de>
Message-ID: <20030417100710.4fed562f.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> And my proposed resolution is here:
> <http://lists.xml.resource.org/pipermail/xml2rfc/2003-February/000455.html>

and the problem in doing
    
    1) list counters are local and start with 1, unless:

    2) there's a "counter" attribute on the list that identifies a
    global counter variable.

    So the code for the original requirement (global counter of
    requirements) would be written as:

    <list style="format R%d" counter="requirements">
    
but that breaks the way people have been using 
    
    style="format R%d"
    
for the last year...
    
as kludgy as it may seem, startAt has the advantag of not breaking
anything...
    
/mtr


From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Thu, 17 Apr 2003 10:04:03 -0700
Subject: [xml2rfc] xml2rfc v1.18 imminent...
In-Reply-To: <20030417184620.38d25ea5.henrik@levkowetz.com>
References: <20030416150021.3f00af70.mrose+internet.xml2rfc@dbc.mtview.ca.us> <5.1.0.14.2.20030416235657.00b78330@127.0.0.1> <20030417090925.3d180187.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20030417184620.38d25ea5.henrik@levkowetz.com>
Message-ID: <20030417100403.12ca3297.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> I could live with this.  But however it is solved, I think it would be
> good to have an attribute which explicitly would turn on or off numbering
> for a section. (And following 2. above, would limit that section to not
> having subsections).

time for the other shoe to drop:

    the problem with having un-numbered sections is when you've got an
    <xref/> referring to it and you're generating text
    
in other words, un-numbered sections are problematic...

/mtr


From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Thu, 17 Apr 2003 10:00:31 -0700
Subject: [xml2rfc] xml2rfc v1.18 imminent...
In-Reply-To: <JIEGINCHMLABHJBIGKBCIECAHBAA.julian.reschke@gmx.de>
References: <20030417092829.38735843.mrose+internet.xml2rfc@dbc.mtview.ca.us> <JIEGINCHMLABHJBIGKBCIECAHBAA.julian.reschke@gmx.de>
Message-ID: <20030417100031.50d3021a.mrose+internet.xml2rfc@dbc.mtview.ca.us>

julian - let me explain my thinking:

    2629bis will neer define an element whose name is the same as an
    element in html
    
that's why you see <t/> instead of <p/>, etc., etc.
    
the reason is that once you say something like <table/>, then folks are
going to assume that it's just like like <table/>, and it doesn't matter
how loudly we yell at them, they won't figure it out.
    
rfc2629bis will never cite html documents, for the same reason.
    
the problem with enumerating the list of 10 or so possibilities, is that
there are two many of them. if you want definitions for the three, fine,
we can do that.
    
at this point in the lifecycle, diminishing returns is a very serious
concern. accordingly, the more complicated "changes" are, the less
likely they get a hearing.
    
/mtr


From: henrik@levkowetz.com (Henrik Levkowetz)
Date: Thu, 17 Apr 2003 18:54:52 +0200
Subject: [xml2rfc] 1.15 format style list numbering does not reset
In-Reply-To: <JIEGINCHMLABHJBIGKBCCECAHBAA.julian.reschke@gmx.de>
References: <20030417092529.149459de.mrose+internet.xml2rfc@dbc.mtview.ca.us> <JIEGINCHMLABHJBIGKBCCECAHBAA.julian.reschke@gmx.de>
Message-ID: <20030417185452.3d547c63.henrik@levkowetz.com>

On Thu, 17 Apr 2003 18:34:03 +0200, "Julian Reschke" <julian.reschke@gmx.de> wrote:
> I think a *change* is required.
> 
> The problem was stated here:
> <http://lists.xml.resource.org/pipermail/xml2rfc/2003-February/000451.html>
> 
> And my proposed resolution is here:
> <http://lists.xml.resource.org/pipermail/xml2rfc/2003-February/000455.html>

Replace the name of the counter in your proposed resolution with a
suitably transformed or hashed version of the format string, and the
current version and your proposal have the same characteristics and can
be implemented in the same way.

I.e., it should be possible to implement the two in the same way
exactly, as long as it's possible to hash or transform the format string
to something which can be used as a global variable name.

	Henrik

-- 
  Being generous is inborn; being altruistic is a learned perversity. No
  resemblance -- 


From: henrik@levkowetz.com (Henrik Levkowetz)
Date: Thu, 17 Apr 2003 18:46:20 +0200
Subject: [xml2rfc] xml2rfc v1.18 imminent...
In-Reply-To: <20030417090925.3d180187.mrose+internet.xml2rfc@dbc.mtview.ca.us>
References: <20030416150021.3f00af70.mrose+internet.xml2rfc@dbc.mtview.ca.us> <5.1.0.14.2.20030416235657.00b78330@127.0.0.1> <20030417090925.3d180187.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <20030417184620.38d25ea5.henrik@levkowetz.com>

On Thu, 17 Apr 2003 09:09:25 -0700, Marshall Rose <mrose+internet.xml2rfc@dbc.mtview.ca.us> wrote:
> 
> the issue with the numbering is a derivative of this situation. sure, not
> numbering things like "*Considerations" is fine, right until you have
> subsections. when you have to write code that implements these rules, this kind
> of gap in the input domain becomes obvious. perhaps the obvious thing is to do
> this:
> 
> 	1. sections which appear after appendices are unnumbered
> 	2. sections which appear after appendices may not have subsections

I could live with this.  But however it is solved, I think it would be
good to have an attribute which explicitly would turn on or off numbering
for a section. (And following 2. above, would limit that section to not
having subsections).

	Henrik

-- 
Error message in Haiku form:

  With searching comes loss
  and the presence of absence:
  "My Novel" not found.

    -- Howard Korder 


From: julian.reschke@gmx.de (Julian Reschke)
Date: Thu, 17 Apr 2003 18:42:10 +0200
Subject: [xml2rfc] 1.15 format style list numbering does not reset
In-Reply-To: <20030417183549.7a3d3b95.henrik@levkowetz.com>
Message-ID: <JIEGINCHMLABHJBIGKBCKECBHBAA.julian.reschke@gmx.de>

> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of Henrik
> Levkowetz
> Sent: Thursday, April 17, 2003 6:36 PM
> To: Marshall Rose
> Cc: xml2rfc@lists.xml.resource.org
> Subject: Re: [xml2rfc] 1.15 format style list numbering does not reset
>
>
> On Thu, 17 Apr 2003 09:25:29 -0700, Marshall Rose
> <mrose+internet.xml2rfc@dbc.mtview.ca.us> wrote:
> > > Hi all,
> > >
> > > I really think it would be good if we could get a consensus
> about how the
> > > "extended list numbering" is supposed to work. The current
> implementation
> > > IMHO
> > >
> > > - either needs to be specified precisely or
> > > - we should settle with an easier to understand/implement
> numbering model
> >
> > i thought the resolution was that we were adding an optional "startAt"
> > attribute to the <list/> element:
> >
> >     By default, auto-formatted lists start numbering at 1.  However,
> >     the value may be changed by using the optional 'startAt' attribute.
>
> Yes, this was my understanding, too.

I don't think that my concerns were addressed at all. The proposal I made
(IMHO) makes the markup easier to read, more robust against cut-and-paste,
and easier to process.

Julian

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



From: julian.reschke@gmx.de (Julian Reschke)
Date: Thu, 17 Apr 2003 18:37:57 +0200
Subject: [xml2rfc] xml2rfc v1.18 imminent...
In-Reply-To: <20030417092829.38735843.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <JIEGINCHMLABHJBIGKBCIECAHBAA.julian.reschke@gmx.de>

> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of Marshall Rose
> Sent: Thursday, April 17, 2003 6:28 PM
> To: Julian Reschke
> Cc: xml2rfc@lists.xml.resource.org
> Subject: Re: [xml2rfc] xml2rfc v1.18 imminent...
>
>
> > I think it's less-than clear what for instance "verb" means unless we
> > specify it. Why not just stick with
> >
> > http://www.w3.org/TR/html4/struct/text.html#h-9.2
>
> the problem of course is that this text is html-centric.

Partly. I'd just like to understand why the following terms:

"EM:
Indicates emphasis.
STRONG:
Indicates stronger emphasis.
CITE:
Contains a citation or a reference to other sources.
DFN:
Indicates that this is the defining instance of the enclosed term.
CODE:
Designates a fragment of computer code.
SAMP:
Designates sample output from programs, scripts, etc.
KBD:
Indicates text to be entered by the user.
VAR:
Indicates an instance of a variable or program argument.
ABBR:
Indicates an abbreviated form (e.g., WWW, HTTP, URI, Mass., etc.).
ACRONYM:
Indicates an acronym (e.g., WAC, radar, etc.). "

can't be re-used (or a subset).

Basically, we need to decide what the authorative source of information of
RFC2629-XML is. If it's the spec (and I think this should be the case), it
should list all values that are mandatory, and what they are supposed to
mean.

> let's recall that it is not a goal of 2629 to require that all  processors
render
> output in exactly the same way.

No, but it shouldn't by trial-and-error either.

So what does "verb" mean?


> if you're rendering text, it should conform to 2223 (which gives a fair
> amount of leeway).

Well, when rendering plain text, I don't see how any of these can be
supported...

> if you're rendering html, you really don't need two different  processors
to
> generate the same output, bit for bit, do you?

Nope.


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



From: henrik@levkowetz.com (Henrik Levkowetz)
Date: Thu, 17 Apr 2003 18:35:49 +0200
Subject: [xml2rfc] 1.15 format style list numbering does not reset
In-Reply-To: <20030417092529.149459de.mrose+internet.xml2rfc@dbc.mtview.ca.us>
References: <JIEGINCHMLABHJBIGKBCCEALHBAA.julian.reschke@gmx.de> <JIEGINCHMLABHJBIGKBCGEAMHBAA.julian.reschke@gmx.de> <20030417092529.149459de.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <20030417183549.7a3d3b95.henrik@levkowetz.com>

On Thu, 17 Apr 2003 09:25:29 -0700, Marshall Rose <mrose+internet.xml2rfc@dbc.mtview.ca.us> wrote:
> > Hi all,
> > 
> > I really think it would be good if we could get a consensus about how the
> > "extended list numbering" is supposed to work. The current implementation
> > IMHO
> > 
> > - either needs to be specified precisely or
> > - we should settle with an easier to understand/implement numbering model
> 
> i thought the resolution was that we were adding an optional "startAt"
> attribute to the <list/> element:
>     
>     By default, auto-formatted lists start numbering at 1.  However,
>     the value may be changed by using the optional 'startAt' attribute.

Yes, this was my understanding, too.

	Henrik

-- 
  I intend to live forever, or die trying. 
    -- Groucho Marx


From: julian.reschke@gmx.de (Julian Reschke)
Date: Thu, 17 Apr 2003 18:34:03 +0200
Subject: [xml2rfc] 1.15 format style list numbering does not reset
In-Reply-To: <20030417092529.149459de.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <JIEGINCHMLABHJBIGKBCCECAHBAA.julian.reschke@gmx.de>

> From: Marshall Rose [mailto:mrose+internet.xml2rfc@dbc.mtview.ca.us]
> Sent: Thursday, April 17, 2003 6:25 PM
> To: Julian Reschke
> Cc: xml2rfc@lists.xml.resource.org
> Subject: Re: [xml2rfc] 1.15 format style list numbering does not reset
>
>
> > Hi all,
> >
> > I really think it would be good if we could get a consensus
> about how the
> > "extended list numbering" is supposed to work. The current
> implementation
> > IMHO
> >
> > - either needs to be specified precisely or
> > - we should settle with an easier to understand/implement
> numbering model
>
> i thought the resolution was that we were adding an optional "startAt"
> attribute to the <list/> element:
>
>     By default, auto-formatted lists start numbering at 1.  However,
>     the value may be changed by using the optional 'startAt' attribute.
>
> is additional text required?

I think a *change* is required.

The problem was stated here:
<http://lists.xml.resource.org/pipermail/xml2rfc/2003-February/000451.html>

And my proposed resolution is here:
<http://lists.xml.resource.org/pipermail/xml2rfc/2003-February/000455.html>

Julian

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



From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Thu, 17 Apr 2003 09:28:29 -0700
Subject: [xml2rfc] xml2rfc v1.18 imminent...
In-Reply-To: <JIEGINCHMLABHJBIGKBCIEBOHBAA.julian.reschke@gmx.de>
References: <20030417091309.2c35d636.mrose+internet.xml2rfc@dbc.mtview.ca.us> <JIEGINCHMLABHJBIGKBCIEBOHBAA.julian.reschke@gmx.de>
Message-ID: <20030417092829.38735843.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> I think it's less-than clear what for instance "verb" means unless we
> specify it. Why not just stick with
> 
> http://www.w3.org/TR/html4/struct/text.html#h-9.2

the problem of course is that this text is html-centric. 

let's recall that it is not a goal of 2629 to require that all processors render
output in exactly the same way.

if you're rendering text, it should conform to 2223 (which gives a fair
amount of leeway). 

if you're rendering html, you really don't need two different processors to
generate the same output, bit for bit, do you?

/mtr


From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Thu, 17 Apr 2003 09:25:29 -0700
Subject: [xml2rfc] 1.15 format style list numbering does not reset
In-Reply-To: <JIEGINCHMLABHJBIGKBCGEAMHBAA.julian.reschke@gmx.de>
References: <JIEGINCHMLABHJBIGKBCCEALHBAA.julian.reschke@gmx.de> <JIEGINCHMLABHJBIGKBCGEAMHBAA.julian.reschke@gmx.de>
Message-ID: <20030417092529.149459de.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> Hi all,
> 
> I really think it would be good if we could get a consensus about how the
> "extended list numbering" is supposed to work. The current implementation
> IMHO
> 
> - either needs to be specified precisely or
> - we should settle with an easier to understand/implement numbering model

i thought the resolution was that we were adding an optional "startAt"
attribute to the <list/> element:
    
    By default, auto-formatted lists start numbering at 1.  However,
    the value may be changed by using the optional 'startAt' attribute.
    
is additional text required?
    
/mtr



From: julian.reschke@gmx.de (Julian Reschke)
Date: Thu, 17 Apr 2003 18:25:18 +0200
Subject: [xml2rfc] xml2rfc v1.18 imminent...
In-Reply-To: <20030417091309.2c35d636.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <JIEGINCHMLABHJBIGKBCIEBOHBAA.julian.reschke@gmx.de>

> From: Marshall Rose [mailto:mrose+internet.xml2rfc@dbc.mtview.ca.us]
> Sent: Thursday, April 17, 2003 6:13 PM
> To: Julian Reschke
> Cc: xml2rfc@lists.xml.resource.org
> Subject: Re: [xml2rfc] xml2rfc v1.18 imminent...
>
>
> > >     - implement <spanx/> to replace emoticon stuff
> >
> > - add descriptions about what the currently suggested values
> should mean (I
> > think this was missing last time I looked)
>
> i think the current 2629bis talks about "emph", "strong", and "verb",
> and i think i'm pretty sure i got those for you!...

:-)

I think it's less-than clear what for instance "verb" means unless we
specify it. Why not just stick with

http://www.w3.org/TR/html4/struct/text.html#h-9.2

?

> > I think the problem lies in the concept of "sections occuring after
> > appendices". Why do we need to allow that anyway?
>
> well, i'm just trying to make it possible to use xml to produce rfcs the
> way the rfc editor wants them to look like. (for a more detailed
> explanation, see my previous response to graham).
>
>
> > I agree that this is a problem. Somehow I think we should try to get an
> > answer from the RFC editor -- this is a problem no matter how
> you produce
> > the text version of an RFC or I-D.
>
> sure, although i've been waiting over two weeks for the response to my
> last question on 2223bis...

I understand it's frustrating, but I think we should try to get better
feedback here. This is a valid concern, and the RFC revision shouldn't
specify something that really doesn't make any sense at all.

Julian


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



From: ned.freed@mrochek.com (ned.freed@mrochek.com)
Date: Thu, 17 Apr 2003 09:22:50 -0700 (PDT)
Subject: [xml2rfc] Text Tables in xml2rfc
In-Reply-To: "Your message dated Thu, 17 Apr 2003 11:04:33 -0400" <20030417150433.GW2000@sbrim-w2k>
References: <2147483647.1050508711@nifty-jr.west.sun.com> <20030417150433.GW2000@sbrim-w2k>
Message-ID: <01KUTUX15OL8002O3W@mauve.mrochek.com>

> It feels painful, and it's a throwback to the days of nroff and
> hand-editing of html.  I prefer to use emacs table mode and leave it as
> artwork.  We don't need to use markup to create tables when we have
> local tools with actual user interfaces.

And nothing  prevents you from continuing to do this. I, on the other hand,
would like to have a table facility in xml2rfc to produce tables.

				Ned


From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Thu, 17 Apr 2003 09:13:09 -0700
Subject: [xml2rfc] xml2rfc v1.18 imminent...
In-Reply-To: <JIEGINCHMLABHJBIGKBCCEALHBAA.julian.reschke@gmx.de>
References: <20030416150021.3f00af70.mrose+internet.xml2rfc@dbc.mtview.ca.us> <JIEGINCHMLABHJBIGKBCCEALHBAA.julian.reschke@gmx.de>
Message-ID: <20030417091309.2c35d636.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> >     - implement <spanx/> to replace emoticon stuff
> 
> - add descriptions about what the currently suggested values should mean (I
> think this was missing last time I looked)
    
i think the current 2629bis talks about "emph", "strong", and "verb",
and i think i'm pretty sure i got those for you!...

    
> I think the problem lies in the concept of "sections occuring after
> appendices". Why do we need to allow that anyway?
    
well, i'm just trying to make it possible to use xml to produce rfcs the
way the rfc editor wants them to look like. (for a more detailed
explanation, see my previous response to graham).
    
    
> I agree that this is a problem. Somehow I think we should try to get an
> answer from the RFC editor -- this is a problem no matter how you produce
> the text version of an RFC or I-D.

sure, although i've been waiting over two weeks for the response to my
last question on 2223bis...
    
/mtr


From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Thu, 17 Apr 2003 09:09:25 -0700
Subject: [xml2rfc] xml2rfc v1.18 imminent...
In-Reply-To: <5.1.0.14.2.20030416235657.00b78330@127.0.0.1>
References: <20030416150021.3f00af70.mrose+internet.xml2rfc@dbc.mtview.ca.us> <5.1.0.14.2.20030416235657.00b78330@127.0.0.1>
Message-ID: <20030417090925.3d180187.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> Hmmm... using numbers-letters-numbers looks rather odd to me.

i agree. the rfc-editor just doesn't number them, which works fine right until
you have subsections...


> My current suggestion is that sections that come after appendices get 
> section "numbers" that follow on from the appendix labelling, e.g.
> 
>      1. Introduction
>      2. Specification
>      3. Example
>      A. Acknowledgements
>      B. IANA Considerations
>      C. Security Considerations
>      C.1  Confidentiality
>      C.2  Traffic Analysis
> 
> This, to me, seems like a logical conclusion of requiring that these 
> sections always appear at the end of the document.  If there are no 
> appendices, then the special sections might be numbered or lettered -- I'm 
> agnostic on that.


the fundamental problem that i had when defining rfc2629 and writing xml2rfc is
the fact that the publication process is primarily a manual process. what this
means is that rules are consistently applied in theory, but not in practice.
it's not that the rules are ignored, it's just that things slip through
the cracks because a person is enforcing them instead of a program.

for example, if you study rfc2223 very carefully, you will find some places
where it does not conform to rfc2223. was this on purpose? probably not. it's
just an artifact of a process that is essentially manual rather automated.

the issue with the numbering is a derivative of this situation. sure, not
numbering things like "*Considerations" is fine, right until you have
subsections. when you have to write code that implements these rules, this kind
of gap in the input domain becomes obvious. perhaps the obvious thing is to do
this:

	1. sections which appear after appendices are unnumbered
	2. sections which appear after appendices may not have subsections

/mtr


From: swb@employees.org (Scott W Brim)
Date: Thu, 17 Apr 2003 11:04:33 -0400
Subject: [xml2rfc] Text Tables in xml2rfc
In-Reply-To: <2147483647.1050508711@nifty-jr.west.sun.com>
References: <2147483647.1050508711@nifty-jr.west.sun.com>
Message-ID: <20030417150433.GW2000@sbrim-w2k>

It feels painful, and it's a throwback to the days of nroff and
hand-editing of html.  I prefer to use emacs table mode and leave it as
artwork.  We don't need to use markup to create tables when we have
local tools with actual user interfaces.


From: henrik@levkowetz.com (Henrik Levkowetz)
Date: Thu, 17 Apr 2003 11:04:38 +0200
Subject: [xml2rfc] Text Tables in xml2rfc
In-Reply-To: <2147483647.1050508711@nifty-jr.west.sun.com>
References: <2147483647.1050508711@nifty-jr.west.sun.com>
Message-ID: <20030417110438.78738895.henrik@levkowetz.com>

On Wed, 16 Apr 2003 15:58:31 -0700, Chris Newman <Chris.Newman@sun.com> wrote:
> I believe xml2rfc does need some basic table support for textual tables.  Some 
> observations:
> 
> * HTML tables are _extremely_ complex to implement and don't map well to plain
>   text display, and thus unsuitable for xml2rfc

I think I disagree. *Rendering* of HTML tables is complex. Writing them is
straightforward.

> * Using artwork for tables makes them a pain to edit.  This is contrary to a
>   primary purpose of xml2rfc -- making RFCs/drafts simple to edit.

I clearly disagree. Artwork is much easier to get exactly right for text
output than using a table support feature.

> * Using artwork for tables makes them display poorly in HTML output.  While
>   this does not violate the primary purpose of xml2rfc, it is a secondary
>   concern.

I agree. Using artwork for tables is a real loss for HTML output.

> * Hand editing the <tr><td></td></tr> structure for HTML tables is awkward with
>   a text editor, thus that structure is not appropriate for xml2rfc from the
>   ease-of-use standpoint.

Not really. But I like TeX's simple table generation format better. I think
you've taken some clues from that in your proposal :-)

> * Formatting tables without knowing the column widths in advance makes a
>   single pass formatter problematic.

Sure.

> Based on those observations, here's an initial strawman:
> 
> <texttable>
>   <ttcol width="10%">Title 1</ttcol>
>   <ttcol width="40%">Title 2</ttcol>
>   <ttcol>Title 3</ttcol>
>   column 1 text<cell />column 2 text<cell />column 3 text<cell />
>   row 2 col 1  <cell />row 2 col 2  <cell />row 2 col 3  <cell />
>   empty col:   <cell />             <cell />row 3 col 3
> </texttable>

For XML I'd be more comfortable with <cell> Cell text </cell>.

Contrary to some others, I think it's eminently OK to dispence with
the additional <row /> elements, and just render the cells consecutively,
with new rows determined by the number of <ttcol />

> The outer entity is "texttable" (to distinguish from HTML <table>).  

Yes, that's a SHOULD if we want a simplified syntax.

> This must 
> be followed by one or more ttcol elements.  Widths are only specified as 
> percentages (nothing else is reasonable for all output formats).  

And keeping the "%" sign makes the meaning obvious.

> <ttcol> with 
> omitted width tag are all of equal width and consume the remaining width at the 
> current indent level.  The text of a <ttcol> entity is the column title.  An 
> empty <ttcol> entity means there is no title for that column.  The body of the 
> table is made up of text with <cell /> tags between the cells of the table. 
> Whitespace adjacent to <cell /> tags is stripped.  An empty cell has only 
> whitespace between the <cell /> tags.  Text in a cell is wrapped as
> necessary to fit the column width.  Column widths are not adjusted based on the 
> text in the columns.

Sounds OK to me, although I don't think the usefulness for text output
is that much greater than using artwork.

	Henrik

-- 
  There is no such thing as "social gambling." Either you are there to
  cut the other bloke's heart out and eat it -- or you're a sucker. If
  you don't like this choice -- don't gamble. 


From: julian.reschke@gmx.de (Julian Reschke)
Date: Thu, 17 Apr 2003 09:56:25 +0200
Subject: [xml2rfc] Text Tables in xml2rfc
In-Reply-To: <5.1.0.14.2.20030417083559.02972f18@127.0.0.1>
Message-ID: <JIEGINCHMLABHJBIGKBCGEBAHBAA.julian.reschke@gmx.de>

> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of Graham Klyne
> Sent: Thursday, April 17, 2003 9:42 AM
> To: Chris Newman; xml2rfc@lists.xml.resource.org
> Subject: Re: [xml2rfc] Text Tables in xml2rfc
>
>
> This looks handy to me.
>
> It seems to me a little at odds with normal XML practice to use
> <cell/> as
> a separator rather than a container.  I guess I'd go for something like:
>
> [[
> <texttable>
>   <ttcol width="10%">Title 1</ttcol>
>   <ttcol width="40%">Title 2</ttcol>
>   <ttcol>Title 3</ttcol>
>   <c>column 1 text</c><c>column 2 text</c><c>column 3 text</c>
>   <c>row 2 col 1  </c><c>row 2 col 2  </c><c>row 2 col 3  </c>
>   <c>empty col:   </c><c/>                <c>row 3 col 3  </c>
> </texttable>
> ]]


This makes it somehow more logical, but I'd still add <row> elements (in
which case we'd basically have renamed HTML table elements, so why not just
adopt them???).

> But this is small detail, and I can see why you might prefer your way.
>
> I tend to agree your comments about '%'.
>

Julian

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



From: GK@ninebynine.org (Graham Klyne)
Date: Thu, 17 Apr 2003 08:41:36 +0100
Subject: [xml2rfc] Text Tables in xml2rfc
In-Reply-To: <2147483647.1050508711@nifty-jr.west.sun.com>
Message-ID: <5.1.0.14.2.20030417083559.02972f18@127.0.0.1>

This looks handy to me.

It seems to me a little at odds with normal XML practice to use <cell/> as 
a separator rather than a container.  I guess I'd go for something like:

[[
<texttable>
  <ttcol width="10%">Title 1</ttcol>
  <ttcol width="40%">Title 2</ttcol>
  <ttcol>Title 3</ttcol>
  <c>column 1 text</c><c>column 2 text</c><c>column 3 text</c>
  <c>row 2 col 1  </c><c>row 2 col 2  </c><c>row 2 col 3  </c>
  <c>empty col:   </c><c/>                <c>row 3 col 3  </c>
</texttable>
]]

But this is small detail, and I can see why you might prefer your way.

I tend to agree your comments about '%'.

#g
--


At 15:58 16/04/2003 -0700, Chris Newman wrote:
>I believe xml2rfc does need some basic table support for textual 
>tables.  Some observations:
>
>* HTML tables are _extremely_ complex to implement and don't map well to plain
>  text display, and thus unsuitable for xml2rfc
>
>* Using artwork for tables makes them a pain to edit.  This is contrary to a
>  primary purpose of xml2rfc -- making RFCs/drafts simple to edit.
>
>* Using artwork for tables makes them display poorly in HTML output.  While
>  this does not violate the primary purpose of xml2rfc, it is a secondary
>  concern.
>
>* Hand editing the <tr><td></td></tr> structure for HTML tables is awkward 
>with
>  a text editor, thus that structure is not appropriate for xml2rfc from the
>  ease-of-use standpoint.
>
>* Formatting tables without knowing the column widths in advance makes a
>  single pass formatter problematic.
>
>Based on those observations, here's an initial strawman:
>
><texttable>
>  <ttcol width="10%">Title 1</ttcol>
>  <ttcol width="40%">Title 2</ttcol>
>  <ttcol>Title 3</ttcol>
>  column 1 text<cell />column 2 text<cell />column 3 text<cell />
>  row 2 col 1  <cell />row 2 col 2  <cell />row 2 col 3  <cell />
>  empty col:   <cell />             <cell />row 3 col 3
></texttable>
>
>The outer entity is "texttable" (to distinguish from HTML <table>).  This 
>must be followed by one or more ttcol elements.  Widths are only specified 
>as percentages (nothing else is reasonable for all output 
>formats).  <ttcol> with omitted width tag are all of equal width and 
>consume the remaining width at the current indent level.  The text of a 
><ttcol> entity is the column title.  An empty <ttcol> entity means there 
>is no title for that column.  The body of the table is made up of text 
>with <cell /> tags between the cells of the table. Whitespace adjacent to 
><cell /> tags is stripped.  An empty cell has only whitespace between the 
><cell /> tags.  Text in a cell is wrapped as
>necessary to fit the column width.  Column widths are not adjusted based 
>on the text in the columns.
>
>Comments?  Suggested refinements?
>
>                - Chris
>
>_______________________________________________
>xml2rfc mailing list
>xml2rfc@lists.xml.resource.org
>http://lists.xml.resource.org/mailman/listinfo/xml2rfc

-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E



From: julian.reschke@gmx.de (Julian Reschke)
Date: Thu, 17 Apr 2003 08:56:13 +0200
Subject: [xml2rfc] 1.15 format style list numbering does not reset
In-Reply-To: <JIEGINCHMLABHJBIGKBCCEALHBAA.julian.reschke@gmx.de>
Message-ID: <JIEGINCHMLABHJBIGKBCGEAMHBAA.julian.reschke@gmx.de>

Hi all,

I really think it would be good if we could get a consensus about how the
"extended list numbering" is supposed to work. The current implementation
IMHO

- either needs to be specified precisely or
- we should settle with an easier to understand/implement numbering model

Discussion somehow ended in:

	<http://lists.xml.resource.org/pipermail/xml2rfc/2003-February/000458.html>

Julian

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



From: julian.reschke@gmx.de (Julian Reschke)
Date: Thu, 17 Apr 2003 08:52:58 +0200
Subject: [xml2rfc] Text Tables in xml2rfc
In-Reply-To: <2147483647.1050508711@nifty-jr.west.sun.com>
Message-ID: <JIEGINCHMLABHJBIGKBCOEALHBAA.julian.reschke@gmx.de>

> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of Chris Newman
> Sent: Thursday, April 17, 2003 12:59 AM
> To: xml2rfc@lists.xml.resource.org
> Subject: [xml2rfc] Text Tables in xml2rfc
>
>
> I believe xml2rfc does need some basic table support for textual  tables.
Some
> observations:
>
> * HTML tables are _extremely_ complex to implement and don't map  well to
plain
>   text display, and thus unsuitable for xml2rfc

Agreed.

> * Using artwork for tables makes them a pain to edit.  This is  contrary
to a
>   primary purpose of xml2rfc -- making RFCs/drafts simple to edit.

Agreed.

> * Using artwork for tables makes them display poorly in HTML  output.
While
>   this does not violate the primary purpose of xml2rfc, it is a secondary
>   concern.

Agreed.

> * Hand editing the <tr><td></td></tr> structure for HTML tables  is
awkward with
>   a text editor, thus that structure is not appropriate for  xml2rfc from
the
>   ease-of-use standpoint.

Not agreed. It's a very logical content model that everybody's aware of.

> * Formatting tables without knowing the column widths in advance makes a
>   single pass formatter problematic.

Yes.

> Based on those observations, here's an initial strawman:
>
> <texttable>
>   <ttcol width="10%">Title 1</ttcol>
>   <ttcol width="40%">Title 2</ttcol>
>   <ttcol>Title 3</ttcol>
>   column 1 text<cell />column 2 text<cell />column 3 text<cell />
>   row 2 col 1  <cell />row 2 col 2  <cell />row 2 col 3  <cell />
>   empty col:   <cell />             <cell />row 3 col 3
> </texttable>
>
> The outer entity is "texttable" (to distinguish from HTML  <table>).  This
must

Why do we need to distinguish???

> be followed by one or more ttcol elements.  Widths are only specified as
> percentages (nothing else is reasonable for all output formats).   <ttcol>
with
> omitted width tag are all of equal width and consume the  remaining width
at the
> current indent level.  The text of a <ttcol> entity is the column  title.
An
> empty <ttcol> entity means there is no title for that column.   The body
of the
> table is made up of text with <cell /> tags between the cells of  the
table.
> Whitespace adjacent to <cell /> tags is stripped.  An empty cell has only
> whitespace between the <cell /> tags.  Text in a cell is wrapped as
> necessary to fit the column width.  Column widths are not  adjusted based
on the
> text in the columns.
>
> Comments?  Suggested refinements?

I hardly know where to start :-)

- The structure doesn't have container elements for rows - why? Row
processing depends on the number of previously found ttcol elements. With
this structure, input errors (mismatches between column titles and cell
count) can not be detected.

- Why aren't the cells container elements? (This and the previous one make
it extremely hard to process this structure using XSLT).

- how do I left/right adjust (I think this is a minimal requirement for most
tables)?

- How are tables counted / labelled? Shouldn't this be in the "figure"
content model?

Alternative proposal:

 <table>
   <thead>
     <th width="10%">Title 1</th>
     <th width="40%">Title 2</th>
     <th>Title 3</th>
   </thead>
   <tbody>
     <tr><td>column 1 text</td><td>column 2 text</td><td>column 3
text</td></tr>
     <tr><td>row 2 col 1</td><td>row 2 col 2  </td><td>row 2 col 3
</td></tr>
     <tr><td>empty col:   </td><td/><td>row 3 col 3</td></tr>
   </tbody>
 </table>

Advantages:

- well-understood and easy-to process content model
- everybody is familiar with it anyway (just restrict the options)


Julian

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



From: julian.reschke@gmx.de (Julian Reschke)
Date: Thu, 17 Apr 2003 08:36:20 +0200
Subject: [xml2rfc] xml2rfc v1.18 imminent...
In-Reply-To: <20030416150021.3f00af70.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <JIEGINCHMLABHJBIGKBCCEALHBAA.julian.reschke@gmx.de>

> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of Marshall Rose
> Sent: Thursday, April 17, 2003 12:00 AM
> To: xml2rfc@lists.xml.resource.org
> Subject: [xml2rfc] xml2rfc v1.18 imminent...
>
>
> hi. i'm getting ready to release v1.18. changes are:
>
>     - new LICENSE text
>     - implement <spanx/> to replace emoticon stuff

Two suggestions:

- add descriptions about what the currently suggested values should mean (I
think this was missing last time I looked)
- consider using a shorter element name :-)

>     - implement <appendix/> for rfc223bis
>     - ?rfc strict='yes'? invokes a crude validity check
>
> the change for
>
>     <!ELEMENT middle      (section+,appendix*,section*)>
>
> is a little funky in the sense that you can get something like this:
>
>     1. Introduction
>     2. Specification
>     3. Example
>     A. Acknowledgements
>     4. IANA Considerations
>     5. Security Considerations
>
> the reason this looks better in 2223bis is because sections occurring
> after appendices aren't numbered, e.g.,

I think the problem lies in the concept of "sections occuring after
appendices". Why do we need to allow that anyway?

>     1. Introduction
>     2. Specification
>     3. Example
>     A. Acknowledgements
>        IANA Considerations
>        Security Considerations
>
> the reason that xml2rfc doesn't produce code like that is because i
> don't know how to number subsections in the unnumbered sections, e.g.,
>
>     5. Security Considerations
>     5.1. Confidentiality
>     5.2. Traffic Analysis
>
> somehow i think that doing
>
>     1. Introduction
>     2. Specification
>     3. Example
>     A. Acknowledgements
>        IANA Considerations
>        Security Considerations
>          Confidentiality
>          Traffic Analysis
>
> would look just too odd.
>
> comments?

I agree that this is a problem. Somehow I think we should try to get an
answer from the RFC editor -- this is a problem no matter how you produce
the text version of an RFC or I-D.

Julian

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



From: Chris.Newman@Sun.COM (Chris Newman)
Date: Wed, 16 Apr 2003 18:24:48 -0700
Subject: [xml2rfc] Text Tables in xml2rfc
In-Reply-To: <20030416174235.251f9565.mrose+internet.xml2rfc@dbc.mtview.ca.us>
References: <2147483647.1050508711@nifty-jr.west.sun.com> <20030416174235.251f9565.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <2147483647.1050517488@nifty-jr.west.sun.com>

begin quotation by Marshall Rose on 2003/4/16 17:42 -0700:
> 1. since the width is always a percentage, why not have:
>
>     <ttcol width="10">
>
> instead of:
>
>     <ttcol width="10%">

Without the "%", the units of that number would be implicit rather than 
explicit.  The advantage of the implicit form is that it is one character less 
to type when editing the document.  The advantage of the explicit form is it 
makes it quite clear to someone reading the document what the document means, 
even if they are unfamiliar with the DTD.  Futhermore, the "width" attribute in 
HTML tags defaults to points rather than percentage, so someone familiar with 
HTML might be confused reading the implicit form.

This is a design tradeoff rather than a clear right/wrong situation.  But I 
feel the benefits of requiring the explicit form outweigh the costs.

> 2. presumably we want this to be included in sections' content, model, e.g.,
>
>     <!ELEMENT section     (t|figure|iref|section|texttable)*>
>     <!ELEMENT texttable   (ttcol+,(%TEXT;,cell)*,%TEXT;)>
>     <!ELEMENT ttcol       (%TEXT;)>
>     <!ATTLIST ttcol
>               width       %NUMBER;           #IMPLIED>
>     <!ELEMENT cell        EMPTY>

Looks good to me.

                - Chris



From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Wed, 16 Apr 2003 17:42:35 -0700
Subject: [xml2rfc] Text Tables in xml2rfc
In-Reply-To: <2147483647.1050508711@nifty-jr.west.sun.com>
References: <2147483647.1050508711@nifty-jr.west.sun.com>
Message-ID: <20030416174235.251f9565.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> I believe xml2rfc does need some basic table support for textual tables.
> ...
> 
> Based on those observations, here's an initial strawman:
> ...

i like it. minimal.
    
i have two comments:
    
1. since the width is always a percentage, why not have:
    
    <ttcol width="10">

instead of:
    
    <ttcol width="10%">
    
    
2. presumably we want this to be included in sections' content, model, e.g.,
    
    <!ELEMENT section     (t|figure|iref|section|texttable)*>
    <!ELEMENT texttable   (ttcol+,(%TEXT;,cell)*,%TEXT;)>
    <!ELEMENT ttcol       (%TEXT;)>
    <!ATTLIST ttcol
              width       %NUMBER;           #IMPLIED>
    <!ELEMENT cell        EMPTY>
    
/mtr


From: GK@ninebynine.org (Graham Klyne)
Date: Thu, 17 Apr 2003 00:00:56 +0100
Subject: [xml2rfc] xml2rfc v1.18 imminent...
In-Reply-To: <20030416150021.3f00af70.mrose+internet.xml2rfc@dbc.mtview. ca.us>
Message-ID: <5.1.0.14.2.20030416235657.00b78330@127.0.0.1>

At 15:00 16/04/2003 -0700, Marshall Rose wrote:
>somehow i think that doing
>
>     1. Introduction
>     2. Specification
>     3. Example
>     A. Acknowledgements
>        IANA Considerations
>        Security Considerations
>          Confidentiality
>          Traffic Analysis
>
>would look just too odd.

Hmmm... using numbers-letters-numbers looks rather odd to me.

My current suggestion is that sections that come after appendices get 
section "numbers" that follow on from the appendix labelling, e.g.

     1. Introduction
     2. Specification
     3. Example
     A. Acknowledgements
     B. IANA Considerations
     C. Security Considerations
     C.1  Confidentiality
     C.2  Traffic Analysis

This, to me, seems like a logical conclusion of requiring that these 
sections always appear at the end of the document.  If there are no 
appendices, then the special sections might be numbered or lettered -- I'm 
agnostic on that.

#g


-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E



From: Chris.Newman@Sun.COM (Chris Newman)
Date: Wed, 16 Apr 2003 15:58:31 -0700
Subject: [xml2rfc] Text Tables in xml2rfc
Message-ID: <2147483647.1050508711@nifty-jr.west.sun.com>

I believe xml2rfc does need some basic table support for textual tables.  Some 
observations:

* HTML tables are _extremely_ complex to implement and don't map well to plain
  text display, and thus unsuitable for xml2rfc

* Using artwork for tables makes them a pain to edit.  This is contrary to a
  primary purpose of xml2rfc -- making RFCs/drafts simple to edit.

* Using artwork for tables makes them display poorly in HTML output.  While
  this does not violate the primary purpose of xml2rfc, it is a secondary
  concern.

* Hand editing the <tr><td></td></tr> structure for HTML tables is awkward with
  a text editor, thus that structure is not appropriate for xml2rfc from the
  ease-of-use standpoint.

* Formatting tables without knowing the column widths in advance makes a
  single pass formatter problematic.

Based on those observations, here's an initial strawman:

<texttable>
  <ttcol width="10%">Title 1</ttcol>
  <ttcol width="40%">Title 2</ttcol>
  <ttcol>Title 3</ttcol>
  column 1 text<cell />column 2 text<cell />column 3 text<cell />
  row 2 col 1  <cell />row 2 col 2  <cell />row 2 col 3  <cell />
  empty col:   <cell />             <cell />row 3 col 3
</texttable>

The outer entity is "texttable" (to distinguish from HTML <table>).  This must 
be followed by one or more ttcol elements.  Widths are only specified as 
percentages (nothing else is reasonable for all output formats).  <ttcol> with 
omitted width tag are all of equal width and consume the remaining width at the 
current indent level.  The text of a <ttcol> entity is the column title.  An 
empty <ttcol> entity means there is no title for that column.  The body of the 
table is made up of text with <cell /> tags between the cells of the table. 
Whitespace adjacent to <cell /> tags is stripped.  An empty cell has only 
whitespace between the <cell /> tags.  Text in a cell is wrapped as
necessary to fit the column width.  Column widths are not adjusted based on the 
text in the columns.

Comments?  Suggested refinements?

                - Chris



From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Wed, 16 Apr 2003 15:00:21 -0700
Subject: [xml2rfc] xml2rfc v1.18 imminent...
Message-ID: <20030416150021.3f00af70.mrose+internet.xml2rfc@dbc.mtview.ca.us>

hi. i'm getting ready to release v1.18. changes are:
    
    - new LICENSE text
    - implement <spanx/> to replace emoticon stuff
    - implement <appendix/> for rfc223bis
    - ?rfc strict='yes'? invokes a crude validity check

the change for
    
    <!ELEMENT middle      (section+,appendix*,section*)>
    
is a little funky in the sense that you can get something like this:
    
    1. Introduction
    2. Specification
    3. Example
    A. Acknowledgements
    4. IANA Considerations
    5. Security Considerations
    
the reason this looks better in 2223bis is because sections occurring
after appendices aren't numbered, e.g.,
    
    1. Introduction
    2. Specification
    3. Example
    A. Acknowledgements
       IANA Considerations
       Security Considerations

the reason that xml2rfc doesn't produce code like that is because i
don't know how to number subsections in the unnumbered sections, e.g.,
    
    5. Security Considerations
    5.1. Confidentiality
    5.2. Traffic Analysis
    
somehow i think that doing
    
    1. Introduction
    2. Specification
    3. Example
    A. Acknowledgements
       IANA Considerations
       Security Considerations
         Confidentiality
         Traffic Analysis

would look just too odd.
    
comments?
    
/mtr


From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Wed, 16 Apr 2003 13:29:54 -0700
Subject: [xml2rfc] Example of iref
In-Reply-To: <3E97C976.2090003@ericsson.com>
References: <3E96C7DA.3080004@ericsson.com> <20030411093652.042bbc1f.mrose+internet.xml2rfc@dbc.mtview.ca.us> <3E97C976.2090003@ericsson.com>
Message-ID: <20030416132954.5b486ad9.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> I will propose to clarify the intention of the iref element by adding some
> text at the beginning of section 2.3.1.6 in the line of:
> 
> "The iref element is used to create an index table (apart from the table of 
> contents automatically created). This feature might be useful, e.g., to
> create an index of figures or an index or tables. The index would typically
> be inserted at the end of the document (Not sure about this text)."

well, this is essentially content-free, so i'll add just this one
phrase to the existing text:
    
    typically rendered at the end of the document.
    
/mtr


From: Miguel.A.Garcia@ericsson.com (Miguel A. Garcia)
Date: Sat, 12 Apr 2003 11:08:22 +0300
Subject: [xml2rfc] Example of iref
References: <3E96C7DA.3080004@ericsson.com> <20030411093652.042bbc1f.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <3E97C976.2090003@ericsson.com>

Marshall:

Thanks for your answer. I got it now.

In 2629-bis I was missing some more text explaining the capability of creating 
one or more index tables. Also it would be good to mention (perhaps this is 
shouldn't be part of the RFC, but of xml2rfc) that the index tables are created 
at the  end of the document.

I will propose to clarify the intention of the iref element by adding some text 
at the beginning of section 2.3.1.6 in the line of:

"The iref element is used to create an index table (apart from the table of 
contents automatically created). This feature might be useful, e.g., to create 
an index of figures or an index or tables. The index would typically be inserted 
at the end of the document (Not sure about this text)."


Marshall Rose wrote:
>>Hi:
>>
>>I am trying to understand what is the "iref" element and how it works.
>>Unfortunately the description in RFC 2629 or 2629-bis is very poor, and I
>>haven't found an example of usage.
>>
>>So can anyone send me an axample of how to use iref?
> 
> 
> well, here's a fragment from rfc2629.xml:
> 
>     
>     <section anchor="iref" title="The iref Element">
>     <figure>
>     <preamble><iref item="indexing" subitem="how to" />The "iref" element
>     is used to add information to an index.
>     The mandatory "item" attribute is the primary key the information is stored
>     under,
>     whilst the optional "subitem" attribute is the secondary key,
>     e.g.,</preamble>
>     <artwork><![CDATA[
>         <iref item="indexing" subitem="how to" />
>     ]]></artwork>
>     </figure>
>     <t>Finally, note that the "iref" element is always empty -- it never
>     contains any text.</t>
>     </section>
> 
>     
> the exact example shown in the CDATA block is used in the markup, which
> results in an index entry being made on the next to last page:
>     
>     
>     Index
> 
>     I
>        indexing
>           how to  16
> 
> 
> not really sure how to make it more clear than that.
> 
> /mtr


-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                         Jorvas, Finland
mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553
mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002








From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Fri, 11 Apr 2003 09:36:52 -0700
Subject: [xml2rfc] Example of iref
In-Reply-To: <3E96C7DA.3080004@ericsson.com>
References: <3E96C7DA.3080004@ericsson.com>
Message-ID: <20030411093652.042bbc1f.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> Hi:
> 
> I am trying to understand what is the "iref" element and how it works.
> Unfortunately the description in RFC 2629 or 2629-bis is very poor, and I
> haven't found an example of usage.
> 
> So can anyone send me an axample of how to use iref?

well, here's a fragment from rfc2629.xml:

    
    <section anchor="iref" title="The iref Element">
    <figure>
    <preamble><iref item="indexing" subitem="how to" />The "iref" element
    is used to add information to an index.
    The mandatory "item" attribute is the primary key the information is stored
    under,
    whilst the optional "subitem" attribute is the secondary key,
    e.g.,</preamble>
    <artwork><![CDATA[
        <iref item="indexing" subitem="how to" />
    ]]></artwork>
    </figure>
    <t>Finally, note that the "iref" element is always empty -- it never
    contains any text.</t>
    </section>

    
the exact example shown in the CDATA block is used in the markup, which
results in an index entry being made on the next to last page:
    
    
    Index

    I
       indexing
          how to  16


not really sure how to make it more clear than that.

/mtr


From: Miguel.A.Garcia@ericsson.com (Miguel A. Garcia)
Date: Fri, 11 Apr 2003 16:49:14 +0300
Subject: [xml2rfc] Example of iref
Message-ID: <3E96C7DA.3080004@ericsson.com>

Hi:

I am trying to understand what is the "iref" element and how it works. Unfortunately the description in RFC 2629 or 2629-bis is very poor, and I haven't found an example of usage.

So can anyone send me an axample of how to use iref?

Regards,

     Miguel
-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                         Jorvas, Finland
mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553
mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002







From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Wed, 9 Apr 2003 09:19:02 -0700
Subject: [xml2rfc] Tcl 8.4
In-Reply-To: <877ka3ir83.fsf@Login.CERT.Uni-Stuttgart.DE>
References: <877kasibv0.fsf@Login.CERT.Uni-Stuttgart.DE> <20030321150121.3cce6b9c.mrose+internet.xml2rfc@dbc.mtview.ca.us> <877ka3ir83.fsf@Login.CERT.Uni-Stuttgart.DE>
Message-ID: <20030409091902.5d88ded0.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> Marshall Rose <mrose+internet.xml2rfc@dbc.mtview.ca.us> writes:
> 
> >> I've just received this bug report:
> >> 
> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=185793
> >> 
> >> There's a patch in it; you might want to apply it.
> >
> > thanks!
> 
> There are a couple of additional occurrences of " -$" in the sources.
> I'm unsure if they need changing, too.

i already checked them. they should be just fine.

/mtr


From: Weimer@CERT.Uni-Stuttgart.DE (Florian Weimer)
Date: Wed, 09 Apr 2003 18:13:32 +0200
Subject: [xml2rfc] Tcl 8.4
In-Reply-To: <20030321150121.3cce6b9c.mrose+internet.xml2rfc@dbc.mtview.ca.us> (Marshall Rose's message of "Fri, 21 Mar 2003 15:01:21 -0800")
References: <877kasibv0.fsf@Login.CERT.Uni-Stuttgart.DE> <20030321150121.3cce6b9c.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <877ka3ir83.fsf@Login.CERT.Uni-Stuttgart.DE>

Marshall Rose <mrose+internet.xml2rfc@dbc.mtview.ca.us> writes:

>> I've just received this bug report:
>> 
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=185793
>> 
>> There's a patch in it; you might want to apply it.
>
> thanks!

There are a couple of additional occurrences of " -$" in the sources.
I'm unsure if they need changing, too.

-- 
Florian Weimer 	                  Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          fax +49-711-685-5898


From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Wed, 9 Apr 2003 09:09:31 -0700
Subject: [xml2rfc] a question from the back of the room
In-Reply-To: <20030401091800.12805f5d.mrose+internet.xml2rfc@dbc.mtview.ca.us>
References: <20030401091800.12805f5d.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <20030409090931.0e5f4d7e.mrose+internet.xml2rfc@dbc.mtview.ca.us>

well, it's been a week and i haven't heard anything from the rfc-editor.
    
so, we're going to use the content model henrik's suggested:
    
    <!ELEMENT middle      (section+,appendix*,section*)>
    <!ELEMENT appendix    (t|figure|iref|appendix)*>
    <!ATTLIST appendix
              anchor      ID                 #IMPLIED
              title       %ATEXT;            #REQUIRED>

julian - let me know what you think.
    
i have a version of xml2rfc.tcl right now that does this. i want to try
it out for a few more days and then i'll release it.
    
thanks,
    
/mtr


From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Fri, 4 Apr 2003 08:56:50 -0800
Subject: [xml2rfc] Patch: Do not add two spaces after abbreviations
In-Reply-To: <87el4iy09y.fsf@Login.CERT.Uni-Stuttgart.DE>
References: <87vg14k6jv.fsf@Login.CERT.Uni-Stuttgart.DE> <20030104134710.43a70cdd.mrose+internet.xml2rfc@dbc.mtview.ca.us> <87n0mgjyjy.fsf@Login.CERT.Uni-Stuttgart.DE> <20030104164940.3a7e1f68.mrose+internet.xml2rfc@dbc.mtview.ca.us> <87el4iy09y.fsf@Login.CERT.Uni-Stuttgart.DE>
Message-ID: <20030404085650.2a71c76a.mrose+internet.xml2rfc@dbc.mtview.ca.us>

ok, whatever.
    
/mtr


From: Weimer@CERT.Uni-Stuttgart.DE (Florian Weimer)
Date: Fri, 04 Apr 2003 13:23:05 +0200
Subject: [xml2rfc] Patch: Do not add two spaces after abbreviations
In-Reply-To: <20030104164940.3a7e1f68.mrose+internet.xml2rfc@dbc.mtview.ca.us> (Marshall Rose's message of "Sat, 4 Jan 2003 16:49:40 -0800")
References: <87vg14k6jv.fsf@Login.CERT.Uni-Stuttgart.DE> <20030104134710.43a70cdd.mrose+internet.xml2rfc@dbc.mtview.ca.us> <87n0mgjyjy.fsf@Login.CERT.Uni-Stuttgart.DE> <20030104164940.3a7e1f68.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <87el4iy09y.fsf@Login.CERT.Uni-Stuttgart.DE>

Marshall Rose <mrose+internet.xml2rfc@dbc.mtview.ca.us> writes:

>> > i guess BSD style, since that's what i use for the stuff that i write.
>> 
>> Can you put a file called "LICENCE" in the tarball?  Then I'll package
>> xml2rfc for Debian some day. :-)
>
> okie-dokie.

I'm sorry, but the following license is not sufficient:

| (c) 2002 Marshall T. Rose
| 
| Hold harmless the author, and any lawful use is allowed.

Copying of software (possibly including modifications)requires
explicit permission from the author, otherwise it's unlawful. 8-)

Could you use a BSD-style license without an advertising clause?
Something like this?

Copyright (c) <YEAR>, <YOUR NAME>.
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
   notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
   notice, this list of conditions and the following disclaimer in the
   documentation and/or other materials provided with the distribution.
3. Neither the name of the author nor the names of the contributors
   may be used to endorse or promote products derived from this software
   without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED.  IN NO EVENT SHALL THE AUHTORS OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.


-- 
Florian Weimer 	                  Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          fax +49-711-685-5898


From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Thu, 3 Apr 2003 20:07:33 -0800
Subject: [xml2rfc] problems using xml2rfc-1.17
In-Reply-To: <015901c2fa42$e4246090$93b58742@ssprunk>
References: <015901c2fa42$e4246090$93b58742@ssprunk>
Message-ID: <20030403200733.4d1f2263.mrose+internet.xml2rfc@dbc.mtview.ca.us>

this is very odd.
    
to debug your first problem, try this:
    
    % tclsh
    % source xml2rfc.tcl
    xml2rfc rfc2629.xml

that will print out better diagnostics for what's causing this:
couldn't compile regular expression pattern: ?+* follows nothing around line 4
    
for the second problem, i've never heard of sample.xml, can you send it?
    
/mtr


From: stephen@sprunk.org (Stephen Sprunk)
Date: Thu, 3 Apr 2003 18:41:01 -0600
Subject: [xml2rfc] problems using xml2rfc-1.17
Message-ID: <015901c2fa42$e4246090$93b58742@ssprunk>

I'm having trouble getting xml2rfc/txt/nroff working correctly using the
included xml source for RFC2629.  xml2html works just fine.

sprunk@defiant:~/www> xml2html rfc2629.xml
sprunk@defiant:~/www> ls -l rfc2629.html
-rw-r--r--    1 sprunk   users       59513 Apr  3 18:39 rfc2629.html
sprunk@defiant:~/www> xml2txt rfc2629.xml
couldn't compile regular expression pattern: ?+* follows nothing around line
4

Context:
    <rfc number="2629">
sprunk@defiant:~/www> xml2nroff rfc2629.xml
couldn't compile regular expression pattern: ?+* follows nothing around line
4

Context:
    <rfc number="2629">
sprunk@defiant:~/www>

The sample.xml file posted in the same location as the source tarballs
fails, though rather differently:

sprunk@defiant:~/www> xml2html sample.xml
invalid command name "http::cleanup"
sprunk@defiant:~/www> xml2txt sample.xml
invalid command name "http::cleanup"
sprunk@defiant:~/www>

I'm using TCL 8.0 on Linux.  Any suggestions on what to look for or fix?

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking



From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Thu, 3 Apr 2003 08:48:06 -0800
Subject: [xml2rfc] non-ascii names in xml2rfc, the sequel
In-Reply-To: <4.2.0.58.J.20030403111044.029bf048@localhost>
References: <00c801c235ca$9d1f1100$0701000a@FATORA> <JIEGINCHMLABHJBIGKBCAEJBFAAA.julian.reschke@gmx.de> <20020728223020.23d49898.mrose+internet.xml2rfc@dbc.mtview.ca.us> <4.2.0.58.J.20030403111044.029bf048@localhost>
Message-ID: <20030403084806.46dc6dee.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> Did I miss something? 

no, quite the opposite.


> If not, why didn't any of the
> ideas get implemented?

because when i asked for some concensus on the problem/solution, i got back
silence on the list. i don't have a problem adding the functionality. i do have
a problem adding functionality when:

	- i'm not going to be using the functionality; and,
	- the people who would be using it, don't express an opinion...

/mtr


From: duerst@w3.org (Martin Duerst)
Date: Thu, 03 Apr 2003 11:14:46 -0500
Subject: [xml2rfc] non-ascii names in xml2rfc, the sequel
In-Reply-To: <016601c23974$38ea1650$6500000a@dev0196>
References: <00c801c235ca$9d1f1100$0701000a@FATORA> <JIEGINCHMLABHJBIGKBCAEJBFAAA.julian.reschke@gmx.de> <20020728223020.23d49898.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <4.2.0.58.J.20030403111044.029bf048@localhost>

Hello Marshall,

Sorry to go back to a very old discussion.

I have just downloaded xml2rfc (version 1.17, hope that's the
newest one) and didn't find any of the proposals in the
'non-ascii' discussion implemented.

Did I miss something? If not, why didn't any of the
ideas get implemented?


At 19:58 02/07/31 -0700, Marshall Rose wrote:
>here is my current thinking. comments are welcome.
>
>to support authors who want localized names when rendering to a format that
>supports that,
>an optional element will be added to the <author/> element, i.e.,
>
>     <!ELEMENT author      (organization,address?,unictext?)>
>
>     <!ELEMENT unictext    (organization,address?)>
>     <!ATTLIST unictext
>               initials        %ATEXT;            #IMPLIED
>               surname     %ATEXT;            #IMPLIED
>               fullname     %ATEXT;            #IMPLIED>
>
>  which allows CDATA and #PCDATA to contain unicode characters. The xml:lang
>attribute may also be used to provide additional information.
>
>The <unictext/> element is consulted only if the output format supports
>unicode.
>
>comments?

Please use elements rather than attributes for initials/surname/fullname
in the new element.


Regards,   Martin.


From: mcr@sandelman.ottawa.on.ca (Michael Richardson)
Date: Tue, 01 Apr 2003 19:00:14 -0500
Subject: [xml2rfc] accomodating draft-rfc-editor-rfc2223bis-04.txt
In-Reply-To: Your message of "Mon, 31 Mar 2003 16:15:22 PST." <20030331161522.3b3e8eef.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <200304020000.h3200FUK006477@marajade.sandelman.ottawa.on.ca>

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


I prefer either option 3, *or* 

option 4:

    <!ELEMENT back        (appendix*,securityconsideration,ianaconsideration,references*,)>

I.e. to identify the "special" sections explicitely.

]       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

iQCVAwUBPoooDYqHRg3pndX9AQHBEAQAoejgtQs5l/Y3TB1CVuQOyWFMcqkiGmaV
2GXhrIinZLwek0skN6ejZMTvqlrrj/JoF7ugkb7qZjULvmxb+75JnQ+LiWUrcZEe
6DqJY1Reu6xWH547vpxp3z230FOVoDpXQyWrLawMuIeF9OVFtkV4v7gvU3rv4xrD
YCaeU4+7wVo=
=/EXM
-----END PGP SIGNATURE-----


From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Tue, 1 Apr 2003 09:18:00 -0800
Subject: [xml2rfc] a question from the back of the room
Message-ID: <20030401091800.12805f5d.mrose+internet.xml2rfc@dbc.mtview.ca.us>

hi. i'm in the process of reviewing rfc2629 with respect to
draft-rfc-editor-rfc2223bis-04.
    
one issue has arisen that i'd like some clarity on.
    
the way that i read the new rules is that the ordering of sections,
appendices and "special" sections (e.g., security considerations) looks
like this:
    
	sections
	appendices
	special sections
	references

others on the xml2rfc list think that a looser interpretation is
appropriate, e.g., that the ordering of sections, appendices, specials,
and references is pretty much up to the author.
    
my perception is that things aren't this flexible.
    
could someone clarify where the line is on this one? the answer may
impact on how we revise rfc2629 (if at all).
    
thanks,
    
/mtr


From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Tue, 1 Apr 2003 09:10:35 -0800
Subject: [xml2rfc] accomodating draft-rfc-editor-rfc2223bis-04.txt
In-Reply-To: <20030401122549.22c90746.henrik@levkowetz.com>
References: <20030331161522.3b3e8eef.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20030401122549.22c90746.henrik@levkowetz.com>
Message-ID: <20030401091035.12db27c0.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> I find this option the most palatable of those you mention, although I
> am wondering if a stricter model would be better:
> 
> 	<!ELEMENT middle      (section+, appendix*, section*)>

i like the stricter content model.

    
> Did you intend to automatically generate any <section/> after an
> <appendix/> without section numbers, or add an attribute to disable
> numbering? Of course, you can't rely on a document having appendices.
> Maybe a new element name for the end sections would be in order.


yeah, this is hard to get right without an explicit helper in the
markup.
    
/mtr


From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Tue, 1 Apr 2003 09:07:26 -0800
Subject: [xml2rfc] accomodating draft-rfc-editor-rfc2223bis-04.txt
In-Reply-To: <20030401161905.GJ2020@sbrim-w2k>
References: <20030331161522.3b3e8eef.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20030401161905.GJ2020@sbrim-w2k>
Message-ID: <20030401090726.179360f9.mrose+internet.xml2rfc@dbc.mtview.ca.us>

> On Mon, Mar 31, 2003 04:15:22PM -0800, Marshall Rose allegedly wrote:
> > where any sections in <back/> are appendices. however, the model in
> > rfc2223bis looks like this:
> >     
> >     sections
> >     appendices
> >     "special" sections (e.g., "Security Considerations")
> >     references
> 
> I don't see this requirement.  2223bis says everything up to author's
> address is "floating".  

interesting. let's test this theory. i'll send a note to the rfc-editor and copy
the list. i ask that folks on the mailing list be sensitive to the rfc-editor's
mail queue in deciding whether to reply...

thanks!

/mtr


From: swb@employees.org (Scott W Brim)
Date: Tue, 1 Apr 2003 11:19:05 -0500
Subject: [xml2rfc] accomodating draft-rfc-editor-rfc2223bis-04.txt
In-Reply-To: <20030331161522.3b3e8eef.mrose+internet.xml2rfc@dbc.mtview.ca.us>
References: <20030331161522.3b3e8eef.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <20030401161905.GJ2020@sbrim-w2k>

On Mon, Mar 31, 2003 04:15:22PM -0800, Marshall Rose allegedly wrote:
> where any sections in <back/> are appendices. however, the model in
> rfc2223bis looks like this:
>     
>     sections
>     appendices
>     "special" sections (e.g., "Security Considerations")
>     references

I don't see this requirement.  2223bis says everything up to author's
address is "floating".  

Personally I think security considerations should be before appendices,
so if there is a problem I'd go with your option 3 (appeal).

..swb


From: henrik@levkowetz.com (Henrik Levkowetz)
Date: Tue, 1 Apr 2003 12:25:49 +0200
Subject: [xml2rfc] accomodating draft-rfc-editor-rfc2223bis-04.txt
In-Reply-To: <20030331161522.3b3e8eef.mrose+internet.xml2rfc@dbc.mtview.ca.us>
References: <20030331161522.3b3e8eef.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <20030401122549.22c90746.henrik@levkowetz.com>

On Mon, 31 Mar 2003 16:15:22 -0800, Marshall Rose <mrose+internet.xml2rfc@dbc.mtview.ca.us> wrote:


> option 2 is to change the rfc2629.dtd to look like this:
> 
>     <!ELEMENT middle      (section|appendix)+>
>     
> where <appendix/> is identical in structure to <section/>. obviously,
> rfc2629 processors must continue to recognize the old model.  (if you do
> "strict" processing, then only the new model will be allowed.)


I find this option the most palatable of those you mention, although I
am wondering if a stricter model would be better:

	<!ELEMENT middle      (section+, appendix*, section*)>

Did you intend to automatically generate any <section/> after an
<appendix/> without section numbers, or add an attribute to disable
numbering? Of course, you can't rely on a document having appendices.
Maybe a new element name for the end sections would be in order.

	Henrik

-- 
Error message in Haiku form:

  Login incorrect.
  Only perfect spellers may
  enter this system.

    -- Jason Axley 


From: julian.reschke@gmx.de (Julian Reschke)
Date: Tue, 1 Apr 2003 09:28:23 +0200
Subject: [xml2rfc] accomodating draft-rfc-editor-rfc2223bis-04.txt
In-Reply-To: <20030331161522.3b3e8eef.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <JIEGINCHMLABHJBIGKBCEEMBGOAA.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, April 01, 2003 2:15 AM
> To: xml2rfc@lists.xml.resource.org
> Subject: [xml2rfc] accomodating draft-rfc-editor-rfc2223bis-04.txt
>
>
> hi. there is one substantive impact that rfc2223bis has on xml2rfc. i am
> soliciting your opinion as to how to address it.
>
>
> the model in rfc2629.dtd looks like this:
>
>     <!ELEMENT middle      (section)+>
>     <!ELEMENT back        (references*,section*)>
>
> where any sections in <back/> are appendices. however, the model in
> rfc2223bis looks like this:
>
>     sections
>     appendices
>     "special" sections (e.g., "Security Considerations")
>     references
>
> there are two or three options to reconcile this, all having varying
> levels of amusement.

Note: I just did a quick read of the draft and I'm not sure whether it
really mandates thiis (can you point me to the specific section). That being
said, I think it would be good if we can produce both types of orderings, as
long as both types exist in the real world (note that one use case is to
XML-markup *existing* RFCs, without having to rearrange document
order/section numbering).

> option 1 is to leave rfc2629.dtd alone, and require that processing
> tools buffer references, etc. it will be a pain to do this in
> xml2rfc.tcl, but it's doable.
>
> we'll have to hear from julian what he thinks the impact on xslt
> processing.

That would be trivial in XSLT (the stylesheet has random access to the whole
input document).

> option 2 is to change the rfc2629.dtd to look like this:
>
>     <!ELEMENT middle      (section|appendix)+>
>
> where <appendix/> is identical in structure to <section/>. obviously,
> rfc2629 processors must continue to recognize the old model.  (if you do
> "strict" processing, then only the new model will be allowed.)

I think having document order continue to reflect output ordering is
preferrable, so I vote for this one.

> option 3 is to ask the rfc editor not to change their ordering model.
>
>
> your comments are solicited.

Regards,

Julian

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



From: Jeff.Hodges@sun.com (Jeff Hodges)
Date: Mon, 31 Mar 2003 17:07:06 -0800
Subject: [xml2rfc] accomodating draft-rfc-editor-rfc2223bis-04.txt
References: <20030331161522.3b3e8eef.mrose+internet.xml2rfc@dbc.mtview.ca.us>
Message-ID: <3E88E63A.F9D60AC7@sun.com>

Marshall Rose wrote:
> 
> hi. there is one substantive impact that rfc2223bis has on xml2rfc. i am
> soliciting your opinion as to how to address it.
>
<snippage/>
> 
> option 2 is to change the rfc2629.dtd to look like this:
> 
>     <!ELEMENT middle      (section|appendix)+>
> 
> where <appendix/> is identical in structure to <section/>. obviously,
> rfc2629 processors must continue to recognize the old model.  (if you do
> "strict" processing, then only the new model will be allowed.)

this makes the most sense to me.

JeffH


From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose)
Date: Mon, 31 Mar 2003 16:15:22 -0800
Subject: [xml2rfc] accomodating draft-rfc-editor-rfc2223bis-04.txt
Message-ID: <20030331161522.3b3e8eef.mrose+internet.xml2rfc@dbc.mtview.ca.us>

hi. there is one substantive impact that rfc2223bis has on xml2rfc. i am
soliciting your opinion as to how to address it.

    
the model in rfc2629.dtd looks like this:
    
    <!ELEMENT middle      (section)+>
    <!ELEMENT back        (references*,section*)>

where any sections in <back/> are appendices. however, the model in
rfc2223bis looks like this:
    
    sections
    appendices
    "special" sections (e.g., "Security Considerations")
    references

there are two or three options to reconcile this, all having varying
levels of amusement.

    
option 1 is to leave rfc2629.dtd alone, and require that processing
tools buffer references, etc. it will be a pain to do this in
xml2rfc.tcl, but it's doable.
    
we'll have to hear from julian what he thinks the impact on xslt
processing.

    
option 2 is to change the rfc2629.dtd to look like this:

    <!ELEMENT middle      (section|appendix)+>
    
where <appendix/> is identical in structure to <section/>. obviously,
rfc2629 processors must continue to recognize the old model.  (if you do
"strict" processing, then only the new model will be allowed.)
    
option 3 is to ask the rfc editor not to change their ordering model.
    
    
your comments are solicited.

/mtr