Subject: [xml2rfc] spacing between multiple xrefs
From: [email-masked] (Carl Malamud)
Date: Wed, 28 May 2003 19:54:19 -0700 (PDT)

Whoops ... I got Scott's inquiry totally backward.  Never mind.  :)

> Try this:
> 
> <xref ...>&#160;<xref ...>
> 
> (utf-8 space character)
> 
> Which works for your html.
> 
> For text, s/\&\#160\;/ /
> 
> Somewhat dirty hack, I'm sure mtr has a signfiicantly more
> elegant solution.
> 
> Carl
> 
> > I just used the web-based tool, and I don't know if the change was
> > intended, but previously a series of xrefs, "<xref ...></xref> <xref
> > ..></xref>" would produce no spaces between, and now there are.  That
> > is, in the old days I would get "[2][3][4]" and now I get "[2] [3] [4]".
> > 
> > .swb
> > _______________________________________________
> > xml2rfc mailing list
> > [email-masked]
> > http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> > 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

From: [email-masked] (Marshall Rose)
Date: Wed, 28 May 2003 16:16:58 -0700
Subject: [xml2rfc] spacing between multiple xrefs
In-Reply-To: <20030528211759.GD2424@sbrim-w2k>
References: <20030528211759.GD2424@sbrim-w2k>
Message-ID: <[email-masked]>

> I just used the web-based tool, and I don't know if the change was
> intended, but previously a series of xrefs, "<xref ...></xref> <xref
> ..></xref>" would produce no spaces between, and now there are.  That
> is, in the old days I would get "[2][3][4]" and now I get "[2] [3] [4]".

my bad. i was fixing a whitespace problem with spanx and it seems to
have leaked. i've backed that off.  here's a diff you can use until i
update the web-based service.
    
/mtr
    
*** _xml2rfc.tcl	Tue May 20 10:59:39 2003
--- xml2rfc.tcl	Wed May 28 16:08:20 2003
***************
*** 6234,6239 ****
--- 6234,6240 ----
          }       
      }
      if {![cellP $line]} {
+         set eatP 0
          write_text_txt $line
      }
  
***************
*** 6253,6258 ****
--- 6254,6260 ----
          append line " \[$counter\]"
      }
      if {![cellP $line]} {
+         set eatP 0
          write_text_txt $line
      }
  
***************
*** 8571,8576 ****
--- 8573,8579 ----
          }       
      }
      if {![cellP $line]} {
+         set eatP 0
          write_text_nr $line
      }
  
***************
*** 8590,8595 ****
--- 8593,8599 ----
          append line " \[$counter\]"
      }
      if {![cellP $line]} {
+         set eatP 0
          write_text_nr $line
      }

From: [email-masked] (Carl Malamud)
Date: Wed, 28 May 2003 16:09:32 -0700 (PDT)
Subject: [xml2rfc] spacing between multiple xrefs
In-Reply-To: <20030528211759.GD2424@sbrim-w2k>
Message-ID: <[email-masked]>

Try this:

<xref ...>&#160;<xref ...>

(utf-8 space character)

Which works for your html.

For text, s/\&\#160\;/ /

Somewhat dirty hack, I'm sure mtr has a signfiicantly more
elegant solution.

Carl

> I just used the web-based tool, and I don't know if the change was
> intended, but previously a series of xrefs, "<xref ...></xref> <xref
> ..></xref>" would produce no spaces between, and now there are.  That
> is, in the old days I would get "[2][3][4]" and now I get "[2] [3] [4]".
> 
> .swb
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

From: [email-masked] (Scott W Brim)
Date: Wed, 28 May 2003 17:17:59 -0400
Subject: [xml2rfc] spacing between multiple xrefs
Message-ID: <20030528211759.GD2424@sbrim-w2k>

I just used the web-based tool, and I don't know if the change was
intended, but previously a series of xrefs, "<xref ...></xref> <xref
..></xref>" would produce no spaces between, and now there are.  That
is, in the old days I would get "[2][3][4]" and now I get "[2] [3] [4]".

.swb

From: [email-masked] (Marshall Rose)
Date: Sun, 25 May 2003 18:01:38 -0700
Subject: [xml2rfc] Texttable and horizontal rules within the table
In-Reply-To: <9260278.1053878652@localhost>
References: <[email-masked]> <[email-masked]> <9260278.1053878652@localhost>
Message-ID: <[email-masked]>

> Sigh.  I had read "compact" in the document as eliminating some
> of the (possibly gratuitous) form feeds, between-section white
> space, and other wastes of trees if the document is printed,
> which, of course, it doesn't do.  I'm glad to learn what it does
> do... I think.

well, it tries to make things a bit more "compact"...

/mtr

From: [email-masked] (John C Klensin)
Date: Sun, 25 May 2003 16:04:12 -0400
Subject: [xml2rfc] Texttable and horizontal rules within the table
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <9260278.1053878652@localhost>

--On Saturday, May 24, 2003 16:22 -0700 Marshall Rose
<[email-masked]> wrote:

> john - 
>     
>> But, if text is actually generated from xml2rfc, at least
>> with  "<?rfc compact='yes'?>", what actually appears is
>>...
>> without the between-cell rules.
> 
> exactly. if you don't specify compact mode, you get each cell
> outlined. that's why it's called "compact"...

Sigh.  I had read "compact" in the document as eliminating some
of the (possibly gratuitous) form feeds, between-section white
space, and other wastes of trees if the document is printed,
which, of course, it doesn't do.  I'm glad to learn what it does
do... I think.

     john

From: [email-masked] (Marshall Rose)
Date: Sat, 24 May 2003 16:22:13 -0700
Subject: [xml2rfc] Texttable and horizontal rules within the table
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

john - 
    
> But, if text is actually generated from xml2rfc, at least with 
> "<?rfc compact='yes'?>", what actually appears is
> 
> 	+---------------------+
> 	| ttcol #1 | ttcol #2 |
> 	+----------+----------+
> 	|  c #1    |  c #2    |
> 	|  c #3    |  c #4    |
> 	|  c #5    |  c #6    |
> 	+----------+----------+
> 
> without the between-cell rules.

exactly. if you don't specify compact mode, you get each cell
outlined. that's why it's called "compact"...
    
/mtr

From: [email-masked] (John C Klensin)
Date: Sat, 24 May 2003 10:58:07 -0400
Subject: [xml2rfc] Texttable and horizontal rules within the table
Message-ID: <[email-masked]>

Hi.

In section 2.3.1.4 of the 10 May version of 2629bis, an example 
is shown of texttable.   In HTML form, that example appears with 
horizontal rules below the column headers and below each pair of 
column entries, i.e., if presented in text form, the table would 
look more or less like:

	+---------------------+
	| ttcol #1 | ttcol #2 |
	+----------+----------+
	|  c #1    |  c #2    |
	+----------+----------+
	|  c #3    |  c #4    |
	+----------+----------+
	|  c #5    |  c #6    |
	+----------+----------+

But, if text is actually generated from xml2rfc, at least with 
"<?rfc compact='yes'?>", what actually appears is

	+---------------------+
	| ttcol #1 | ttcol #2 |
	+----------+----------+
	|  c #1    |  c #2    |
	|  c #3    |  c #4    |
	|  c #5    |  c #6    |
	+----------+----------+

without the between-cell rules.

This may be fine for the sorts of short cells that appear in the 
example, but, if the text in some of the cells requires 
wrapping, the table rapidly deteriorates into unreadability.

Is this a bug?   If it is not, and maybe if it is, would there 
be merit in a "format" (possibly better called "rowSeparation") 
attribute of texttable, with values of, e.g., "none", "rule", 
and "vspace")?

    john

From: [email-masked] (John C Klensin)
Date: Fri, 23 May 2003 17:10:32 -0400
Subject: [xml2rfc] annotated references / bibliographies and "notes in draft"
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

 "Clive D.W. Feather" <[email-masked]> wrote...

> Marshall Rose said:
>> - annotating <reference/>
>>
>> one of the oldest rfc authors (currently not a subscribre to
>> this list) has asked for the ability to annotate references,
>> e.g.,
>>...

Since the earliest RFC published under my name (as distinct from 
things I meddled in 20+ years earlier) was in 1993, I assume 
"oldest" refers to my chronological age and general senility. 
But that probably fits too :-).

>> personally, i think that a "references" section with
>> annotations is really an "annotated bibliography" section.
>> however, since this is the core audience talking, we need to
>> consider it.
>
> It would certainly help me to be able to put "This is the last
> known URL of this reference but it no longer works; can anyone
> provide a new one?" as an annotation.

Hmm.  Clive makes, perhaps unintentionally, a good point that I 
hadn't thought about and should have.  Most of us produce a 
rather high ratio of I-D drafts in comparison to final copy 
headed for the RFC Editor.  There are things that make sense in 
the former that don't in the latter.  Clive's example is one of 
them.  A note in running text like "loose end", "to be 
supplied", or "this is lame, can someone suggest a better 
explanation" can belong in an I-D and be very useful; it 
certainly doesn't belong in an RFC.

Back when I was involved with some iterative document 
preparation in SGML, we defined a "placeholder" or "note in 
draft" tag (don't remember what we called it anymore) that could 
be inserted almost anywhere.  We also defined a processing 
directive that distinguished among

	working-draft: Placeholders showed up in text, with
	emphasis.
	
	draft-final: Placeholders were ignored, so that one
	could understand what the document would look like.
	
	final: Any remaining placeholders triggered fatal errors.

Those of you who been unlucky enough to have seen my actual 
working drafts will have seen things like
    <<<mumble, curse, fix this>>>
scattered through the text.  They are sort of the conceptual 
legacy of what placeholder-tagged text would look like when 
expanded into ASCII text -- very easy to spot or search for in 
the ASCII.

Having something like that would be, IMO, a good idea.  However, 
it is different from a permanent reference annotation (the 
example Marshall gave, which I may have given him, is a bit 
misleading).  Two, relatively-more-clear examples of the latter 
would be:

	[17] American National Standards Institute (formerly
	United States of America Standards Institute), "USA Code
	for Information Interchange", ANSI X3.4-1968.  X3.4-1968
	(ASCII) has been replaced by newer versions with slight
	modifications, but the 1968 version remains definitive
	for the Internet.

This is halfway between what I'd consider "annotated reference" 
and "annotated bibliography".  The sentence starting with 
"X3.4-1968 (ASCII) has..." is a warning to the reader to not 
pick up the wrong version and get led astray.  It also slips in 
"ASCII", which is what someone is likely to search for, but 
which does not appear in the actual reference due to ANSI's 
inability to standardize on its name.  This sort of thing is 
actually common when an author needs to say something like 
"don't bother looking at the fourth edition, the cited material 
last appears in the third one".

	[22] Bush, V., "As We May Think", Atlantic Monthly, ....
	This article has been widely reprinted; it may be found,
	for example, in XXXX or YYYY.

This really is an annotated reference.  I've run into style 
manuals that _require_ it when the original is out of print or 
otherwise inaccessible, or when the author was not working from 
the real original for some reason. My 20-year-old copy of the 
Chicago Manual discusses a variation on the theme under 
"Reprints" (16.57-16.58 in my copy).

[The rest of this is likely to be tedious -- anyone not 
interested in splitting bibliographic hairs should probably stop 
reading.]

>> personally, i think that a "references" section with
>> annotations is really an "annotated bibliography" section.

Yeah, well, I agree.  But there are some cases, such as the 
second example above, in which there is a need to either be able 
to insert running text or to have a lot more tag structure.  I 
don't think the cases arise often enough, especially in RFCs, 
for lots more tag structure to be worth the trouble.  Beyond 
that, yes, but...

The above (vaguely) referenced Chicago Style Manual says (15.74):

	A list of books or other references ... may be titled
	Bibliography or Select Bibliography or, if it includes
	only works referenced in the text, Works Cited,
	Literature Cited, or References; other appropriate
	titles are not ruled out.

I've got a different style manual (which I generally hate and 
won't dignify by citing), which says, in part,...

	A reference list need be neither exhaustive nor
	normative; a bibliography should be either one or the
	other.  If you have put together a list of all of the
	works of such-and-such a description,..., then you may
	call that a bibliography... But, if your list contains
	nothing more than the sources you have used ... call
	that a reference list.

So, Chicago things that "Bibliography" is the generic term. 
I've certainly never the title "Annotated References", although 
I've seen lots of individual references that are annotated. 
And the other author thinks that we have reference lists and 
shouldn't even consider calling what we put in RFCs 
"bibliographies".  Probably the definitive answer is that the 
RFC Editor has used "References" for as long and as consistently 
as I can remember.

     john

p.s. It turns out that none of the British references I have in 
my collection address this question.  If someone is reading this 
from that side of the pond and can point me to what I should get 
to cure that problem, I'd appreciate it.

From: [email-masked] (Scott W Brim)
Date: Fri, 23 May 2003 10:41:28 -0400
Subject: [xml2rfc] a couple of feature requests
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <20030523144128.GV2128@sbrim-w2k>

On Thu, May 22, 2003 09:15:32AM -0700, Marshall Rose allegedly wrote:
>     STD62 [1-8]
>     
> which refers to 8 contiguous references, you can't.
>     
> the problem is more pronounced when rending targets for sections rather
> than references, e.g., you can't do something like this
>     
>     Sections 1.1-3.2
>     
> so, the enhancement request comes down to being able to turn off
> rendering decorations on xref/eref.

Good idea (although I haven't had a need for it yet).

> - annotating <reference/>
>     
> one of the oldest rfc authors (currently not a subscribre to this list)
> has asked for the ability to annotate references, e.g.,
>     
>    [2]  Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC
>         2223, October 1997.
> 
>         This document is currently under revision. Regardless, please
>         consult Section ...
>     
> personally, i think that a "references" section with annotations is
> really an "annotated bibliography" section. however, since this is the
> core audience talking, we need to consider it.
>     
> comments?

An annotated bibliography still has 90% overlap with the needs of a
references section, so it would be nice if <reference> had this
capability.  <notes>?

From: [email-masked] (Clive D.W. Feather)
Date: Fri, 23 May 2003 07:05:50 +0100
Subject: [xml2rfc] a couple of feature requests
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose said:
> - annotating <reference/>
>     
> one of the oldest rfc authors (currently not a subscribre to this list)
> has asked for the ability to annotate references, e.g.,
>     
>    [2]  Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC
>         2223, October 1997.
> 
>         This document is currently under revision. Regardless, please
>         consult Section ...
>     
> personally, i think that a "references" section with annotations is
> really an "annotated bibliography" section. however, since this is the
> core audience talking, we need to consider it.

It would certainly help me to be able to put "This is the last known URL of
this reference but it no longer works; can anyone provide a new one?" as
an annotation.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646

From: [email-masked] (Marshall Rose)
Date: Thu, 22 May 2003 09:15:32 -0700
Subject: [xml2rfc] a couple of feature requests
Message-ID: <[email-masked]>

hi. i've gotten a couple of notes from folks asking for some feature
enhancements. i'll summarize:
    
- rendering targets
    
right now, when you do something like
    
    <xref target='RFC2629' />
    
it renders like this
    
    [1]
    
(unless you've turned on the symrefs PI).
    
if you want to render something like this
    
    STD62 [1-8]
    
which refers to 8 contiguous references, you can't.
    
the problem is more pronounced when rending targets for sections rather
than references, e.g., you can't do something like this
    
    Sections 1.1-3.2
    
so, the enhancement request comes down to being able to turn off
rendering decorations on xref/eref.

- annotating <reference/>
    
one of the oldest rfc authors (currently not a subscribre to this list)
has asked for the ability to annotate references, e.g.,
    
   [2]  Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC
        2223, October 1997.

        This document is currently under revision. Regardless, please
        consult Section ...
    
personally, i think that a "references" section with annotations is
really an "annotated bibliography" section. however, since this is the
core audience talking, we need to consider it.
    
comments?
    
thanks!

/mtr

From: [email-masked] (Dan Kohn)
Date: Wed, 21 May 2003 10:31:11 -0700
Subject: [xml2rfc] RE: External entity support broke from 5.0R3 to 5.0R4[ALTOVA Case # 3675]
Message-ID: <[email-masked]>

Thank you.  For your reference, I first had to uninstall XMLspy 5r4
first, but 5r3 again correctly supports external entities.

          - dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>

-----Original Message-----
From: Altova Support Team [mailto:[email-masked]] 
Sent: Wednesday, May 21, 2003 02:09
To: Dan Kohn
Subject: RE: External entity support broke from 5.0R3 to 5.0R4[ALTOVA
Case # 3675]

	Hi Dan,

		yes this is a bug and has already been submitted to our
internal bug list.  Please excuse us for any inconveniences incurred.
You can download version 5r3 from our software archive on the following
page:  http://www.xmlspy.com/download_archive.html

Best Regards,

... Christian Luntzer
... Support Manager
... Altova GmbH - markup your mind!

===================================================================
The new ALTOVA product-line: xmlspy 5 - stylevision 5 - authentic 5
Award-winning tools for developers - web designers - business-users
NEW: WebDAV & Delta-V support, Conditional Templates, Dynamic Forms
xsl:fo Designer, WSDL Editing, HTML->XML Migration, XSLT Debugging,
Java/C#/C++ Code Generation, Integration for Oracle 9i, Tamino, CMS
Visit  www.altova.com  to download your free evaluation copy today!
===================================================================

The information transmitted in this message and/or as an attachment
to it  is intended  only for the  person or  entity to  which it is
addressed and may contain confidential  and/or privileged material.
Any  review,  retransmission,  dissemination  or  other use of,  or
taking of any action in reliance upon,  this information by persons
or entities other than the intended recipient is prohibited. If you
received this in error,  please contact  the sender  and delete the
material from any computer.  Altova GmbH  and  Altova, Inc.  do not
accept legal responsibility  for the contents of this message.  Any
views or opinions  presented are solely  those of the author and do
not  necessarily  represent those of  Altova GmbH and  Altova, Inc.
unless otherwise specifically stated. Thank you!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 21 May 2003 02:00
To: Altova Support Team
Subject: External entity support broke from 5.0R3 to 5.0R4[ALTOVA Case #
3675]

Case Number:3675

===============================================================
Customer Information
===============================================================
Name: Daniel Kohn
First Name: Daniel
Last Name: Kohn
Company: private
Key-Code: ff4m60-2DUa2d-PcKMMB-3kTCMD-AuhzC2

http://www.altova.com/internal/tools/keycodesummary.asp?k=ff4m60-2DUa2d-
PcKMMB-3kTCMD-AuhzC2

===============================================================
                               Equipment Information 

===============================================================
Operating System: Windows XP
OS Service Pack: SP1
OS Language: English
IE Version: 6.0
IE service Pack: SP1
Office Version: XP
Office Language: English
Office Service Pack: SP1

===============================================================
                                 Product Information 

===============================================================
Product: XMLSPY Professional Edition
Component: Validation
Version: 5.4

===============================================================
                                 Support Request 

===============================================================
Summary:
 External entity support broke from 5.0R3 to 5.0R4

Description:
 A major market for XML and XMLspy is writing IETF RFCs with RFC 2629
and xml2rfc.  I wrote sample.xml
<http://xml.resource.org/authoring/sample.xml> with XMLspy 5.0R3 to
demonstrate the proper use of external entities.  This file no longer
validates in 5.0R4, apparently because XMLspy doesn't pull in the
external entities.  Of course, this functionality is required by any
compliant validating XML processor.  More info on xml2rfc is at
<http://xml.resource.org/>.

Steps to Reproduce:
  Open either of the two XML attachments (while having the DTD and XSLT
in the same directory).  They open and validate in R3 but not R4.  Note
that with the attached XSLT file, IE6 can correctly open, validate, and
transform both files.

While you're working to fix the bug, can I please get access to a copy
of R3 so as to continue my work?

From: [email-masked] (Henning Schulzrinne)
Date: Tue, 20 May 2003 21:02:48 -0400
Subject: [xml2rfc] XMLspy 5.0R4 seems to break external entities
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Dan Kohn wrote:
> I'm finally responding to Henning Schulzrinne's complaint last week that
> sample.xml didn't load.  XMLspy 5.0R3 worked fine when I authored
> sample.xml (obviously), but having just upgraded to 5.0R4, no XML file
> relying on external entities seems to work.  Of course, I can't confirm
> this because I can't back out the upgrade.  Sample.xml still opens fine
> within IE6.

I've been in touch with Altova's tech support and the fellow did confirm 
this problem, promised to pass it on to their developers, but offered no 
promise of a fix or timeline.

> 
> Has anyone paid for tech support with XMLspy (or purchased the product
> within the last 30 days)?  They say they require this to respond
> (quickly?) to bug reports. How infuriating, after paying $200 for a
> product.  I'm not willing to pay another $80 for support on what is
> patently a bug.

See above; I used my 30-day pre-purchase support :-) However, it would 
probably not hurt if others file the same bug.

> 
> Anyway, here is the bug report I made to them, which I have no guarantee
> that they'll respond to me on:
> 
> External entity support broke from 5.0R3 to 5.0R4
> 
> A major market for XML and XMLspy is writing IETF RFCs with RFC 2629 and
> xml2rfc.  I wrote sample.xml
> <http://xml.resource.org/authoring/sample.xml> with XMLspy 5.0R3 to
> demonstrate the proper use of external entities.  This file no longer
> validates in 5.0R4, apparently because XMLspy doesn't pull in the
> external entities.  Of course, this functionality is required by any
> compliant validating XML processor.  More info on xml2rfc is at
> <http://xml.resource.org/>.
> 
> Open sample.xml (while having the rfc2629.dtd in the same directory).
> They open and validate in R3 but not R4.  Note that with rfc2629.xslt,
> IE6 can correctly open, validate, and transform both files.
> 
>           - dan
> --
> Dan Kohn <mailto:[email-masked]>
> <http://www.dankohn.com/>  <tel:+1-650-327-2600>
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc

From: [email-masked] (Fred Baker)
Date: Tue, 20 May 2003 17:24:58 -0700
Subject: [xml2rfc] xml2rfc 1.19 bug report
In-Reply-To: <[email-masked]. ca.us>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

At 11:03 AM 5/20/2003 -0700, Marshall Rose wrote:
>if you're running xml2rfc on your own system, here's a patch.

thanks much 

From: [email-masked] (Dan Kohn)
Date: Tue, 20 May 2003 17:20:24 -0700
Subject: [xml2rfc] XMLspy 5.0R4 seems to break external entities
Message-ID: <[email-masked]>

I'm finally responding to Henning Schulzrinne's complaint last week that
sample.xml didn't load.  XMLspy 5.0R3 worked fine when I authored
sample.xml (obviously), but having just upgraded to 5.0R4, no XML file
relying on external entities seems to work.  Of course, I can't confirm
this because I can't back out the upgrade.  Sample.xml still opens fine
within IE6.

Has anyone paid for tech support with XMLspy (or purchased the product
within the last 30 days)?  They say they require this to respond
(quickly?) to bug reports. How infuriating, after paying $200 for a
product.  I'm not willing to pay another $80 for support on what is
patently a bug.

Anyway, here is the bug report I made to them, which I have no guarantee
that they'll respond to me on:

External entity support broke from 5.0R3 to 5.0R4

A major market for XML and XMLspy is writing IETF RFCs with RFC 2629 and
xml2rfc.  I wrote sample.xml
<http://xml.resource.org/authoring/sample.xml> with XMLspy 5.0R3 to
demonstrate the proper use of external entities.  This file no longer
validates in 5.0R4, apparently because XMLspy doesn't pull in the
external entities.  Of course, this functionality is required by any
compliant validating XML processor.  More info on xml2rfc is at
<http://xml.resource.org/>.

Open sample.xml (while having the rfc2629.dtd in the same directory).
They open and validate in R3 but not R4.  Note that with rfc2629.xslt,
IE6 can correctly open, validate, and transform both files.

          - dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>

From: [email-masked] (Marshall Rose)
Date: Tue, 20 May 2003 11:03:04 -0700
Subject: [xml2rfc] xml2rfc 1.19 bug report
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> So when I click on the "updates" link, it connects to ftp.isi.edu and
> download the file
> 
> 	/pub/in-notes/rfc2827 (if approved).txt
> 
> oops...

indeed.
    
most amusing. and easy to fix.
    
if you're running xml2rfc on your own system, here's a patch.
    
if you're using the web-based service, let me know, and i'll update it today...
    
/mtr
    
*** _xml2rfc.tcl	Thu May 15 13:57:45 2003
--- xml2rfc.tcl	Tue May 20 10:59:39 2003
***************
*** 9211,9216 ****
--- 9211,9223 ----
          set start ""
      }
  
+     if {[set y [string first " (" $line]] >= 0} {
+         set tail [string range $line $y end]
+         set line [string range $line 0 [expr $y-1]]
+     } else {
+         set tail ""
+     }
+ 
      set s ""
      foreach n [split $line ,] {
          set n [string trim $n]
***************
*** 9218,9224 ****
          set s ", "
      }
  
!     return $start
  }
  
  proc write_url {url} {
--- 9225,9231 ----
          set s ", "
      }
  
!     return $start$tail
  }
  
  proc write_url {url} {

From: [email-masked] ([email-masked])
Date: Tue, 20 May 2003 10:13:01 -0700 (PDT)
Subject: [xml2rfc] xml2rfc 1.19 bug report
Message-ID: <[email-masked]>

So I happened to notice this:

I specified

<rfc ipr="full2026" category="exp"
docName="draft-ymbk-bcp38-multihoming-update-00" updates="2827">

In the HTML version, I see:

<tr valign="top"><td width="33%" bgcolor="#666666" class="header">Updates:<a href='ftp://ftp.isi.edu/in-notes/rfc2827 (if approved).txt'>2827 (if approved)</a></td><td width="33%" bgcolor="#666666" class="header">P. Savola</td></tr>

So when I click on the "updates" link, it connects to ftp.isi.edu and download
the file

	/pub/in-notes/rfc2827 (if approved).txt

oops...

sample xml file on request.

From: [email-masked] (Julian Reschke)
Date: Wed, 14 May 2003 22:20:23 +0200
Subject: [xml2rfc] sample.xml and XML Spy
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Henning
> Schulzrinne
> Sent: Wednesday, May 14, 2003 10:05 PM
> To: Marshall Rose
> Cc: [email-masked]
> Subject: Re: [xml2rfc] sample.xml and XML Spy
>
>
> > good question. i haven't used xmlspy in a few years, so i probably can't
> > be much help. but here's some generic stuff:
> >
> > put rfc2629.dtd and rfc2629.xslt in the same directory as sample.xml
>
> Tried this; works for the dtd, but not for the ENTITY.

Works for me.

> ...

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

From: [email-masked] (Henning Schulzrinne)
Date: Wed, 14 May 2003 16:04:55 -0400
Subject: [xml2rfc] sample.xml and XML Spy
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> good question. i haven't used xmlspy in a few years, so i probably can't
> be much help. but here's some generic stuff:
>     
> put rfc2629.dtd and rfc2629.xslt in the same directory as sample.xml

Tried this; works for the dtd, but not for the ENTITY.

>     
> see if there are any "Security" options, etc., that might disable
> retrieval of external entities.

I set Internet options to the lowest security setting; seems to make no 
difference.

Thanks for the suggestions.

From: [email-masked] (Marshall Rose)
Date: Wed, 14 May 2003 13:03:49 -0700
Subject: [xml2rfc] sample.xml and XML Spy
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

This is a multi-part message in MIME format.

--Multipart_Wed__14_May_2003_13:03:50_-0700_08ac6200
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

> I tried to validate sample.xml with XML Spy (5.0)
> 
> Even after changing the DTD reference (the one expected in 
> http://xml.resource.org/authoring/rfc2629.dtd) to something that works, 
> XML Spy can't seem to resolve any of the entity references, such as
> 
> <!DOCTYPE rfc [
> <!ENTITY rfc2119 PUBLIC ''
>        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
> ]>
> 
> Any suggestions on what I'm doing wrong?

good question. i haven't used xmlspy in a few years, so i probably can't
be much help. but here's some generic stuff:
    
put rfc2629.dtd and rfc2629.xslt in the same directory as sample.xml
    
see if there are any "Security" options, etc., that might disable
retrieval of external entities.
    
sorry i'm not of more help.
    
/mtr
    
ps: i also made a couple of small changes to sample.xml
(attached). maybe that will help too...

--Multipart_Wed__14_May_2003_13:03:50_-0700_08ac6200
Content-Type: text/xml;
 name="sample.xml"
Content-Disposition: attachment;
 filename="sample.xml"
Content-Transfer-Encoding: 7bit

<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2119 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>

<rfc category="std" ipr="full2026" docName="sample.txt">
    <front>
        <title>An Example</title>
        <author initials='A.Y' surname="Mous" fullname='Anon Y. Mous'>
            <organization/>
        </author>
        <date month="March" year="2003"/>
        <abstract><t>An example.</t></abstract>
    </front>

    <middle>
        <section title="Requirements notation">
            <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
            "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
            and "OPTIONAL" in this document are to be interpreted as
            described in <xref target="RFC2119"/>.</t>
        </section>

        <section title="Security Considerations">
        <t>None.</t>
        </section>
    </middle>

    <back>
        <references>&rfc2119;</references>
    </back>

</rfc>

--Multipart_Wed__14_May_2003_13:03:50_-0700_08ac6200--

From: [email-masked] (Henning Schulzrinne)
Date: Wed, 14 May 2003 14:48:27 -0400
Subject: [xml2rfc] sample.xml and XML Spy
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

I tried to validate sample.xml with XML Spy (5.0)

Even after changing the DTD reference (the one expected in 
http://xml.resource.org/authoring/rfc2629.dtd) to something that works, 
XML Spy can't seem to resolve any of the entity references, such as

<!DOCTYPE rfc [
<!ENTITY rfc2119 PUBLIC ''
       'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>

Any suggestions on what I'm doing wrong?

Thanks.

From: [email-masked] (Marshall Rose)
Date: Wed, 14 May 2003 10:00:16 -0700
Subject: [xml2rfc] anchor in textable
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> If I remove the anchor attribute in the texttable, both .txt and .html are 
> correctly generated.
> 
> Any idea what is wrong?

yes, what's wrong is that my regression tests didn't cover that
permutation.
    
i'll update the web-based service in an hour or so. if you are running
it on your own system. here's a patch.

*** _xml2rfc.tcl	Tue May 13 17:10:40 2003
--- xml2rfc.tcl	Wed May 14 09:58:08 2003
***************
*** 7245,7251 ****
  }
  
  proc texttable_html {tag lines anchor title {didP 0}} {
!     global counter depth elemN elem passno stack xref
  
      switch -- $tag {
          begin {
--- 7245,7251 ----
  }
  
  proc texttable_html {tag lines anchor title {didP 0}} {
!     global stdout
  
      switch -- $tag {
          begin {

From: [email-masked] (Miguel A. Garcia)
Date: Wed, 14 May 2003 14:29:20 +0300
Subject: [xml2rfc] Figure differences
References: <[email-masked]>
Message-ID: <[email-masked]>

Julian:

Did you have anchor attributes in the figure element?

I do have anchor attributes in some figures, and the caption is only 
created in the .txt, but not the .html.

/Miguel

Julian Reschke wrote:
> s/valid/present/.
> 
> BTW: I just looked at a TXT that I created two days ago, and sure enough, it
> doesn't have captions for the figures:
> 
> <http://www.ietf.org/internet-drafts/draft-ietf-webdav-ordering-protocol-08.
> txt>
> 
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 
> 
>>-----Original Message-----
>>From: [email-masked]
>>[mailto:[email-masked]]On Behalf Of Julian Reschke
>>Sent: Wednesday, May 14, 2003 1:11 PM
>>To: Miguel A. Garcia; [email-masked]
>>Subject: RE: [xml2rfc] Figure differences
>>
>>
>>I prefer the other way around -- a caption should only be valid when
>>requested.
>>
>>--
>><green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>>
>>
>>>-----Original Message-----
>>>From: [email-masked]
>>>[mailto:[email-masked]]On Behalf Of Miguel A.
>>>Garcia
>>>Sent: Wednesday, May 14, 2003 1:08 PM
>>>To: [email-masked]
>>>Subject: [xml2rfc] Figure differences
>>>
>>>
>>>Hi:
>>>
>>>In XML2RFC 1.18 I have noticed a difference in the treatment of figures
>>>between the .txt and the .html versions.
>>>
>>>In the .txt file, there is a caption for every figure, saying
>>
>>"Figure x",
>>
>>>where x is the figure number. However, there is not such caption in the
>>>.html file.
>>>
>>>I believe this is a bug: the .html file should contain a
>>
>>caption as well,
>>
>>>indicating the figure number.
>>>
>>>Any views?
>>>
>>>/Miguel
>>>--
>>>Miguel-Angel Garcia                     Oy LM Ericsson AB
>>>                                         Jorvas, Finland
>>>mailto:[email-masked]     Phone:  +358 9 299 3553
>>>mailto:[email-masked]        Mobile: +358 40 5140002
>>>
>>>
>>>
>>>
>>>
>>>_______________________________________________
>>>xml2rfc mailing list
>>>[email-masked]
>>>http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>>>
>>
>>_______________________________________________
>>xml2rfc mailing list
>>[email-masked]
>>http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>>
> 

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                         Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002

From: [email-masked] (Julian Reschke)
Date: Wed, 14 May 2003 13:21:30 +0200
Subject: [xml2rfc] Figure differences
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

s/valid/present/.

BTW: I just looked at a TXT that I created two days ago, and sure enough, it
doesn't have captions for the figures:

<http://www.ietf.org/internet-drafts/draft-ietf-webdav-ordering-protocol-08.
txt>

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

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Julian Reschke
> Sent: Wednesday, May 14, 2003 1:11 PM
> To: Miguel A. Garcia; [email-masked]
> Subject: RE: [xml2rfc] Figure differences
>
>
> I prefer the other way around -- a caption should only be valid when
> requested.
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Miguel A.
> > Garcia
> > Sent: Wednesday, May 14, 2003 1:08 PM
> > To: [email-masked]
> > Subject: [xml2rfc] Figure differences
> >
> >
> > Hi:
> >
> > In XML2RFC 1.18 I have noticed a difference in the treatment of figures
> > between the .txt and the .html versions.
> >
> > In the .txt file, there is a caption for every figure, saying
> "Figure x",
> > where x is the figure number. However, there is not such caption in the
> > .html file.
> >
> > I believe this is a bug: the .html file should contain a
> caption as well,
> > indicating the figure number.
> >
> > Any views?
> >
> > /Miguel
> > --
> > Miguel-Angel Garcia                     Oy LM Ericsson AB
> >                                          Jorvas, Finland
> > mailto:[email-masked]     Phone:  +358 9 299 3553
> > mailto:[email-masked]        Mobile: +358 40 5140002
> >
> >
> >
> >
> >
> > _______________________________________________
> > xml2rfc mailing list
> > [email-masked]
> > http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> >
>
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>

From: [email-masked] (Miguel A. Garcia)
Date: Wed, 14 May 2003 14:20:16 +0300
Subject: [xml2rfc] Figure differences
References: <[email-masked]>
Message-ID: <[email-masked]>

Well, to me the presence of the anchor attribute in the figure element 
should be more than enough to indicate the requirement of a caption. I 
believe that if you need to refer in the text to the figure (anchor 
attribute present in figure), a caption should be always present.

If you don't need to refer in the text to the figure, then don't create an 
anchor, and a caption is not needed.

/Miguel

Julian Reschke wrote:
> I prefer the other way around -- a caption should only be valid when
> requested.
> 
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 
> 
>>-----Original Message-----
>>From: [email-masked]
>>[mailto:[email-masked]]On Behalf Of Miguel A.
>>Garcia
>>Sent: Wednesday, May 14, 2003 1:08 PM
>>To: [email-masked]
>>Subject: [xml2rfc] Figure differences
>>
>>
>>Hi:
>>
>>In XML2RFC 1.18 I have noticed a difference in the treatment of figures
>>between the .txt and the .html versions.
>>
>>In the .txt file, there is a caption for every figure, saying "Figure x",
>>where x is the figure number. However, there is not such caption in the
>>.html file.
>>
>>I believe this is a bug: the .html file should contain a caption as well,
>>indicating the figure number.
>>
>>Any views?
>>
>>/Miguel
>>--
>>Miguel-Angel Garcia                     Oy LM Ericsson AB
>>                                         Jorvas, Finland
>>mailto:[email-masked]     Phone:  +358 9 299 3553
>>mailto:[email-masked]        Mobile: +358 40 5140002
>>
>>
>>
>>
>>
>>_______________________________________________
>>xml2rfc mailing list
>>[email-masked]
>>http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>>
> 

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                         Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002

From: [email-masked] (Julian Reschke)
Date: Wed, 14 May 2003 13:11:02 +0200
Subject: [xml2rfc] Figure differences
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

I prefer the other way around -- a caption should only be valid when
requested.

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

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Miguel A.
> Garcia
> Sent: Wednesday, May 14, 2003 1:08 PM
> To: [email-masked]
> Subject: [xml2rfc] Figure differences
>
>
> Hi:
>
> In XML2RFC 1.18 I have noticed a difference in the treatment of figures
> between the .txt and the .html versions.
>
> In the .txt file, there is a caption for every figure, saying "Figure x",
> where x is the figure number. However, there is not such caption in the
> .html file.
>
> I believe this is a bug: the .html file should contain a caption as well,
> indicating the figure number.
>
> Any views?
>
> /Miguel
> --
> Miguel-Angel Garcia                     Oy LM Ericsson AB
>                                          Jorvas, Finland
> mailto:[email-masked]     Phone:  +358 9 299 3553
> mailto:[email-masked]        Mobile: +358 40 5140002
>
>
>
>
>
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>

From: [email-masked] (Miguel A. Garcia)
Date: Wed, 14 May 2003 14:08:13 +0300
Subject: [xml2rfc] Figure differences
Message-ID: <[email-masked]>

Hi:

In XML2RFC 1.18 I have noticed a difference in the treatment of figures 
between the .txt and the .html versions.

In the .txt file, there is a caption for every figure, saying "Figure x", 
where x is the figure number. However, there is not such caption in the 
.html file.

I believe this is a bug: the .html file should contain a caption as well, 
indicating the figure number.

Any views?

/Miguel
-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                         Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002

From: [email-masked] (Miguel A. Garcia)
Date: Wed, 14 May 2003 13:50:38 +0300
Subject: [xml2rfc] anchor in textable
Message-ID: <[email-masked]>

I am doing my first experiment with tables, and XML2RFC 1.18 is giving me a 
heacache.

The XML I have written for the table is pretty simple:

<texttable anchor='mytable'>
<ttcol>Command Name</ttcol>
<ttcol>Abbr.</ttcol>
<ttcol>Code</ttcol>
<ttcol>Reference</ttcol>
<c>Push-Profile-Request</c>             <c>PPR</c> <c>fff</c> <c> TBD </c>
<c>Push-Profile-Answer</c>              <c>PPA</c> <c>fff</c> <c> TBD </c>
</texttable>

If I generate the .txt file, everything goes fine. But if I try to generate 
the .html file, then it fails. The error I get is:

can't read "stdout": no such variable around line 384

If I remove the anchor attribute in the texttable, both .txt and .html are 
correctly generated.

Any idea what is wrong?

/Miguel

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                         Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002

From: [email-masked] (Marshall Rose)
Date: Tue, 13 May 2003 15:34:37 -0700
Subject: [xml2rfc] newbie question: funny error when converting using xml2rfc.tcl
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> I'm playing with xml2rfc.tcl and am getting a funny error when I try
> to convert rfc2629.xml.  A window opens up saying 
> 
>    "can't use non-numeric string as operand of " "
> 
>    Context:
>      <rfc number="2629">
>      <front>
> 
> I'm trying to run this on a shared, somewhat strangely configured
> SunOS server but it does seem to be running TCL 8.0.  The simple
> diagnostics in README work as they are supposed to.  Any hints?

hi. my rough guess is that tcl 8.0 is too early (it came out in august '97).
however, i've done some work making xml2rfc work with early tcls.
    
what i will do is send you a special version in another email with
instructions how to run it. it will provide better diagnostics. it may
take a couple of interations to get to the bottom of it...
    
/mtr

    

From: [email-masked] (Aaron Falk)
Date: Tue, 13 May 2003 15:30:38 -0700
Subject: [xml2rfc] newbie question: funny error when converting using xml2rfc.tcl
Message-ID: <[email-masked]>

Hi-

I'm playing with xml2rfc.tcl and am getting a funny error when I try
to convert rfc2629.xml.  A window opens up saying 

   "can't use non-numeric string as operand of " "

   Context:
     <rfc number="2629">
     <front>

I'm trying to run this on a shared, somewhat strangely configured
SunOS server but it does seem to be running TCL 8.0.  The simple
diagnostics in README work as they are supposed to.  Any hints?

--aaron

From: [email-masked] (Henning Schulzrinne)
Date: Tue, 13 May 2003 16:07:27 -0400
Subject: [xml2rfc] 1.18 DTD fails with IE 6.0
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Thanks for the quick and helpful response. Now works, except for the 
problem in the external entity reference in sample.xml (complains about 
access denied, even though I can wget the exact same URL).

Julian Reschke wrote:

> Actually, there were *two* issues. See attached version.
> 
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 
> 

From: [email-masked] (Marshall Rose)
Date: Tue, 13 May 2003 12:56:49 -0700
Subject: [xml2rfc] 1.18 DTD fails with IE 6.0
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

This is a multi-part message in MIME format.

--Multipart_Tue__13_May_2003_12:56:49_-0700_089d9100
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

> Actually, there were *two* issues. See attached version.

julian - true.

henning - use the versoin that julian sent (or the attached, if you've already
his email).

/mtr

--Multipart_Tue__13_May_2003_12:56:49_-0700_089d9100
Content-Type: application/octet-stream;
 name="rfc2629.dtd"
Content-Disposition: attachment;
 filename="rfc2629.dtd"
Content-Transfer-Encoding: base64

--Multipart_Tue__13_May_2003_12:56:49_-0700_089d9100--

From: [email-masked] (Julian Reschke)
Date: Tue, 13 May 2003 21:53:22 +0200
Subject: [xml2rfc] 1.18 DTD fails with IE 6.0
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

This is a multi-part message in MIME format.

------=_NextPart_000_0011_01C3199A.12A188A0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Actually, there were *two* issues. See attached version.

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

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Marshall Rose
> Sent: Tuesday, May 13, 2003 9:42 PM
> To: Henning Schulzrinne
> Cc: [email-masked]
> Subject: Re: [xml2rfc] 1.18 DTD fails with IE 6.0
> 
> 
> > <!-- later on, may be (section+,appendix*,section*)>
> 
> oops! i need better qa. change that line to:
>     
>     <!-- later on, may be (section+,appendix*,section*) -->
>     
> and you should be good to go.
>     
> /mtr
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 
------=_NextPart_000_0011_01C3199A.12A188A0
Content-Type: text/xml;
	name="rfc2629.dtd"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="rfc2629.dtd"

<!--
  revised DTD for the RFC document series, draft of 2002-07-13
  -->

<!--
  Contents

    DTD data types

    The top-level

    Front matter

    The Body

    Back matter
  -->

<!--
  DTD data types:

        entity        description
        ======        ===============================================
        NUMBER        [0-9]+
        NUMBERS       a comma-separated list of NUMBER

        DAY           the day of the month, e.g., "1"
        MONTH         the month of the year, e.g., "January"
        YEAR          a four-digit year, e.g., "1999"

        URI           e.g., "http://invisible.net/"

        ATEXT/CTEXT   printable ASCII text (no line-terminators)

        TEXT          character data
  -->

<!ENTITY % NUMBER     "CDATA">
<!ENTITY % NUMBERS    "CDATA">

<!ENTITY % DAY        "CDATA">
<!ENTITY % MONTH      "CDATA">
<!ENTITY % YEAR       "CDATA">

<!ENTITY % URI        "CDATA">

<!ENTITY % ATEXT      "CDATA">
<!ENTITY % CTEXT      "#PCDATA">

<!ENTITY % TEXT       "#PCDATA">

<!ENTITY   rfc.number "XXXX">

<!--
  The top-level
  -->

<!--
  attributes for the "rfc" element are supplied by the RFC
  editor. when preparing drafts, authors should leave them blank.

  the "seriesNo" attribute is used if the category is, e.g., BCP.
  -->
<!ELEMENT rfc         (front,middle,back?)>
<!ATTLIST rfc
          number      %NUMBER;           #IMPLIED
          obsoletes   %NUMBERS;          ""
          updates     %NUMBERS;          ""
          category    (std|bcp|info|exp|historic)
                                         "info"
          seriesNo    %NUMBER;           #IMPLIED
          ipr         (full2026|noDerivativeWorks2026|none)
                                         #IMPLIED
          docName     %ATEXT;            #IMPLIED> 

<!--
  Front matter
  -->

<!ELEMENT front       (title,author+,date,area*,workgroup*,keyword*,
                       abstract?,note*)>

<!-- the "abbrev" attribute is used for headers, etc. -->
<!ELEMENT title       (%CTEXT;)>
<!ATTLIST title
          abbrev      %ATEXT;            #IMPLIED> 

<!ELEMENT author      (organization,address?)>
<!ATTLIST author
          initials    %ATEXT;            #IMPLIED
          surname     %ATEXT;            #IMPLIED
          fullname    %ATEXT;            #IMPLIED
          role        (editor)           #IMPLIED>

<!ELEMENT organization
                      (%CTEXT;)>
<!ATTLIST organization
          abbrev      %ATEXT;            #IMPLIED> 
 
<!ELEMENT address     (postal?,phone?,facsimile?,email?,uri?)>

<!-- at most one of each the city, region, code, and country
     elements may be present -->
<!ELEMENT postal      (street+,(city|region|code|country)*)>
<!ELEMENT street      (%CTEXT;)>
<!ELEMENT city        (%CTEXT;)>
<!ELEMENT region      (%CTEXT;)>
<!ELEMENT code        (%CTEXT;)>
<!ELEMENT country     (%CTEXT;)>
<!ELEMENT phone       (%CTEXT;)>
<!ELEMENT facsimile   (%CTEXT;)>
<!ELEMENT email       (%CTEXT;)>
<!ELEMENT uri         (%CTEXT;)>

<!ELEMENT date        EMPTY>
<!ATTLIST date
          day         %DAY;              #IMPLIED
          month       %MONTH;            #IMPLIED
          year        %YEAR;             #REQUIRED>

<!-- meta-data... -->
<!ELEMENT area        (%CTEXT;)>
<!ELEMENT workgroup   (%CTEXT;)>
<!ELEMENT keyword     (%CTEXT;)>

<!ELEMENT abstract    (t)+>
<!ELEMENT note        (t)+>
<!ATTLIST note
          title       %ATEXT;            #REQUIRED>

<!--
  The body
  -->

<!-- later on, may be (section+,appendix*,section*)> -->
<!ELEMENT middle      (section+)>

<!ELEMENT section     (t|figure|texttable|iref|section)*>
<!ATTLIST section
          anchor      ID                 #IMPLIED
          title       %ATEXT;            #REQUIRED>

<!--
<!ELEMENT appendix    (t|figure|texttable|iref|appendix)*>
<!ATTLIST appendix
          anchor      ID                 #IMPLIED
          title       %ATEXT;            #REQUIRED>
  -->

<!-- use of <figure/> is deprecated... -->
<!ELEMENT t           (%TEXT;|list|figure|xref|eref|iref|spanx|vspace)*>
<!ATTLIST t
          hangText    %ATEXT;            #IMPLIED>

<!-- the value of the style attribute is inherited from the closest 
     parent -->
<!ELEMENT list        (t+)>
<!ATTLIST list
          style       %ATEXT;            "empty"
          hangIndent  %NUMBER;           "0"
          counter     %ATEXT;            #IMPLIED>

<!ELEMENT xref        (%CTEXT;)>
<!ATTLIST xref
          target      IDREF              #REQUIRED
          pageno      (true|false)       "false">

<!ELEMENT eref        (%CTEXT;)>
<!ATTLIST eref
          target      %URI;              #REQUIRED>

<!ELEMENT iref        EMPTY>
<!ATTLIST iref
          item        %ATEXT;            #REQUIRED
          subitem     %ATEXT;            ""
          primary    (true|false)       "false">

<!ELEMENT spanx       (%CTEXT;)>
<!ATTLIST spanx
          xml:space   (default|preserve) "preserve"
          style       %ATEXT;            "emph">

<!ELEMENT vspace      EMPTY>
<!ATTLIST vspace
          blankLines  %NUMBER;           "0">

<!ELEMENT figure      (preamble?,artwork,postamble?)>
<!ATTLIST figure
          anchor      ID                 #IMPLIED
          title       %ATEXT;            "">

<!ELEMENT preamble    (%TEXT;|xref|eref|iref)*>
<!ELEMENT artwork     (%TEXT;)*>
<!ATTLIST artwork
          xml:space   (default|preserve) "preserve"
          name        %ATEXT;            ""
          type        %ATEXT;            ""
          src         %URI;              ""
          width       %ATEXT;            ""
          height      %ATEXT;            "">

<!ELEMENT postamble   (%TEXT;|xref|eref|iref)*>
    
<!ELEMENT texttable   (preamble?,ttcol+,c*,postamble?)>
<!ATTLIST texttable
          anchor      ID                 #IMPLIED
          title       %ATEXT;            "">
<!ELEMENT ttcol       (%CTEXT;)>
<!ATTLIST ttcol
          width       %ATEXT;           #IMPLIED
          align       (left|center|right) "left">
<!ELEMENT c           (%TEXT;|xref|eref|iref)*>

<!--
  Back matter
  -->

<!-- sections, if present, are appendices -->
<!ELEMENT back        (references*,section*)>

<!ELEMENT references  (reference+)>
<!ATTLIST references
          title       %ATEXT;            "References">
<!ELEMENT reference   (front,seriesInfo*,format*)>
<!ATTLIST reference
          anchor      ID                 #IMPLIED
          target      %URI;              #IMPLIED>
<!ELEMENT seriesInfo  EMPTY>
<!ATTLIST seriesInfo
          name        %ATEXT;            #REQUIRED
          value       %ATEXT;            #REQUIRED>
<!ELEMENT format      EMPTY>
<!ATTLIST format
          target      %URI;              #IMPLIED
          type        %ATEXT;            #REQUIRED
          octets      %NUMBER;           #IMPLIED>

------=_NextPart_000_0011_01C3199A.12A188A0--

From: [email-masked] (Marshall Rose)
Date: Tue, 13 May 2003 12:42:06 -0700
Subject: [xml2rfc] 1.18 DTD fails with IE 6.0
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> <!-- later on, may be (section+,appendix*,section*)>

oops! i need better qa. change that line to:
    
    <!-- later on, may be (section+,appendix*,section*) -->
    
and you should be good to go.
    
/mtr

From: [email-masked] (Henning Schulzrinne)
Date: Tue, 13 May 2003 15:11:14 -0400
Subject: [xml2rfc] 1.18 DTD fails with IE 6.0
Message-ID: <[email-masked]>

Labeled as:

Revised DTD for the RFC document series, draft of 2002-07-13

The XML page cannot be displayed
Cannot view XML input using style sheet. Please correct the error and 
then click the Refresh button, or try again later.

Incorrect syntax was used in a comment. Error processing resource 
'http://www.cs.columbia.edu/~hgs/nsis/gimps/rfc2629.dtd'. Line 144, 
Position 272

<!-- later on, may be (section+,appendix*,section*)>

From: [email-masked] (Julian Reschke)
Date: Mon, 12 May 2003 10:59:48 +0200
Subject: [xml2rfc] ANN: XSLT for xml2rfc 1.18, CHM format
Message-ID: <[email-masked]>

Hi,

the XSLT [1] now supports the new xml2rfc features, also support for some
Processing Instructions was added/updated. In addition, I've enhanced
creation of HTML META and LINK tags (in Mozilla: enable View -> Show/Hide ->
Site Navigation Bar), and fixed some of the HTML conformance problems.

I'm also experimenting with creating Microsoft HTML Help files, which
(beside the drawback of having a proprietary format) ship compressed and
have some nice TOC/IIndex navigation features. See example at [2]. I'll
publish the code at a later point of time (interested people please email
me).

Regards, Julian

[1] <http://greenbytes.de/tech/webdav/rfc2629.xslt>
[2] <http://greenbytes.de/tech/webdav/rfc2396.chm>

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

From: [email-masked] (Graham Klyne)
Date: Thu, 08 May 2003 14:41:37 +0100
Subject: [xml2rfc] rules for rules in tables
In-Reply-To: <[email-masked]. ca.us>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

At 11:00 07/05/2003 -0700, Marshall Rose wrote:
>the more i think about this, i think there should be only three choices:
>
>     none, headers, cells
>
>anything else seems to fall into "makes it complete, but won't be used".

I think what you propose is a sweet spot.  I can't imagine a use for the 
other cases where one of the above wouldn't do just fine.

#g

-------------------
Graham Klyne
<[email-masked]>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E

From: [email-masked] (Clive D.W. Feather)
Date: Thu, 8 May 2003 14:39:31 +0100
Subject: [xml2rfc] Re: Table of contents
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

I wrote:
> Is there any way to specify that a section should be excluded from the TOC?
> I've got a TOC which is now about three pages long. Unfortunately, simply
> limiting the depth isn't sufficient, because of the particular structure of
> this document. What I want to do is to omit some bottom-level <section>s
> from tbe TOC.
> 
> In other words, something like <section intoc="no">.

This turned out - once I remembered how TCL worked - to be very easy:

In the DTD:

  <!ELEMENT section     (t|figure|iref|section)*>
  <!ATTLIST section
+           intoc       (true|false)       "true"
            anchor      ID                 #IMPLIED
            title       %ATEXT;            #REQUIRED>

In the 1.17 code:

*** 4041,4041 ****
!                     lappend toc [list $label $cv(title) $cv(.ANCHOR)]
--- 4041,4046 ----
!                     if {[catch {set putintoc $cv(intoc)}]} {
!                         set putintoc true
!                     }
!                     if {![string compare $putintoc true]} {
!                         lappend toc [list $label $cv(title) $cv(.ANCHOR)]
!                     }
***************

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646

From: [email-masked] (Marshall Rose)
Date: Wed, 7 May 2003 13:49:45 -0700
Subject: [xml2rfc] adding (editor)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> I was thinking along the lines of
> 
> <!ATTLIST author  role (editor) #IMPLIED >
> 
> (not sure about whether this is legal DTD speak)

yes, that's fine.
    
/mtr

From: [email-masked] (Chris Newman)
Date: Wed, 07 May 2003 12:30:12 -0700
Subject: [xml2rfc] rules for rules in tables
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

I've been thinking about this some more and worrying about all the propose 
feature-creep surrounding <texttable> and I just changed my mind on this issue. 
I believe we should not add the "rules" attribute and that tables should always 
have borders.

Tables in HTML are used for two purposes: 1. to format tabular data and 2. for 
document layout.  Most of the complexity of HTML tables is related to the use 
of tables for document layout, and most of that complexity is now redundant 
with cascading style sheets which is a better architecture for that kind of 
style preference (albeit less useful in practice because it deployed later). 
At least the complexity in CSS has the advantage of being a separate layer from 
HTML, whereas the complexity in HTML tables is there for all to suffer.

The best feature of RFC 2629 is the simplicity of the format, and we have to be 
vigilant to prevent feature creep.  What made 2629 so valuable to me at first 
was that I could read the entire RFC in about 1/2 hour and start writing an RFC 
using it.  We need to be kind to future adoption by holding the line on 
features.  We need to aim for no more than an 85%-90% solution for RFC 
authoring to keep that valuable quality.

So I propose a rule-of-thumb to limit new features:

  Any proposed new feature related to style or layout rather than structure
  of the document should be deferred to a separate style-sheet facility that
  is not part of the core 2629 format.

The "rules" attribute fails that litmus test.  Furthermore, I believe the 
default behavior should be to put borders around the tables because that will 
prevent people from using <texttable> for document layout and limit its use to 
true tabular data.

                - Chris

begin  quotation by Marshall Rose on 2003/5/7 7:58 -0700:

> i suggest that the following attribute be added to the <texttable/>
> element:
>
>     <!ATTLIST texttable    rules    (none|header|rows|cols|all)    "none">
>
> where:
>
>     none: No rules.
>     header: Rules will appear the headers and their columns
>     rows: Rules will appear between rows only.
>     cols: Rules will appear between columns only.
>     all: Rules will appear between all rows and columns.
>
> comments?
>
> /mtr
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc

From: [email-masked] (Chris Newman)
Date: Wed, 07 May 2003 12:02:21 -0700
Subject: [xml2rfc] rules for rules in tables
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Sounds good to me.

                - Chris

begin  quotation by Marshall Rose on 2003/5/7 11:00 -0700:

> the more i think about this, i think there should be only three choices:
>
>     none, headers, cells
>
> anything else seems to fall into "makes it complete, but won't be used".
>
> /mtr
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc

From: [email-masked] (Marshall Rose)
Date: Wed, 7 May 2003 11:00:35 -0700
Subject: [xml2rfc] rules for rules in tables
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

the more i think about this, i think there should be only three choices:
    
    none, headers, cells

anything else seems to fall into "makes it complete, but won't be used".
    
/mtr

From: [email-masked] (Henrik Levkowetz)
Date: Wed, 7 May 2003 18:15:19 +0200
Subject: [xml2rfc] adding (editor)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 7 May 2003 17:12:35 +0200
"Julian Reschke" <[email-masked]> wrote:

> I think for now an optional role attribute with a single allowed value
> ("editor") makes most sense. This takes care of Scott's immediate needs, is
> extensible, yet avoids having people put in things they shouldn't.

No, let the value filtering be taken care of on some other level. You
don't want to have to twiddle xml2rfc to adapt to every little change in
style. Recent RFCs have consistently used ", Ed.", but if Scott wants
"(editor)" and someone else wants ", Editor" etc., that's fine with me,
and the tool should'n have to care.

	Henrik

-- 
  "I was recently on a tour of Latin America, and the only regret I
  have was that I didn't study Latin harder in school so I could
  converse with those people."  
    -- J. Danforth Quayle

From: [email-masked] (Henrik Levkowetz)
Date: Wed, 7 May 2003 18:09:16 +0200
Subject: [xml2rfc] adding (editor)
In-Reply-To: <[email-masked]>
References: <20030507133512.GD2136@sbrim-w2k> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 7 May 2003 07:55:19 -0700
Marshall Rose <[email-masked]> wrote:

> if we go for a "suffix", then i suppose folks can also do things like
> "Sr.", "III", and (inevitably) "Ph.D.".
>     
> if we go for a "role", then we can probably have things like "editor",
> "chair", etc.

Suits me. 

> or, we can do the extraordinarily myoptic fix which is to add this
> attribute to the <author/> element
>     
> 	<!ATTLIST author    editor    (true|false)    "true">

	Henrik

-- 
  This is the first age that's paid much attention to the future, which
  is a little ironic since we may not have one. 
    -- Arthur Clarke 

From: [email-masked] (Julian Reschke)
Date: Wed, 7 May 2003 18:05:23 +0200
Subject: [xml2rfc] adding (editor)
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

I was thinking along the lines of

<!ATTLIST author  role (editor) #IMPLIED >

(not sure about whether this is legal DTD speak)

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

> -----Original Message-----
> From: Marshall Rose [mailto:[email-masked]]
> Sent: Wednesday, May 07, 2003 5:59 PM
> To: Julian Reschke
> Cc: [email-masked]; [email-masked]
> Subject: Re: [xml2rfc] adding (editor)
> 
> 
> > I think for now an optional role attribute with a single allowed value
> > ("editor") makes most sense. This takes care of Scott's 
> immediate needs, is
> > extensible, yet avoids having people put in things they shouldn't.
> 
> e.g.,.
> 
> 	<!ATTLIST author  role (author|editor) "author">
> 
> ???
> 
> /mtr
> 

From: [email-masked] (Marshall Rose)
Date: Wed, 7 May 2003 08:58:55 -0700
Subject: [xml2rfc] adding (editor)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> I think for now an optional role attribute with a single allowed value
> ("editor") makes most sense. This takes care of Scott's immediate needs, is
> extensible, yet avoids having people put in things they shouldn't.

e.g.,.

	<!ATTLIST author  role (author|editor) "author">

???

/mtr

From: [email-masked] (Julian Reschke)
Date: Wed, 7 May 2003 17:30:37 +0200
Subject: [xml2rfc] rules for rules in tables
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Clive D.W.
> Feather
> Sent: Wednesday, May 07, 2003 5:09 PM
> To: Marshall Rose
> Cc: [email-masked]
> Subject: Re: [xml2rfc] rules for rules in tables
>
>
> Marshall Rose said:
> > i suggest that the following attribute be added to the <texttable/>
> > element:
> >
> >     <!ATTLIST texttable    rules    (none|header|rows|cols|all)
>    "none">
> >
> > where:
> >
> >     none: No rules.
> >     header: Rules will appear the headers and their columns
> >     rows: Rules will appear between rows only.
> >     cols: Rules will appear between columns only.
> >     all: Rules will appear between all rows and columns.
>
> I would also suggest "box" and "boxall", producing a box around the whole
> table or a box around each element (i.e. box + all).

I think HTML has an additional "frame" attribute to specify that we possibly
could steal, but I'll need some time for spec reading and tests...

> However, I would hope for something more flexible. For example, an element
> to go between the header elements to specify a rule, or an element to go
> between the c elements of two rows to specify a rule there.

Seems as like we should have row containers.

<duck-and-cover/>

I'd say then -- as Marshall is in the process of doing a release -- let's
not do anything of the rules stuff right now, and move that into the next
release.

Julian

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

From: [email-masked] (Clive D.W. Feather)
Date: Wed, 7 May 2003 16:15:57 +0100
Subject: [xml2rfc] text tables
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke said:
> A BNF grammar fragment can be seen as a sequence of triples (left-side, "=",
> right-side), and *could* automatically benefit from smart wrapping inside a
> table. So I disagree that this shouldn't be a table.

Indeed, this is the sort of thing I want to do with tables.

And it's also why I want some column widths to be determined automatically
rather than me having to pick a percentage or a value.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646

From: [email-masked] (Julian Reschke)
Date: Wed, 7 May 2003 17:12:35 +0200
Subject: [xml2rfc] adding (editor)
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

I think for now an optional role attribute with a single allowed value
("editor") makes most sense. This takes care of Scott's immediate needs, is
extensible, yet avoids having people put in things they shouldn't.

Julian

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

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Marshall Rose
> Sent: Wednesday, May 07, 2003 4:55 PM
> To: Scott W Brim
> Cc: [email-masked]
> Subject: Re: [xml2rfc] adding (editor)
>
>
> > I would like to have "S. Brim (editor)" on the top right on a draft.  In
> > order to do that, I add "(editor)" to my name in <author surname=...>.
> > However, someday, we might actually have XML-based RFCs, and it would be
> > good if the surname field were actually a real surname.  Is there a
> > more legitimate way to add "(editor)"?
>
> at present, no. about 3% of the rfc series has document editors instead
> of authors (starting back with 1122!)
>
> philosophically, i'm opposed to document editors for rfcs, but i suppose
> i have to bend with the times.
>
> so, i suppose there are two ways of fixing this.
>
> one way is to call it a "suffix", the other way is to make it a "role".
>
> if we go for a "suffix", then i suppose folks can also do things like
> "Sr.", "III", and (inevitably) "Ph.D.".
>
> if we go for a "role", then we can probably have things like "editor",
> "chair", etc.
>
> or, we can do the extraordinarily myoptic fix which is to add this
> attribute to the <author/> element
>
> 	<!ATTLIST author    editor    (true|false)    "true">
>
> comments?
>
> /mtr
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>

From: [email-masked] (Clive D.W. Feather)
Date: Wed, 7 May 2003 16:10:01 +0100
Subject: [xml2rfc] adding (editor)
In-Reply-To: <[email-masked]>
References: <20030507133512.GD2136@sbrim-w2k> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose said:
>> I would like to have "S. Brim (editor)" on the top right on a draft.  In
>> order to do that, I add "(editor)" to my name in <author surname=...>.
>> However, someday, we might actually have XML-based RFCs, and it would be
>> good if the surname field were actually a real surname.  Is there a
>> more legitimate way to add "(editor)"?

> one way is to call it a "suffix", the other way is to make it a "role".

I would go for "role".

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646

From: [email-masked] (Julian Reschke)
Date: Wed, 7 May 2003 17:09:14 +0200
Subject: [xml2rfc] rules for rules in tables
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Sounds good.

(please let me know if and when you have a test case).

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

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Marshall Rose
> Sent: Wednesday, May 07, 2003 4:58 PM
> To: [email-masked]
> Subject: [xml2rfc] rules for rules in tables
>
>
> i suggest that the following attribute be added to the <texttable/>
> element:
>
>     <!ATTLIST texttable    rules    (none|header|rows|cols|all)    "none">
>
> where:
>
>     none: No rules.
>     header: Rules will appear the headers and their columns
>     rows: Rules will appear between rows only.
>     cols: Rules will appear between columns only.
>     all: Rules will appear between all rows and columns.
>
> comments?
>
> /mtr
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>

From: [email-masked] (Clive D.W. Feather)
Date: Wed, 7 May 2003 16:09:11 +0100
Subject: [xml2rfc] rules for rules in tables
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose said:
> i suggest that the following attribute be added to the <texttable/>
> element:
>     
>     <!ATTLIST texttable    rules    (none|header|rows|cols|all)    "none">
>     
> where:
>     
>     none: No rules.
>     header: Rules will appear the headers and their columns
>     rows: Rules will appear between rows only.
>     cols: Rules will appear between columns only.
>     all: Rules will appear between all rows and columns.

I would also suggest "box" and "boxall", producing a box around the whole
table or a box around each element (i.e. box + all).

However, I would hope for something more flexible. For example, an element
to go between the header elements to specify a rule, or an element to go
between the c elements of two rows to specify a rule there.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646

From: [email-masked] (Scott W Brim)
Date: Wed, 7 May 2003 11:08:46 -0400
Subject: [xml2rfc] adding (editor)
In-Reply-To: <[email-masked]>
References: <20030507133512.GD2136@sbrim-w2k> <[email-masked]>
Message-ID: <20030507150846.GL2136@sbrim-w2k>

One more general comment: thanks much.

From: [email-masked] (Scott W Brim)
Date: Wed, 7 May 2003 11:08:30 -0400
Subject: [xml2rfc] adding (editor)
In-Reply-To: <[email-masked]>
References: <20030507133512.GD2136@sbrim-w2k> <[email-masked]>
Message-ID: <20030507150830.GK2136@sbrim-w2k>

On Wed, May 07, 2003 07:55:19AM -0700, Marshall Rose allegedly wrote:
> one way is to call it a "suffix", the other way is to make it a "role".
>     
> if we go for a "suffix", then i suppose folks can also do things like
> "Sr.", "III", and (inevitably) "Ph.D.".
>     
> if we go for a "role", then we can probably have things like "editor",
> "chair", etc.

looks good

> or, we can do the extraordinarily myoptic fix which is to add this
> attribute to the <author/> element
>     
> 	<!ATTLIST author    editor    (true|false)    "true">

ew

General comment: it's not urgent

From: [email-masked] (Marshall Rose)
Date: Wed, 7 May 2003 07:58:13 -0700
Subject: [xml2rfc] rules for rules in tables
Message-ID: <[email-masked]>

i suggest that the following attribute be added to the <texttable/>
element:
    
    <!ATTLIST texttable    rules    (none|header|rows|cols|all)    "none">
    
where:
    
    none: No rules.
    header: Rules will appear the headers and their columns
    rows: Rules will appear between rows only.
    cols: Rules will appear between columns only.
    all: Rules will appear between all rows and columns.
    
comments?
    
/mtr

From: [email-masked] (Marshall Rose)
Date: Wed, 7 May 2003 07:55:19 -0700
Subject: [xml2rfc] adding (editor)
In-Reply-To: <20030507133512.GD2136@sbrim-w2k>
References: <20030507133512.GD2136@sbrim-w2k>
Message-ID: <[email-masked]>

> I would like to have "S. Brim (editor)" on the top right on a draft.  In
> order to do that, I add "(editor)" to my name in <author surname=...>.
> However, someday, we might actually have XML-based RFCs, and it would be
> good if the surname field were actually a real surname.  Is there a
> more legitimate way to add "(editor)"?

at present, no. about 3% of the rfc series has document editors instead
of authors (starting back with 1122!)
    
philosophically, i'm opposed to document editors for rfcs, but i suppose
i have to bend with the times.
    
so, i suppose there are two ways of fixing this.
    
one way is to call it a "suffix", the other way is to make it a "role".
    
if we go for a "suffix", then i suppose folks can also do things like
"Sr.", "III", and (inevitably) "Ph.D.".
    
if we go for a "role", then we can probably have things like "editor",
"chair", etc.
    
or, we can do the extraordinarily myoptic fix which is to add this
attribute to the <author/> element
    
	<!ATTLIST author    editor    (true|false)    "true">
    
comments?
    
/mtr

From: [email-masked] (Clive D.W. Feather)
Date: Wed, 7 May 2003 15:24:41 +0100
Subject: [xml2rfc] Table of contents
Message-ID: <[email-masked]>

Is there any way to specify that a section should be excluded from the TOC?
I've got a TOC which is now about three pages long. Unfortunately, simply
limiting the depth isn't sufficient, because of the particular structure of
this document. What I want to do is to omit some bottom-level <section>s
from tbe TOC.

In other words, something like <section intoc="no">.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646

From: [email-masked] (Henrik Levkowetz)
Date: Wed, 7 May 2003 16:10:54 +0200
Subject: [xml2rfc] adding (editor)
In-Reply-To: <20030507133512.GD2136@sbrim-w2k>
References: <20030507133512.GD2136@sbrim-w2k>
Message-ID: <[email-masked]>

On Wed, 7 May 2003 09:35:13 -0400
Scott W Brim <[email-masked]> wrote:

> I would like to have "S. Brim (editor)" on the top right on a draft.  In
> order to do that, I add "(editor)" to my name in <author surname=...>.
> However, someday, we might actually have XML-based RFCs, and it would be
> good if the surname field were actually a real surname.  Is there a
> more legitimate way to add "(editor)"?

Concur. (Except I use ", Ed."). 

Adding the editor suffix as part of the surname has the additional
drawback that it is replicated in the footer, which does not match the
current style of published RFCs.

	Henrik

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

From: [email-masked] (Scott W Brim)
Date: Wed, 7 May 2003 09:35:13 -0400
Subject: [xml2rfc] adding (editor)
Message-ID: <20030507133512.GD2136@sbrim-w2k>

I would like to have "S. Brim (editor)" on the top right on a draft.  In
order to do that, I add "(editor)" to my name in <author surname=...>.
However, someday, we might actually have XML-based RFCs, and it would be
good if the surname field were actually a real surname.  Is there a
more legitimate way to add "(editor)"?

Thanks ... Scott

From: [email-masked] (Marshall Rose)
Date: Tue, 6 May 2003 12:39:06 -0700
Subject: [xml2rfc] xml2rfc v1.18 imminent...
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> We apologzie for the delayed response.  We have received much feedback
> regarding rfc2223bis.  We are taking all of the feedback into
> consideration, and have not yet made any final decisions.  For this
> reason we cannot yet offer you clarity on this particular subject.  
> 
> We do not mean to hold up your revision of rfc2629.  Please revise the
> document as you see fit.

thanks. the issue isn't really about updating rfc2629, it's about what kind of
output programs that implement rfc2629 should produce.

is there an eta as to the next revision of rfc2223bis.

thanks,

/mtr

From: [email-masked] (RFC Editor)
Date: Tue, 6 May 2003 12:29:12 -0700
Subject: [xml2rfc] Re: a question from the back of the room
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Marshall,

We apologzie for the delayed response.  We have received much feedback
regarding rfc2223bis.  We are taking all of the feedback into
consideration, and have not yet made any final decisions.  For this
reason we cannot yet offer you clarity on this particular subject.  

We do not mean to hold up your revision of rfc2629.  Please revise the
document as you see fit.

RFC Editor

On Tue, Apr 01, 2003 at 09:18:00AM -0800, Marshall Rose wrote:
> 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: [email-masked] (Julian Reschke)
Date: Tue, 6 May 2003 20:49:05 +0200
Subject: [xml2rfc] text tables
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Chris Newman
> Sent: Tuesday, May 06, 2003 8:38 PM
> To: Julian Reschke; [email-masked]
> Subject: RE: [xml2rfc] text tables
>
>
> begin quotation by Julian Reschke on 2003/5/6 8:51 +0200:
>
> > Some more questions:
> >
> > 1) Are tables without column titles supported? I.e., can I do
> something like
> > this using texttables:
> >
> >    IPv6reference = "[" IPv6address "]"
> >
> >    IPv6address   = (                          6( h4 ":" ) ls32 )
> >                  / (                     "::" 5( h4 ":" ) ls32 )
> >                  / ( [              h4 ] "::" 4( h4 ":" ) ls32 )
> >                  / ( [ *1( h4 ":" ) h4 ] "::" 3( h4 ":" ) ls32 )
> >                  / ( [ *2( h4 ":" ) h4 ] "::" 2( h4 ":" ) ls32 )
> >                  / ( [ *3( h4 ":" ) h4 ] "::"    h4 ":"   ls32 )
> >                  / ( [ *4( h4 ":" ) h4 ] "::"             ls32 )
> >                  / ( [ *5( h4 ":" ) h4 ] "::"             h4   )
> >                  / ( [ *6( h4 ":" ) h4 ] "::"                  )
> >
> >    ls32          = ( h4 ":" h4 ) / IPv4address
> >                  ; least-significant 32 bits of address
> >
> >    h4            = 1*4HEXDIG
>
> FYI, the ABNF validator at <http://www.apps.ietf.org/abnf.html> will only
> extract xml2rfc ABNF enclosed in an <artwork type="abnf"> attribute.  I
> wouldn't recommend enclosing ABNF in other structures.

Interesting.

> And I think your example is clearly a figure rather than a table
> in terms of
> structure -- you rely on vertical alignment of fixed width characters to
> enhance readability.

Well, a figure is a "catch all", because it actually doesn't have structure.
A BNF grammar fragment can be seen as a sequence of triples (left-side, "=",
right-side), and *could* automatically benefit from smart wrapping inside a
table. So I disagree that this shouldn't be a table.

Julian

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

From: [email-masked] (Chris Newman)
Date: Tue, 06 May 2003 11:38:28 -0700
Subject: [xml2rfc] text tables
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

begin quotation by Julian Reschke on 2003/5/6 8:51 +0200:

> Some more questions:
>
> 1) Are tables without column titles supported? I.e., can I do something like
> this using texttables:
>
>    IPv6reference = "[" IPv6address "]"
>
>    IPv6address   = (                          6( h4 ":" ) ls32 )
>                  / (                     "::" 5( h4 ":" ) ls32 )
>                  / ( [              h4 ] "::" 4( h4 ":" ) ls32 )
>                  / ( [ *1( h4 ":" ) h4 ] "::" 3( h4 ":" ) ls32 )
>                  / ( [ *2( h4 ":" ) h4 ] "::" 2( h4 ":" ) ls32 )
>                  / ( [ *3( h4 ":" ) h4 ] "::"    h4 ":"   ls32 )
>                  / ( [ *4( h4 ":" ) h4 ] "::"             ls32 )
>                  / ( [ *5( h4 ":" ) h4 ] "::"             h4   )
>                  / ( [ *6( h4 ":" ) h4 ] "::"                  )
>
>    ls32          = ( h4 ":" h4 ) / IPv4address
>                  ; least-significant 32 bits of address
>
>    h4            = 1*4HEXDIG

FYI, the ABNF validator at <http://www.apps.ietf.org/abnf.html> will only 
extract xml2rfc ABNF enclosed in an <artwork type="abnf"> attribute.  I 
wouldn't recommend enclosing ABNF in other structures.

And I think your example is clearly a figure rather than a table in terms of 
structure -- you rely on vertical alignment of fixed width characters to 
enhance readability.

                - Chris

From: [email-masked] (Marshall Rose)
Date: Tue, 6 May 2003 07:39:16 -0700
Subject: [xml2rfc] Suppressing mailto: links in HTML
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> ...
> Marshall, in case you want to support that too, please change the PI name to
> "rfc" (I am using "rfc-ext" to avoid name clashes with your implementation).

ok. i'll add it to my implementation. be sure to update your .xslt and
send it to me...
    
/mtr

From: [email-masked] (Marshall Rose)
Date: Tue, 6 May 2003 07:31:01 -0700
Subject: [xml2rfc] text tables
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> > > 1) Are tables without column titles supported?
> > i'd call that a figure, not a table.
> :-)
> 
> Of course in figures, I can't have markup (such as links).

true. of course, i think it would be hard to convince an arbitrary
third-party that the inherent difference between a table and a figure is
that the former has links...

> > > 2) Is there some default *vertical* alignment within table
> > cells? I'd assume "top"?
> 
> > in the html world, the answer is that the processor can do what
> > it thinks is right.
> 
> So what will your processor do?

it doesn't specify it. i suppose we can add an attribute, but before we
do that, we'd need to have an agreement as to how many attributes we're
going to be adding this month...
    
/mtr

From: [email-masked] (Julian Reschke)
Date: Tue, 6 May 2003 16:23:43 +0200
Subject: [xml2rfc] text tables
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Marshall Rose
> Sent: Tuesday, May 06, 2003 4:19 PM
> To: Julian Reschke
> Cc: [email-masked]
> Subject: Re: [xml2rfc] text tables
>
>
> > Some more questions:
> >
> > 1) Are tables without column titles supported?
>
> nope, because:
>
> > I.e., can I do something like
> > this using texttables:
> >
> >    IPv6reference = "[" IPv6address "]"
> >
> >    IPv6address   = (                          6( h4 ":" ) ls32 )
> >                  / (                     "::" 5( h4 ":" ) ls32 )
> >                  / ( [              h4 ] "::" 4( h4 ":" ) ls32 )
> >                  / ( [ *1( h4 ":" ) h4 ] "::" 3( h4 ":" ) ls32 )
> >                  / ( [ *2( h4 ":" ) h4 ] "::" 2( h4 ":" ) ls32 )
> >                  / ( [ *3( h4 ":" ) h4 ] "::"    h4 ":"   ls32 )
> >                  / ( [ *4( h4 ":" ) h4 ] "::"             ls32 )
> >                  / ( [ *5( h4 ":" ) h4 ] "::"             h4   )
> >                  / ( [ *6( h4 ":" ) h4 ] "::"                  )
> >
> >    ls32          = ( h4 ":" h4 ) / IPv4address
> >                  ; least-significant 32 bits of address
> >
> >    h4            = 1*4HEXDIG
>
> i'd call that a figure, not a table.

:-)

Of course in figures, I can't have markup (such as links).

> > 2) Is there some default *vertical* alignment within table
> cells? I'd assume
> > "top"?
>
> in the ascii world, the question doesn't have meaning (am i right?), so i
think

Nope.

If a row has a height of more than one line (let's say trhee), you *may*
want to vertically center that have fewer lines (in practice I wouldn't, but
it's an option and we may want to be clear about what a processor should do
in that case).

> in the html world, the answer is that the processor can do what
> it thinks is right.

So what will your processor do?

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

From: [email-masked] (Marshall Rose)
Date: Tue, 6 May 2003 07:19:24 -0700
Subject: [xml2rfc] text tables
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Some more questions:
> 
> 1) Are tables without column titles supported?

nope, because:

> I.e., can I do something like
> this using texttables:
> 
>    IPv6reference = "[" IPv6address "]"
> 
>    IPv6address   = (                          6( h4 ":" ) ls32 )
>                  / (                     "::" 5( h4 ":" ) ls32 )
>                  / ( [              h4 ] "::" 4( h4 ":" ) ls32 )
>                  / ( [ *1( h4 ":" ) h4 ] "::" 3( h4 ":" ) ls32 )
>                  / ( [ *2( h4 ":" ) h4 ] "::" 2( h4 ":" ) ls32 )
>                  / ( [ *3( h4 ":" ) h4 ] "::"    h4 ":"   ls32 )
>                  / ( [ *4( h4 ":" ) h4 ] "::"             ls32 )
>                  / ( [ *5( h4 ":" ) h4 ] "::"             h4   )
>                  / ( [ *6( h4 ":" ) h4 ] "::"                  )
> 
>    ls32          = ( h4 ":" h4 ) / IPv4address
>                  ; least-significant 32 bits of address
> 
>    h4            = 1*4HEXDIG

i'd call that a figure, not a table.

> 2) Is there some default *vertical* alignment within table cells? I'd assume
> "top"?

in the ascii world, the question doesn't have meaning (am i right?), so i think
in the html world, the answer is that the processor can do what it thinks is
right.

/mtr

From: [email-masked] (Graham Klyne)
Date: Tue, 06 May 2003 11:23:56 +0100
Subject: [xml2rfc] text tables
In-Reply-To: <[email-masked]. ca.us>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

At 13:43 05/05/2003 -0700, Marshall Rose wrote:
> > Seeing your example raises a question that never occurred to me during the
> > previous discussion:  I see you are inserting borders around table
> > cells.  I think that for may tables, such borders are not needed.
>
>(presumably, s/may/many/...)

Yup.

>
>i think it's a great question, i can certainly see three possibilities:
>
>     - full-blown borders
>     - one line separating headers from data
>     - none
>
>my expectation is that this is probably best answered with an optional
>attribute indicating "what kind of table", but i'd like to hear from
>folks as to what they think.

That would be nice, but I'm aware of the desire to avoid feature creep and, 
as Chris notes, it *is* an issue of presentation rather than structure.

Your 3 options seem like a good balance:  I don't see that I'd often want 
any more control than that (**), but I can imagine using tables for 
different purposes where I'd want to choose between those options.

(**) feel free to reject this out of hand, but there is one feature I have 
used in the past in my tables, which is to use horizontal borders to 
separate sub-sections within the table, but nothing between rows in the 
same sub-section. (e.g. http://www.rfc-editor.org/rfc/rfc2880.txt, section 
4.2.)  I think this is a rare case where if this much control is really 
required, I would be OK using ASCII art rather than a table.

I suppose another option might be to have some values that can be set in 
.xml2rfc.rc that allow some control over style.

#g

-------------------
Graham Klyne
<[email-masked]>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E

From: [email-masked] (Julian Reschke)
Date: Tue, 6 May 2003 09:22:03 +0200
Subject: [xml2rfc] Suppressing mailto: links in HTML
Message-ID: <[email-masked]>

Hi,

Roy Fielding has added support for a new PI into his working copy of my
RFC2629.xslt. It instructs the processor *not* to add HTML links to mailto
URIs, to avoid getting them collected by email adress harvesters. I think
this adresses a real need, so I'm adding this (with slighty changed sytax)
to my version.

Example:

	<?rfc-ext linkmailto="no"?>	<!-- (hrefs not added) -->

	<?rfc-ext linkmailto="yes"?>	<!-- (hrefs added) -->

For backwards compatibility, the default is "yes".

Marshall, in case you want to support that too, please change the PI name to
"rfc" (I am using "rfc-ext" to avoid name clashes with your implementation).

Julian

From: [email-masked] (Julian Reschke)
Date: Tue, 6 May 2003 08:51:39 +0200
Subject: [xml2rfc] text tables
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Some more questions:

1) Are tables without column titles supported? I.e., can I do something like
this using texttables:

   IPv6reference = "[" IPv6address "]"

   IPv6address   = (                          6( h4 ":" ) ls32 )
                 / (                     "::" 5( h4 ":" ) ls32 )
                 / ( [              h4 ] "::" 4( h4 ":" ) ls32 )
                 / ( [ *1( h4 ":" ) h4 ] "::" 3( h4 ":" ) ls32 )
                 / ( [ *2( h4 ":" ) h4 ] "::" 2( h4 ":" ) ls32 )
                 / ( [ *3( h4 ":" ) h4 ] "::"    h4 ":"   ls32 )
                 / ( [ *4( h4 ":" ) h4 ] "::"             ls32 )
                 / ( [ *5( h4 ":" ) h4 ] "::"             h4   )
                 / ( [ *6( h4 ":" ) h4 ] "::"                  )

   ls32          = ( h4 ":" h4 ) / IPv4address
                 ; least-significant 32 bits of address

   h4            = 1*4HEXDIG

2) Is there some default *vertical* alignment within table cells? I'd assume
"top"?

Julian

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

From: [email-masked] (Marshall Rose)
Date: Mon, 5 May 2003 13:43:11 -0700
Subject: [xml2rfc] text tables
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Seeing your example raises a question that never occurred to me during the 
> previous discussion:  I see you are inserting borders around table 
> cells.  I think that for may tables, such borders are not needed.
    
(presumably, s/may/many/...)
    
i think it's a great question, i can certainly see three possibilities:
    
    - full-blown borders
    - one line separating headers from data
    - none

my expectation is that this is probably best answered with an optional
attribute indicating "what kind of table", but i'd like to hear from
folks as to what they think.
    
/mtr

From: [email-masked] (Chris Newman)
Date: Mon, 05 May 2003 11:03:00 -0700
Subject: [xml2rfc] text tables
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

begin  quotation by Graham Klyne on 2003/5/2 11:11 +0100:
> So I guess I'm raising an additional question:  should borders be:
> (a) present
> (b) absent
> (c) optional
> ?

Because that's a question of style rather than structure, I was making the 
assumption it should be:

(d) implementation (or style-sheet) dependent

I have a slight personal preference for tables without borders, but as long as 
my tables are structurally tables, I'm satisfied regardless of the appearance.

                - Chris

From: [email-masked] (Marshall Rose)
Date: Fri, 2 May 2003 11:07:47 -0700
Subject: [xml2rfc] Tables (again)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

well, after reviewing your wish list, i think you'd be much happier
starting with docbook and writing your own conversion tools.
    
the feature set you're talking about simply isn't needed for most folks
who author rfcs... the 2629 stuff has evolved somewhat based on feature
requests, but complexity has real costs, not the least of which is the
educational problem.
    
as i compare the original 2629 to what i currently use, there's been
about 8% growth over a total of four years. i really can't 2629 evolving
at a much faster pace.

/mtr

From: [email-masked] (Clive D.W. Feather)
Date: Fri, 2 May 2003 18:04:27 +0100
Subject: [xml2rfc] Tables (again)
Message-ID: <[email-masked]>

I'm slightly kicking myself for only just discovering this mailing list,
rather than a few weeks ago.

I'm the editor of the NNTP working group, writing a replacement for
RFC 977, and I've been doing it all in xml2rfc but with a preprocessor to
handle the extra structure I need. For all this time I've been cursing the
lack of a table feature and wondering what to do about it.

I've now looked through the recent archives on the topic, and have a number
of comments to make. I hope you'll forgive me for coming in late to this
discussion.

You can see my current draft at:
<http://www.davros.org/nntp-texts/draft18.txt>
<http://www.davros.org/nntp-texts/draft18.html>

* I would like to create both clean plain text and clean HTML from a
single source. Therefore I would want the xml->html process to generate
HTML tables with minimal change (i.e. just rewrite the markup, not the
content). All the careful formatting work would only be necessary for
xml->text. In particular, the HTML should contain ordinary text, not
constant-width like <figure> produces.

* I see a table as being like a <t>...</t> paragraph. In particular, I'd
like to be able to include it in a <list> so as to get indenting.

* Most of my potential tables aren't organised around percentage widths.
Rather, I want some columns to auto-wrap and other columns to be the
minimum that will hold the text, with no wrapping. As an example, I want to
write a table like:

  UPPERCASE     indicates literal text to be included in the
                command;
  lowercase     indicates a token described elsewhere;
  [brackets]    indicate that the parameter is optional;
  ellipsis...   indicates that the parameter may be repeated any
                number of times (it must occur at least once);
  vertical|bar  indicates a choice of two mutually exclusive
                parameters (exactly one must be provided).

and have the right hand column wrap to just fit the available space.
I would have used a hanging list for this one, except that:
- in plain text there are blank lines between the cases and the right
  hand items aren't aligned;
- in HTML the left and right items are on separate lines;
but that won't work in other cases, such as:

  Extension                   Label        Added behavior

  Specific article numbers    LISTGROUP    Defined in this document
  Overview support            OVER         Defined in this document
  Header pattern matching     HDR          Defined in this document

Look at how References are done for a good demonstration of what I *do*
want.

* Right now I don't have a need for row-spanning (cells that occupy more
than one row) but I do have one for column-spanning (cells that occupy more
than one column). All my examples would be far better generated as tables,
but a few of them have single cells that want to span the entire row:

  Normal case:

    [C] LIST EXTENSIONS 
    [S] 202 Extensions supported: 
    [S] LISTGROUP 
    [S] . 

  Special case:

    [C] ARTICLE 123 
    [S] 400 Power supply failed, running on UPS 
    [Server closes connection.] 

* It would be nice to have granular control over lines, though I know HTML
doesn't completely do this. In other words:
  - have a way to select an overall box or each cell in a box
  - have a way to put a vertical line between some columns but not all
  - have a way to put a horizontal line anywhere, not just after the title.

* I agreed with those who wanted a row container object to wrap around the
<c>...</c> of each row. I can see editing problems ahead when reorganising
tables.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646

From: [email-masked] (Graham Klyne)
Date: Fri, 02 May 2003 11:11:22 +0100
Subject: [xml2rfc] text tables
In-Reply-To: <[email-masked]. ca.us>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall,

Seeing your example raises a question that never occurred to me during the 
previous discussion:  I see you are inserting borders around table 
cells.  I think that for may tables, such borders are not needed.

So I guess I'm raising an additional question:  should borders be:
(a) present
(b) absent
(c) optional
?

If I had to choose (a) or (b), I'd choose (b), so your example may look 
something like this:

[[
        keyword     default    meaning
   ------------  ------------  -------------------------------------
         strict       no       try to enforce the ID-nits
                               conventions and DTD validity

    iprnotified       no       include boilerplate from Section
                               10.4(d) of [1]

        compact       no       when producing a txt/nroff file, try
                               to conserve vertical whitespace

     subcompact     compact    if compact is "yes", then setting
                               this to "no" will make things a
                               little less compact

     ...                                                          ...

      needLines       n/a      an integer hint indicating how many
                               contiguous lines are needed at this
                               point in the output
]]

Otherwise, or even as it is, it looks great!

#g
--

At 19:50 01/05/2003 -0700, Marshall Rose wrote:
> > I believe all issues have been debated sufficiently.
>
>thanks. i have it running and am playing with some of the
>algorithms. here's an example:
>
>                                   #######
>
><texttable>
><preamble>The list of valid keywords are:</preamble>
><ttcol width='20%' align='right'>keyword</ttcol>
><ttcol width='20%' align='center'>default</ttcol>
><ttcol             align='left'>meaning</ttcol>
>
><c>strict</c>
><c>no</c>
><c>try to enforce the ID-nits conventions and DTD validity</c>
>
><c>iprnotified</c>
><c>no</c>
><c>include boilerplate from Section 10.4(d) of <xref target='RFC2026' /></c>
>
><c>compact</c>
><c>no</c>
><c>when producing a txt/nroff file, try to conserve vertical whitespace</c>
>
><c>subcompact</c>
><c>compact</c>
><c>if compact is "yes", then setting this to "no" will make things a 
>little less
>compact</c>
>
><!--
>     ...                                                          ...
>
>   -->
>
><c>needLines</c>
><c>n/a</c>
><c>an integer hint indicating how many contiguous lines are needed at this 
>point
>in the output</c>
><postamble>Remember,
>that as with everything else in XML,
>keywords and values are case-sensitive.</postamble>
></texttable>
>
>                                   #######
>
>produces
>
>                                   #######
>
>    The list of valid keywords are:
>
>+---------------+--------------+---------------------------------------+
>|       keyword |    default   | meaning                               |
>+---------------+--------------+---------------------------------------+
>|        strict |      no      | try to enforce the ID-nits            |
>|               |              | conventions and DTD validity          |
>|               |              |                                       |
>|   iprnotified |      no      | include boilerplate from Section      |
>|               |              | 10.4(d) of [1]                        |
>|               |              |                                       |
>|       compact |      no      | when producing a txt/nroff file, try  |
>|               |              | to conserve vertical whitespace       |
>|               |              |                                       |
>|    subcompact |    compact   | if compact is "yes", then setting     |
>|               |              | this to "no" will make things a       |
>|               |              | little less compact                   |
>|               |              |                                       |
>
>     ...                                                          ...
>
>|     needLines |      n/a     | an integer hint indicating how many   |
>|               |              | contiguous lines are needed at this   |
>|               |              | point in the output                   |
>+---------------+--------------+---------------------------------------+
>
>    Remember, that as with everything else in XML, keywords and values
>    are case-sensitive.
>
>                                   #######
>
>/mtr
>_______________________________________________
>xml2rfc mailing list
>[email-masked]
>http://lists.xml.resource.org/mailman/listinfo/xml2rfc

-------------------
Graham Klyne
<[email-masked]>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E

From: [email-masked] (Henrik Levkowetz)
Date: Fri, 2 May 2003 11:17:34 +0200
Subject: [xml2rfc] text tables
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thu, 1 May 2003 19:50:23 -0700, Marshall Rose <[email-masked]> wrote:

> thanks. i have it running and am playing with some of the
> algorithms. here's an example:

I think I'd be using this more often without cell borders than with.
How about an attribute of <texttable /> to choose tables with/without 
borders?

(Feature creep! Yes, I know)

	Henrik

-- 
  Experience is something you don't get until just after you need it.

From: [email-masked] (Marshall Rose)
Date: Thu, 1 May 2003 19:50:23 -0700
Subject: [xml2rfc] text tables
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> I believe all issues have been debated sufficiently.

thanks. i have it running and am playing with some of the
algorithms. here's an example:

    				  #######

<texttable>
<preamble>The list of valid keywords are:</preamble>
<ttcol width='20%' align='right'>keyword</ttcol>
<ttcol width='20%' align='center'>default</ttcol>
<ttcol             align='left'>meaning</ttcol>

<c>strict</c>
<c>no</c>
<c>try to enforce the ID-nits conventions and DTD validity</c>

<c>iprnotified</c>
<c>no</c>
<c>include boilerplate from Section 10.4(d) of <xref target='RFC2026' /></c>

<c>compact</c>
<c>no</c>
<c>when producing a txt/nroff file, try to conserve vertical whitespace</c>
    
<c>subcompact</c>
<c>compact</c>
<c>if compact is "yes", then setting this to "no" will make things a little less
compact</c>
    
<!--
    ...                                                          ...
    
  -->
    
<c>needLines</c>
<c>n/a</c>
<c>an integer hint indicating how many contiguous lines are needed at this point
in the output</c>
<postamble>Remember,
that as with everything else in XML,
keywords and values are case-sensitive.</postamble>
</texttable>

				  #######
    
produces
    
				  #######
    
   The list of valid keywords are:

+---------------+--------------+---------------------------------------+
|       keyword |    default   | meaning                               |
+---------------+--------------+---------------------------------------+
|        strict |      no      | try to enforce the ID-nits            |
|               |              | conventions and DTD validity          |
|               |              |                                       |
|   iprnotified |      no      | include boilerplate from Section      |
|               |              | 10.4(d) of [1]                        |
|               |              |                                       |
|       compact |      no      | when producing a txt/nroff file, try  |
|               |              | to conserve vertical whitespace       |
|               |              |                                       |
|    subcompact |    compact   | if compact is "yes", then setting     |
|               |              | this to "no" will make things a       |
|               |              | little less compact                   |
|               |              |                                       |
    
    ...                                                          ...
    
|     needLines |      n/a     | an integer hint indicating how many   |
|               |              | contiguous lines are needed at this   |
|               |              | point in the output                   |
+---------------+--------------+---------------------------------------+

   Remember, that as with everything else in XML, keywords and values
   are case-sensitive.
    
				  #######
    
/mtr