From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Wed, 31 Mar 2004 15:33:53 -0800 Subject: [xml2rfc] xml2rfc patch: non-zero exit status on error In-Reply-To: <16491.18679.652294.219545@cnr.cs.columbia.edu> References: <16491.18679.652294.219545@cnr.cs.columbia.edu> Message-ID: <20040331153353.307c7797.mrose+internet.xml2rfc@dbc.mtview.ca.us> > This one-liner patch causes the xml2rfc tool to exit with non-zero status if > there's a processing error when operating in non-GUI (tclsh) mode. > > This makes it possible to use xml2rfc in makefiles (being sure to prepend > DISPLAY="" to the command in the makefile). > > (I like being able to type "make" to build both the text and the html > versions of my document simultaneously.) thanks! it will be in the next release. /mtr From: lennox@cs.columbia.edu (Jonathan Lennox) Date: Wed, 31 Mar 2004 17:40:55 -0500 Subject: [xml2rfc] xml2rfc patch: non-zero exit status on error Message-ID: <16491.18679.652294.219545@cnr.cs.columbia.edu> --dhRn60Iu+q Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit This one-liner patch causes the xml2rfc tool to exit with non-zero status if there's a processing error when operating in non-GUI (tclsh) mode. This makes it possible to use xml2rfc in makefiles (being sure to prepend DISPLAY="" to the command in the makefile). (I like being able to type "make" to build both the text and the html versions of my document simultaneously.) --dhRn60Iu+q Content-Type: text/x-patch Content-Disposition: inline; filename="xml2rfc.err.patch" Content-Transfer-Encoding: 7bit --- /usr/local/bin/xml2rfc Wed Mar 3 14:10:00 2004 +++ xml2rfc Wed Mar 31 17:22:45 2004 @@ -10348,6 +10348,7 @@ if {[llength $argv] > 1} { bgerror $result } else { puts stderr $result + exit 1 } } --dhRn60Iu+q Content-Type: text/plain; charset=us-ascii Content-Description: .signature Content-Transfer-Encoding: 7bit -- Jonathan Lennox lennox@cs.columbia.edu --dhRn60Iu+q-- From: swb@employees.org (Scott W Brim) Date: Wed, 31 Mar 2004 07:39:21 -0500 Subject: [xml2rfc] default setting for In-Reply-To: <406A929A.9090201@gmx.de> References: <20040330211222.58563641.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20040331105755.4bfcaea9.henrik@levkowetz.com> <406A929A.9090201@gmx.de> Message-ID: <20040331123921.GI2428@sbrim-w2k01> On Wed, Mar 31, 2004 11:42:50AM +0200, Julian Reschke allegedly wrote: > +1 (whatever it takes to make the format more acceptable to the RFC > Editor :-) Aesthetically I like no indent, but this principle overrides. From: Miguel.An.Garcia@nokia.com (Miguel Garcia) Date: Wed, 31 Mar 2004 12:53:10 +0300 Subject: [xml2rfc] Bug report: 3667 - 3668 exchanged In-Reply-To: <406A77BF.4060000@nokia.com> References: <406A77BF.4060000@nokia.com> Message-ID: <406A9506.8090505@nokia.com> Now with the right e-mail address in the Cc field. Please Reply to all, so that Mikko Lonnfors gets a copy. /Miguel Miguel Garcia wrote: > > Hi: > > This is a bug report. We noticed that if the xml source includes the > ipr=full3667 attribute, xml2rfc introduces the following text: > > By submitting this Internet-Draft, I certify that any applicable > patent or other IPR claims of which I am aware have been disclosed, > and any of which I become aware will be disclosed, in accordance with > RFC 3667. > ^^^^ > However, according to section 5.1 of RFC 3667 the text should refer to > RFC 3668, not 3667. The text in RFC 3667 reads: > > "By submitting this Internet-Draft, I certify that any applicable > patent or other IPR claims of which I am aware have been disclosed, > and any of which I become aware will be disclosed, in accordance with > RFC 3668." > ^^^^ > > Regards, > > Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From: julian.reschke@gmx.de (Julian Reschke) Date: Wed, 31 Mar 2004 11:42:50 +0200 Subject: [xml2rfc] default setting for In-Reply-To: <20040331105755.4bfcaea9.henrik@levkowetz.com> References: <20040330211222.58563641.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20040331105755.4bfcaea9.henrik@levkowetz.com> Message-ID: <406A929A.9090201@gmx.de> Henrik Levkowetz wrote: > Tuesday 30 March 2004, Marshall Rose wrote: > >>the rfc editor has asked that we change the default setting for >> >> >> >>to >> >> >> >>comments? > > > +1 +1 (whatever it takes to make the format more acceptable to the RFC Editor :-) -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Wed, 31 Mar 2004 11:00:12 +0200 Subject: [xml2rfc] editorial comments In-Reply-To: <20040330070152.62e32f17.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us> <01e201c415f7$1d995530$0300a8c0@DFNJGL21> <20040329193208.6d431884.mrose+internet.xml2rfc@dbc.mtview.ca.us> <027a01c4160c$243aabe0$0300a8c0@DFNJGL21> <20040329211452.5062b7ca.mrose+internet.xml2rfc@dbc.mtview.ca.us> <02eb01c41654$096abab0$0300a8c0@DFNJGL21> <20040330070152.62e32f17.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <20040331110012.3d22d9b2.henrik@levkowetz.com> --Signature=_Wed__31_Mar_2004_11_00_12_+0200_.JLpNMmdjGtK/fqW Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Tuesday 30 March 2004, Marshall Rose wrote: > > Looking back at what I just typed, I think the point of "inline", for > > my use, would be to disturb the text flow - the comments matter more > > than the text, as to an author getting a review - and the point of > > "yes" would be to keep from disturbing the text (more than is > > necessary to slap [22] or [Spencer:22] into the text), as to a reader > > who is trying to understand the text, and only needs a visual queue to > > understand that there's an outstanding editorial change being > > considered. > > interesting. it hadn't occurred to me that breaking up the flow of the > text was a good thing. if we were doing typesetting, we could use > marginal notes and have it both inline and non-invasive. > > how many folks out there want the editorial comments to break up the flow? +1 on having it as an option -1 on having it as the only possibility Henrik --Signature=_Wed__31_Mar_2004_11_00_12_+0200_.JLpNMmdjGtK/fqW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAaoiceVhrtTJkXCMRAuv+AJ9ARQVlDvMlcnhoV/32ynyaMSZacwCgkOtW g5GQaE0tUHZTuiX9NdEKqEc= =Ywxs -----END PGP SIGNATURE----- --Signature=_Wed__31_Mar_2004_11_00_12_+0200_.JLpNMmdjGtK/fqW-- From: henrik@levkowetz.com (Henrik Levkowetz) Date: Wed, 31 Mar 2004 10:57:55 +0200 Subject: [xml2rfc] default setting for In-Reply-To: <20040330211222.58563641.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040330211222.58563641.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <20040331105755.4bfcaea9.henrik@levkowetz.com> --Signature=_Wed__31_Mar_2004_10_57_55_+0200_9YSm8VCFjkZVVu8g Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Tuesday 30 March 2004, Marshall Rose wrote: > the rfc editor has asked that we change the default setting for > > > > to > > > > comments? +1 Henrik --Signature=_Wed__31_Mar_2004_10_57_55_+0200_9YSm8VCFjkZVVu8g Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAaogTeVhrtTJkXCMRAoq9AJ9mA3gyiWdjGjmDdVvbwSvUE4yxTgCcDw5k eW+egGNjkzmZv2wUYVtLz38= =I0DL -----END PGP SIGNATURE----- --Signature=_Wed__31_Mar_2004_10_57_55_+0200_9YSm8VCFjkZVVu8g-- From: Miguel.An.Garcia@nokia.com (Miguel Garcia) Date: Wed, 31 Mar 2004 10:48:15 +0300 Subject: [xml2rfc] Bug report: 3667 - 3668 exchanged Message-ID: <406A77BF.4060000@nokia.com> Hi: This is a bug report. We noticed that if the xml source includes the ipr=full3667 attribute, xml2rfc introduces the following text: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3667. ^^^^ However, according to section 5.1 of RFC 3667 the text should refer to RFC 3668, not 3667. The text in RFC 3667 reads: "By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668." ^^^^ Regards, Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Tue, 30 Mar 2004 21:12:22 -0800 Subject: [xml2rfc] default setting for Message-ID: <20040330211222.58563641.mrose+internet.xml2rfc@dbc.mtview.ca.us> the rfc editor has asked that we change the default setting for to comments? /mtr From: rousskov@measurement-factory.com (Alex Rousskov) Date: Tue, 30 Mar 2004 13:31:35 -0700 (MST) Subject: [xml2rfc] editorial comments In-Reply-To: <20040330194718.GV2428@sbrim-w2k01> References: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us> <01e201c415f7$1d995530$0300a8c0@DFNJGL21> <20040329193208.6d431884.mrose+internet.xml2rfc@dbc.mtview.ca.us> <027a01c4160c$243aabe0$0300a8c0@DFNJGL21> <20040329211452.5062b7ca.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20040330194718.GV2428@sbrim-w2k01> Message-ID: On Tue, 30 Mar 2004, Scott W Brim wrote: > I would be happy with just about anything that does not require the > reader/commenter/editor to go somewhere else to see the body of the > note. ... > as long as the text of the comment appears very very close to the > point where it is intended, I'm happy. Ditto. Preserving the context is essential for small comments. Please also consider use cases where several little comments appear very close to each other. For example: The proxy(XXX: shared proxy only?) MUST strip Cookie(XXX: and Cookie2?) header before forwarding the cached response to the client (XXX: what if it's the same, auth client?). Thanks, Alex. From: swb@employees.org (Scott W Brim) Date: Tue, 30 Mar 2004 14:47:18 -0500 Subject: [xml2rfc] editorial comments In-Reply-To: References: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us> <01e201c415f7$1d995530$0300a8c0@DFNJGL21> <20040329193208.6d431884.mrose+internet.xml2rfc@dbc.mtview.ca.us> <027a01c4160c$243aabe0$0300a8c0@DFNJGL21> <20040329211452.5062b7ca.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <20040330194718.GV2428@sbrim-w2k01> On Tue, Mar 30, 2004 09:31:49AM -0700, Alex Rousskov allegedly wrote: > On Mon, 29 Mar 2004, Marshall Rose wrote: > > what would you have this look like with an inline comment? > > Accordingly, a neophyte, not knowing a word spoken, hummed, sung, > nor bellowed(XXX: Check with Paul V. to see whether "bellowed" or > "braying" is the appropriate term! --MTR), may still understand > everything that transpires. There will be unrequited love, class > conflicts, revenge, inadvertant death, accompanied by some > tasteful cross-dressing, and, on occasion, a smattering of incest, > regicide, tyrannicide, parricide or uxoricide (all with a cappella > accompaniment). That would work. This is how I do my own tbd notes. I would be happy with just about anything that does not require the reader/commenter/editor to go somewhere else to see the body of the note. It can be inline as above, or something like a blockquote, especially indented. If it breaks up the text, it can break the text at the specific point it occurs or after the line is filled ... as long as the text of the comment appears very very close to the point where it is intended, I'm happy. From: rousskov@measurement-factory.com (Alex Rousskov) Date: Tue, 30 Mar 2004 09:31:49 -0700 (MST) Subject: [xml2rfc] editorial comments In-Reply-To: <20040329211452.5062b7ca.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us> <01e201c415f7$1d995530$0300a8c0@DFNJGL21> <20040329193208.6d431884.mrose+internet.xml2rfc@dbc.mtview.ca.us> <027a01c4160c$243aabe0$0300a8c0@DFNJGL21> <20040329211452.5062b7ca.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: On Mon, 29 Mar 2004, Marshall Rose wrote: > let's try an experiment. > > let's say "[22]" refers to this editorial comment: > > Check with Paul V. to see whether "bellowed" or > "braying" is the appropriate term! > > here's the text: > > Accordingly, a neophyte, not knowing a word spoken, hummed, sung, > nor bellowed[22], may still understand everything that transpires. > There will be unrequited love, class conflicts, revenge, inadvertant > death, accompanied by some tasteful cross-dressing, and, on > occasion, a smattering of incest, regicide, tyrannicide, parricide > or uxoricide (all with a cappella accompaniment). > > what would you have this look like with an inline comment? Accordingly, a neophyte, not knowing a word spoken, hummed, sung, nor bellowed(XXX: Check with Paul V. to see whether "bellowed" or "braying" is the appropriate term! --MTR), may still understand everything that transpires. There will be unrequited love, class conflicts, revenge, inadvertant death, accompanied by some tasteful cross-dressing, and, on occasion, a smattering of incest, regicide, tyrannicide, parricide or uxoricide (all with a cappella accompaniment). HTH, Alex. From: rousskov@measurement-factory.com (Alex Rousskov) Date: Tue, 30 Mar 2004 09:26:52 -0700 (MST) Subject: [xml2rfc] editorial comments In-Reply-To: <20040330070152.62e32f17.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us> <01e201c415f7$1d995530$0300a8c0@DFNJGL21> <20040329193208.6d431884.mrose+internet.xml2rfc@dbc.mtview.ca.us> <027a01c4160c$243aabe0$0300a8c0@DFNJGL21> <20040329211452.5062b7ca.mrose+internet.xml2rfc@dbc.mtview.ca.us> <02eb01c41654$096abab0$0300a8c0@DFNJGL21> <20040330070152.62e32f17.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: On Tue, 30 Mar 2004, Marshall Rose wrote: > how many folks out there want the editorial comments to break up the > flow? FWIW, most of my hand-made comments do not break the flow. They are not important enough. If I want a prominent comment to break up the flow, I put it in a separate paragraph. Breaking the flow also kills more trees. We can have a processor decide based on the length of a comment, for example; comments shorter than 70 characters will not break the flow. Alex. From: rousskov@measurement-factory.com (Alex Rousskov) Date: Tue, 30 Mar 2004 09:16:55 -0700 (MST) Subject: [xml2rfc] editorial comments In-Reply-To: <20040330050109.2fd4c8d7.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us> <4069240B.3040708@gmx.de> <20040330050109.2fd4c8d7.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: On Tue, 30 Mar 2004, Marshall Rose wrote: > > 2) the ability to have at least paragraph breaks inside the comment. > > i think this is a mistake. when markup goes inside an editorial comment, > then we're looking at a 99% solution instead of a 90% solution... I agree with Marshall. If markup is really needed, the comment is something more than just a brief, informal, and temporary editorial remark. Alex. From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Tue, 30 Mar 2004 07:01:52 -0800 Subject: [xml2rfc] editorial comments In-Reply-To: <02eb01c41654$096abab0$0300a8c0@DFNJGL21> References: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us> <01e201c415f7$1d995530$0300a8c0@DFNJGL21> <20040329193208.6d431884.mrose+internet.xml2rfc@dbc.mtview.ca.us> <027a01c4160c$243aabe0$0300a8c0@DFNJGL21> <20040329211452.5062b7ca.mrose+internet.xml2rfc@dbc.mtview.ca.us> <02eb01c41654$096abab0$0300a8c0@DFNJGL21> Message-ID: <20040330070152.62e32f17.mrose+internet.xml2rfc@dbc.mtview.ca.us> > Looking back at what I just typed, I think the point of "inline", for > my use, would be to disturb the text flow - the comments matter more > than the text, as to an author getting a review - and the point of > "yes" would be to keep from disturbing the text (more than is > necessary to slap [22] or [Spencer:22] into the text), as to a reader > who is trying to understand the text, and only needs a visual queue to > understand that there's an outstanding editorial change being > considered. interesting. it hadn't occurred to me that breaking up the flow of the text was a good thing. if we were doing typesetting, we could use marginal notes and have it both inline and non-invasive. how many folks out there want the editorial comments to break up the flow? /mtr From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Tue, 30 Mar 2004 06:58:39 -0800 Subject: [xml2rfc] editorial comments In-Reply-To: <406971C3.7080501@gmx.de> References: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us> <4069240B.3040708@gmx.de> <20040330050109.2fd4c8d7.mrose+internet.xml2rfc@dbc.mtview.ca.us> <406971C3.7080501@gmx.de> Message-ID: <20040330065839.0f4eba56.mrose+internet.xml2rfc@dbc.mtview.ca.us> > If that enhancement would give us indeed 99% instead of 90%, I'd say > let's go for it. in that case, use docbook. it's a wonderful 99% solution. however, that is not the "2629 way..." because after paragraph breaks, someone will want some other kind of markup there, and the next thing you know it will be fully-recursive... > I was looking from the p.o.v. how to map my issue tracking entries to > comments. As each of "my" issues can consists of multiple items, > followed by suitable resolution entry, I'd probably unable to do that > mapping without that feature. That doesn't mean the extension isn't > useful, it's just less useful for me. interesting point. /mtr From: julian.reschke@gmx.de (Julian Reschke) Date: Tue, 30 Mar 2004 15:11:58 +0200 Subject: [xml2rfc] editorial comments In-Reply-To: <02eb01c41654$096abab0$0300a8c0@DFNJGL21> References: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us><01e201c415f7$1d995530$0300a8c0@DFNJGL21><20040329193208.6d431884.mrose+internet.xml2rfc@dbc.mtview.ca.us><027a01c4160c$243aabe0$0300a8c0@DFNJGL21> <20040329211452.5062b7ca.mrose+internet.xml2rfc@dbc.mtview.ca.us> <02eb01c41654$096abab0$0300a8c0@DFNJGL21> Message-ID: <4069721E.9030805@gmx.de> ...speaking of *where* crefs can occur: I think they should at least be allowed at section level (outside a specific paragraph), if they apply to a specific section in general. Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: julian.reschke@gmx.de (Julian Reschke) Date: Tue, 30 Mar 2004 15:10:27 +0200 Subject: [xml2rfc] editorial comments In-Reply-To: <20040330050109.2fd4c8d7.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us> <4069240B.3040708@gmx.de> <20040330050109.2fd4c8d7.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <406971C3.7080501@gmx.de> Marshall Rose wrote: >>2) the ability to have at least paragraph breaks inside the comment. > > > i think this is a mistake. when markup goes inside an editorial comment, > then we're looking at a 99% solution instead of a 90% solution... If that enhancement would give us indeed 99% instead of 90%, I'd say let's go for it. I was looking from the p.o.v. how to map my issue tracking entries to comments. As each of "my" issues can consists of multiple items, followed by suitable resolution entry, I'd probably unable to do that mapping without that feature. That doesn't mean the extension isn't useful, it's just less useful for me. Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: Spencer Dawkins" <01e201c415f7$1d995530$0300a8c0@DFNJGL21><20040329193208.6d431884.mrose+internet.xml2rfc@dbc.mtview.ca.us><027a01c4160c$243aabe0$0300a8c0@DFNJGL21> <20040329211452.5062b7ca.mrose+internet.xml2rfc@dbc.mtview.ca.us> <02eb01c41654$096abab0$0300a8c0@DFNJGL21> Message-ID: <02f901c41658$5c9a84a0$0300a8c0@DFNJGL21> > who is trying to understand the text, and only needs a visual queue to "vusual cue" ... sheesh! Spencer From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Tue, 30 Mar 2004 05:01:09 -0800 Subject: [xml2rfc] editorial comments In-Reply-To: <4069240B.3040708@gmx.de> References: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us> <4069240B.3040708@gmx.de> Message-ID: <20040330050109.2fd4c8d7.mrose+internet.xml2rfc@dbc.mtview.ca.us> > 2) the ability to have at least paragraph breaks inside the comment. i think this is a mistake. when markup goes inside an editorial comment, then we're looking at a 99% solution instead of a 90% solution... /mtr From: Spencer Dawkins" <01e201c415f7$1d995530$0300a8c0@DFNJGL21><20040329193208.6d431884.mrose+internet.xml2rfc@dbc.mtview.ca.us><027a01c4160c$243aabe0$0300a8c0@DFNJGL21> <20040329211452.5062b7ca.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <02eb01c41654$096abab0$0300a8c0@DFNJGL21> Dear Marshall, Thanks for asking - From: "Marshall Rose" To: "Spencer Dawkins" Cc: Sent: Monday, March 29, 2004 11:14 PM Subject: Re: [xml2rfc] editorial comments > let's try an experiment. > > let's say "[22]" refers to this editorial comment: > > Check with Paul V. to see whether "bellowed" or > "braying" is the appropriate term! > > here's the text: > > Accordingly, a neophyte, not knowing a word spoken, hummed, sung, > nor bellowed[22], may still understand everything that transpires. > There will be unrequited love, class conflicts, revenge, inadvertant > death, accompanied by some tasteful cross-dressing, and, on > occasion, a smattering of incest, regicide, tyrannicide, parricide > or uxoricide (all with a cappella accompaniment). > > what would you have this look like with an inline comment? > > /mtr When I provide comments on drafts, I tend to send comments that either look like this: Accordingly, a neophyte, not knowing a word spoken, hummed, sung, nor bellowed, may still understand everything that transpires. Spencer: Check with Paul V. to see whether "bellowed" or "braying" is the appropriate term! There will be unrequited love, class conflicts, revenge, inadvertant death, accompanied by some tasteful cross-dressing, and, on occasion, a smattering of incest, regicide, tyrannicide, parricide or uxoricide (all with a cappella accompaniment). or like this: Accordingly, a neophyte, not knowing a word spoken, hummed, sung, nor bellowed, may still understand everything that transpires. There will be unrequited love, class conflicts, revenge, inadvertant death, accompanied by some tasteful cross-dressing, and, on occasion, a smattering of incest, regicide, tyrannicide, parricide or uxoricide (all with a cappella accompaniment). Spencer: Check with Paul V. to see whether "bellowed" or "braying" is the appropriate term! depending on whether the comment is about a word or phrase, or about one or more paragraghs. I could simulate the second case, given the ability to handle the first case, by sticking the at the end of the paragraph. Looking back at what I just typed, I think the point of "inline", for my use, would be to disturb the text flow - the comments matter more than the text, as to an author getting a review - and the point of "yes" would be to keep from disturbing the text (more than is necessary to slap [22] or [Spencer:22] into the text), as to a reader who is trying to understand the text, and only needs a visual queue to understand that there's an outstanding editorial change being considered. Does this help? and thanks for asking, Spenceer From: julian.reschke@gmx.de (Julian Reschke) Date: Tue, 30 Mar 2004 09:43:53 +0200 Subject: [xml2rfc] editorial comments In-Reply-To: <20040329211452.5062b7ca.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us> <01e201c415f7$1d995530$0300a8c0@DFNJGL21> <20040329193208.6d431884.mrose+internet.xml2rfc@dbc.mtview.ca.us> <027a01c4160c$243aabe0$0300a8c0@DFNJGL21> <20040329211452.5062b7ca.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <40692539.2020309@gmx.de> Marshall Rose wrote: > let's try an experiment. > > let's say "[22]" refers to this editorial comment: > > Check with Paul V. to see whether "bellowed" or > "braying" is the appropriate term! > > here's the text: > > Accordingly, a neophyte, not knowing a word spoken, hummed, sung, > nor bellowed[22], may still understand everything that transpires. > There will be unrequited love, class conflicts, revenge, inadvertant > death, accompanied by some tasteful cross-dressing, and, on > occasion, a smattering of incest, regicide, tyrannicide, parricide > or uxoricide (all with a cappella accompaniment). > > what would you have this look like with an inline comment? I agree this is hard; and while generating TXT I'd generally prefer pointers to end notes. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: julian.reschke@gmx.de (Julian Reschke) Date: Tue, 30 Mar 2004 09:42:53 +0200 Subject: [xml2rfc] editorial comments In-Reply-To: <4068F718.6040201@cs.columbia.edu> References: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us><01e201c415f7$1d995530$0300a8c0@DFNJGL21> <20040329193208.6d431884.mrose+internet.xml2rfc@dbc.mtview.ca.us> <027a01c4160c$243aabe0$0300a8c0@DFNJGL21> <4068F718.6040201@cs.columbia.edu> Message-ID: <406924FD.5030204@gmx.de> Henning Schulzrinne wrote: >> >> I'm not sure what all the implications of your words are, but if it >> helps, even getting a comment on the same page as the text it refers >> to would be useful - you could have about as much flexibility as you >> want, in defining "next to", if that helps with your concern. > > > Smaller-font margin notes (in HTML) would be pretty nice. I think > appropriate style sheets can make that happen. > > It would also be nice to be able to distinguish notes that have been > taken care of ("made decision to do foo at IETF 60", "see mailing list > discussion on May 17") from those that haven't been ("need to decide on > options here"). Yes, a single status attribute (open/closed) would be welcome. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: julian.reschke@gmx.de (Julian Reschke) Date: Tue, 30 Mar 2004 09:41:28 +0200 Subject: [xml2rfc] editorial comments In-Reply-To: <20040329193208.6d431884.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us> <01e201c415f7$1d995530$0300a8c0@DFNJGL21> <20040329193208.6d431884.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <406924A8.6070207@gmx.de> Marshall Rose wrote: >>If I could make a suggestion - I understand why including the comments >>as a group will be useful, but I'm thinking that a third value, >>comments='inline', that shows the text of each comment next to the >>text that it refers to, would also be useful. > > > my concern is that it would break the flow of the text. > > or, we could leave it at the discretion of the processor rather than > mandate a separate section... This seems to be an area where some experimentation is needed. A PI could specify a generic comment style (inline / end), and the rest should be left to the processor. For instamce, my PDF generator may want to put comments into footnotes which is neither inline nor at the end... Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: julian.reschke@gmx.de (Julian Reschke) Date: Tue, 30 Mar 2004 09:38:51 +0200 Subject: [xml2rfc] editorial comments In-Reply-To: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <4069240B.3040708@gmx.de> Marshall Rose wrote: > i wish to propose markup that will allow authors to insert editorial > comments into their documents. > > there are two parts to the proposal: > > 1. a element that can appear anywhere , , or > may appear: > > > source %ATEXT; #REQUIRED> > > 2. a processing instruction, , that directs the > processor whether to render the comments (by default, 'no'). > > for example: > > Accordingly, 32 octets are required for this > purpose.Check with Mike to make sure that this is > correct > > if comments are rendered, then, at a minimum, their text appears in full > in a section following where the "References" area, e.g., the main body > of the text might appear as: > > Accordingly, 32 octets are required for this purpose.[22] > > and later on there would be a section like this: > > Editorial Comments > ... > [22] Check with Mike to make sure that this is correct > > > in addition, some processors may choose to provide pop-up or other > visual cues, e.g., when producing html. > > i believe that this proposal hits the "sweet spot" with respect to > annotations of a draft editorial nature. your comments are welcome. I've been looking how to map my custom extension (see previous discussion here) to this syntax. In general, two things seem to be missing: 1) the ability to *name* the issues via an anchor attribute (that is to assign unique identifiers instead of having the processor enumerate them) and 2) the ability to have at least paragraph breaks inside the comment. Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Mon, 29 Mar 2004 21:28:15 -0800 Subject: [xml2rfc] editorial comments In-Reply-To: References: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <20040329212815.030b44dd.mrose+internet.xml2rfc@dbc.mtview.ca.us> > Can the source be optional instead? Why require it? Or am I misreading > the implications of the DTD? yes, it should be optional. /mtr From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Mon, 29 Mar 2004 21:14:52 -0800 Subject: [xml2rfc] editorial comments In-Reply-To: <027a01c4160c$243aabe0$0300a8c0@DFNJGL21> References: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us> <01e201c415f7$1d995530$0300a8c0@DFNJGL21> <20040329193208.6d431884.mrose+internet.xml2rfc@dbc.mtview.ca.us> <027a01c4160c$243aabe0$0300a8c0@DFNJGL21> Message-ID: <20040329211452.5062b7ca.mrose+internet.xml2rfc@dbc.mtview.ca.us> let's try an experiment. let's say "[22]" refers to this editorial comment: Check with Paul V. to see whether "bellowed" or "braying" is the appropriate term! here's the text: Accordingly, a neophyte, not knowing a word spoken, hummed, sung, nor bellowed[22], may still understand everything that transpires. There will be unrequited love, class conflicts, revenge, inadvertant death, accompanied by some tasteful cross-dressing, and, on occasion, a smattering of incest, regicide, tyrannicide, parricide or uxoricide (all with a cappella accompaniment). what would you have this look like with an inline comment? /mtr From: rousskov@measurement-factory.com (Alex Rousskov) Date: Mon, 29 Mar 2004 22:11:26 -0700 (MST) Subject: [xml2rfc] editorial comments In-Reply-To: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: On Mon, 29 Mar 2004, Marshall Rose wrote: > 2. a processing instruction, , that directs the > processor whether to render the comments (by default, 'no'). What about RFC Editor actions? Is that expected that all archival documents will be rendered for publication with comments PI forced to "no"? It would be nice if comments can be preserved when the document is submitted to IESG but do not appear in rendered RFCs (I think we already discussed why preserving comments in sources is desirable). Can such an enforcement of a PI be documented or is it out of our control/scope? Thanks, Alex. From: rousskov@measurement-factory.com (Alex Rousskov) Date: Mon, 29 Mar 2004 22:06:00 -0700 (MST) Subject: [xml2rfc] editorial comments In-Reply-To: <4068F718.6040201@cs.columbia.edu> References: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us><01e201c415f7$1d995530$0300a8c0@DFNJGL21> <20040329193208.6d431884.mrose+internet.xml2rfc@dbc.mtview.ca.us> <027a01c4160c$243aabe0$0300a8c0@DFNJGL21> <4068F718.6040201@cs.columbia.edu> Message-ID: On Mon, 29 Mar 2004, Henning Schulzrinne wrote: > It would also be nice to be able to distinguish notes that have been > taken care of ("made decision to do foo at IETF 60", "see mailing > list discussion on May 17") from those that haven't been ("need to > decide on options here"). IMO, that seems like a nice (if not essential) issue management feature that is beyond the scope of the proposed basic comment element. It can be partially emulated (manually or by preprocessors) by removing already resolved comments/issues or marking them with a special prefix. Alex. From: rousskov@measurement-factory.com (Alex Rousskov) Date: Mon, 29 Mar 2004 22:01:07 -0700 (MST) Subject: [xml2rfc] editorial comments In-Reply-To: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: On Mon, 29 Mar 2004, Marshall Rose wrote: > source %ATEXT; #REQUIRED> Can the source be optional instead? Why require it? Or am I misreading the implications of the DTD? > Accordingly, 32 octets are required for this purpose.[22] Would it be possible for xml2rfc to render the comment reference in a way that distinguishes it from other references, so that the reader knows where to find the text and whether it is a reference of special kind? For example, Accordingly, 32 octets are required for this purpose.[XXX:22] ... [XXX:22] Check with Mike to make sure that this is correct > i believe that this proposal hits the "sweet spot" with respect to > annotations of a draft editorial nature. Yes, with the "inline" attribute that Spencer asked for. Thank you, Alex. From: rousskov@measurement-factory.com (Alex Rousskov) Date: Mon, 29 Mar 2004 21:54:52 -0700 (MST) Subject: [xml2rfc] editorial comments In-Reply-To: <20040329193208.6d431884.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us> <01e201c415f7$1d995530$0300a8c0@DFNJGL21> <20040329193208.6d431884.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: On Mon, 29 Mar 2004, Marshall Rose wrote: > > If I could make a suggestion - I understand why including the > > comments as a group will be useful, but I'm thinking that a third > > value, comments='inline', that shows the text of each comment next > > to the text that it refers to, would also be useful. FWIW, I would also use that additional "inline" feature a lot. > my concern is that it would break the flow of the text. The authors can decide whether being inlined in context is more important than "flow", for each specific comment. In many cases, short editorial comments contain references to the surrounding text ("it", "that message", "these issues") that would be awkward to resolve when reading a separate "Assorted Issues" section. > or, we could leave it at the discretion of the processor rather than > mandate a separate section... Given low implementation competition and the RFC Editor favorite tool, I would prefer to have the inlined attribute to be supported in xml2rfc :-). Thank you, Alex. From: Spencer Dawkins" <01e201c415f7$1d995530$0300a8c0@DFNJGL21> <20040329193208.6d431884.mrose+internet.xml2rfc@dbc.mtview.ca.us> <027a01c4160c$243aabe0$0300a8c0@DFNJGL21> <4068F718.6040201@cs.columbia.edu> Message-ID: <028601c41610$6126d840$0300a8c0@DFNJGL21> I'd use this capability. I don't think more than "open" and "closed" would be required. I'll let somebody smarter than I am propose syntax, if someone else likes the idea. Spencer From: "Henning Schulzrinne" To: "Spencer Dawkins" Cc: Sent: Monday, March 29, 2004 10:27 PM Subject: Re: [xml2rfc] editorial comments > > > > I'm not sure what all the implications of your words are, but if it > > helps, even getting a comment on the same page as the text it refers > > to would be useful - you could have about as much flexibility as you > > want, in defining "next to", if that helps with your concern. > > Smaller-font margin notes (in HTML) would be pretty nice. I think > appropriate style sheets can make that happen. > > It would also be nice to be able to distinguish notes that have been > taken care of ("made decision to do foo at IETF 60", "see mailing list > discussion on May 17") from those that haven't been ("need to decide on > options here"). > From: hgs@cs.columbia.edu (Henning Schulzrinne) Date: Mon, 29 Mar 2004 23:27:04 -0500 Subject: [xml2rfc] editorial comments In-Reply-To: <027a01c4160c$243aabe0$0300a8c0@DFNJGL21> References: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us><01e201c415f7$1d995530$0300a8c0@DFNJGL21> <20040329193208.6d431884.mrose+internet.xml2rfc@dbc.mtview.ca.us> <027a01c4160c$243aabe0$0300a8c0@DFNJGL21> Message-ID: <4068F718.6040201@cs.columbia.edu> > > I'm not sure what all the implications of your words are, but if it > helps, even getting a comment on the same page as the text it refers > to would be useful - you could have about as much flexibility as you > want, in defining "next to", if that helps with your concern. Smaller-font margin notes (in HTML) would be pretty nice. I think appropriate style sheets can make that happen. It would also be nice to be able to distinguish notes that have been taken care of ("made decision to do foo at IETF 60", "see mailing list discussion on May 17") from those that haven't been ("need to decide on options here"). From: Spencer Dawkins" <01e201c415f7$1d995530$0300a8c0@DFNJGL21> <20040329193208.6d431884.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <027a01c4160c$243aabe0$0300a8c0@DFNJGL21> From: "Marshall Rose" To: "Spencer Dawkins" Cc: Sent: Monday, March 29, 2004 9:32 PM Subject: Re: [xml2rfc] editorial comments > > If I could make a suggestion - I understand why including the comments > > as a group will be useful, but I'm thinking that a third value, > > comments='inline', that shows the text of each comment next to the > > text that it refers to, would also be useful. > > my concern is that it would break the flow of the text. > > or, we could leave it at the discretion of the processor rather than > mandate a separate section... I'm not sure what all the implications of your words are, but if it helps, even getting a comment on the same page as the text it refers to would be useful - you could have about as much flexibility as you want, in defining "next to", if that helps with your concern. Spencer From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Mon, 29 Mar 2004 19:32:08 -0800 Subject: [xml2rfc] editorial comments In-Reply-To: <01e201c415f7$1d995530$0300a8c0@DFNJGL21> References: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us> <01e201c415f7$1d995530$0300a8c0@DFNJGL21> Message-ID: <20040329193208.6d431884.mrose+internet.xml2rfc@dbc.mtview.ca.us> > If I could make a suggestion - I understand why including the comments > as a group will be useful, but I'm thinking that a third value, > comments='inline', that shows the text of each comment next to the > text that it refers to, would also be useful. my concern is that it would break the flow of the text. or, we could leave it at the discretion of the processor rather than mandate a separate section... /mtr From: Spencer Dawkins" Message-ID: <01e201c415f7$1d995530$0300a8c0@DFNJGL21> Dear Marshall, This is very much appreciated. If I could make a suggestion - I understand why including the comments as a group will be useful, but I'm thinking that a third value, comments='inline', that shows the text of each comment next to the text that it refers to, would also be useful. Thank you, Spencer ----- Original Message ----- From: "Marshall Rose" To: Sent: Monday, March 29, 2004 6:55 PM Subject: [xml2rfc] editorial comments > i wish to propose markup that will allow authors to insert editorial > comments into their documents. > > there are two parts to the proposal: > > 1. a element that can appear anywhere , , or > may appear: > > > source %ATEXT; #REQUIRED> > > 2. a processing instruction, , that directs the > processor whether to render the comments (by default, 'no'). > > for example: > > Accordingly, 32 octets are required for this > purpose.Check with Mike to make sure that this is > correct > > if comments are rendered, then, at a minimum, their text appears in full > in a section following where the "References" area, e.g., the main body > of the text might appear as: > > Accordingly, 32 octets are required for this purpose.[22] > > and later on there would be a section like this: > > Editorial Comments > ... > [22] Check with Mike to make sure that this is correct > > > in addition, some processors may choose to provide pop-up or other > visual cues, e.g., when producing html. > > i believe that this proposal hits the "sweet spot" with respect to > annotations of a draft editorial nature. your comments are welcome. > > /mtr > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Mon, 29 Mar 2004 16:55:52 -0800 Subject: [xml2rfc] editorial comments Message-ID: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us> i wish to propose markup that will allow authors to insert editorial comments into their documents. there are two parts to the proposal: 1. a element that can appear anywhere , , or may appear: 2. a processing instruction, , that directs the processor whether to render the comments (by default, 'no'). for example: Accordingly, 32 octets are required for this purpose.Check with Mike to make sure that this is correct if comments are rendered, then, at a minimum, their text appears in full in a section following where the "References" area, e.g., the main body of the text might appear as: Accordingly, 32 octets are required for this purpose.[22] and later on there would be a section like this: Editorial Comments ... [22] Check with Mike to make sure that this is correct in addition, some processors may choose to provide pop-up or other visual cues, e.g., when producing html. i believe that this proposal hits the "sweet spot" with respect to annotations of a draft editorial nature. your comments are welcome. /mtr From: LMM@acm.org (Larry Masinter) Date: Thu, 25 Mar 2004 18:16:56 -0800 Subject: [xml2rfc] Hanging indents? In-Reply-To: <40632BCB.9050203@gmx.de> Message-ID: <0HV500H5JVO84J@mailsj-v1.corp.adobe.com> It looks like you coded this, instead of A relation between an absolute URI and a resource. Informally, ... you used URI Mapping A relation between an absolute URI and a resource. Path Segment Informally, ... This also puts an extra blank line between the heading and the value. In HTML structural markup, this is more like a definition list. In many ways, HTML's
is closer to the desired semantic markup than the being offered: you want a list of definitions of terms or options. For backward compatibility, maybe this could just be an option or even a processing instruction for ? Larry From: julian.reschke@gmx.de (Julian Reschke) Date: Fri, 26 Mar 2004 00:10:13 +0100 Subject: [xml2rfc] excessive newlines in published I-Ds Message-ID: <406366D5.2070207@gmx.de> Hi, I just noted that an I-D that was just published () has two empty lines, where the document that I submitted only has one. Does anyone else have the same problem? Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: julian.reschke@gmx.de (Julian Reschke) Date: Thu, 25 Mar 2004 19:58:19 +0100 Subject: [xml2rfc] Hanging indents? In-Reply-To: <0HV300EM7SVBVX@mailsj-v1.corp.adobe.com> References: <0HV300EM7SVBVX@mailsj-v1.corp.adobe.com> Message-ID: <40632BCB.9050203@gmx.de> Larry Masinter wrote: > I've been trying to get the ASCII text to do a definition > list in ASCII of the form > > > this.is.option.one > Here is the text that defines option one. It runs on for > a while, on several lines, indented under the definition. > > this.is.option.two > Here is the text for option two. It is also several lines > long, where each line is indented. > > With > > > > Open to a specified named destination (which includes a view). > > > Open the specified (physical) page. > > > I get reasonable HTML, but the .txt version runs on > > > this.is.option.one Here is the text that defines option one. > > > > > Adding a after the I think we should avoid at all cost. It just breaks the semantical markup theme. > > > Open to a specified named destination (which includes a view). > > > Open the specified (physical) page. > > > fixes up the .txt version, but adds extra unwanted breaks into > the HTML version. And the nroff output > > .ti 3 > nameddest= > Open to a specified named destination (which includes a view). > .ti 3 > page= > Open the specified (physical) page. > > winds up without putting a .bp between the definition term and > its value, so that it's run on in the nroff output. > > I keep thinking somehow I'm coding this wrong anyway, but I'm not > sure what I'm asking for. Should this be an option on the > hanging list style? > > (Actual document http://larry.masinter.net/draft-zilles-pdf-03.xml). I agree that there's an issue here. Related to this: I frequently want to mark up things like Preconditions: (DAV:bind-into-collection): The Request-URI MUST identify a collection. (DAV:bind-source-exists): The DAV:href element MUST identify a resource. (DAV:binding-allowed): The resource identified by the DAV:href supports multiple bindings to it. (DAV:cross-server-binding): If the resource identified by the DAV:href element in the request body is on another server from the collection identified by the request-URI, the server MUST support cross-server bindings. (DAV:name-allowed): The name specified by the DAV:segment is available for use as a new binding name. (taken from ). I currently do that with something like

Preconditions: (DAV:bind-into-collection): The Request-URI MUST identify a collection. (DAV:bind-source-exists): The DAV:href element MUST identify a resource. ...and so on; and I'm getting what I want in both HTML and TXT. However, semantically this seems to be a subsubsection, called "Preconditions", with individual paragraphs (being indented). I've seen similar things in many documents, so maybe a special section type would make sense? Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: LMM@acm.org (Larry Masinter) Date: Thu, 25 Mar 2004 09:17:29 -0800 Subject: [xml2rfc] If one has many authors and a few editors, how to do that in XML2 RFC In-Reply-To: <40629962.3070806@gmx.de> Message-ID: <0HV5002CU6P4UH@mailsj-v1.corp.adobe.com> > c) Either somebody is an author or (s)he isn't. http://www.rfc-editor.org/policy.html#policy.auth2 bullet 3. Perhaps adding a role="contributor" which would leave the person out of the front page, but still include contact information? From: julian.reschke@gmx.de (Julian Reschke) Date: Thu, 25 Mar 2004 09:33:38 +0100 Subject: [xml2rfc] If one has many authors and a few editors, how to do that in XML2 RFC In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15503ED035C@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B15503ED035C@nl0006exch001u.nl.lucent.com> Message-ID: <40629962.3070806@gmx.de> Wijnen, Bert (Bert) wrote: > We can ask XML2RFC mailing list, which I copied. > See below for the issue. Basically, say we have some > 10 or so authors/contributors, whioch one wants to > recognize all, but only a few need to be on front page > as authors/editors? > > Thanks, > Bert a) There shouldn't be more than 5 authors, correct; b) You can mark an author as editor by setting the "role" attribute; c) Either somebody is an author or (s)he isn't. There's (currently) no way not to have an entry on the front page, but to have it in the authors section (add a specific contributors section instead). Hope this helps, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: bwijnen@lucent.com (Wijnen, Bert (Bert)) Date: Thu, 25 Mar 2004 00:56:40 +0100 Subject: [xml2rfc] If one has many authors and a few editors, how to do that in XML2 RFC Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503ED035C@nl0006exch001u.nl.lucent.com> We can ask XML2RFC mailing list, which I copied. See below for the issue. Basically, say we have some 10 or so authors/contributors, whioch one wants to recognize all, but only a few need to be on front page as authors/editors? Thanks, Bert > -----Original Message----- > From: Yang, Lily L [mailto:lily.l.yang@intel.com] > Sent: donderdag 25 maart 2004 0:48 > To: Wijnen, Bert (Bert) > Cc: Dorothy Gellert (E-mail); Mani Mahalingam (E-mail) > Subject: RE: [Capwap-DT] authors' info for the draft > > > I am aware of that. Typicaly when there are too many authors, > editors are listed at the front, but all the authors' info > still appear at the back in the "authors' information" section. > > However, I don't see a way to mark editor in the XML file. So > we might have to hand edit it. > > Any ideas? > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Wednesday, March 24, 2004 3:34 PM > > To: Yang, Lily L > > Cc: Dorothy Gellert (E-mail); Mani Mahalingam (E-mail) > > Subject: RE: [Capwap-DT] authors' info for the draft > > > > > > Not sure what your plans are... but pls realize that RFC-Editor has > > a policy of no more than 5 "authors" on the front page of a > > document. Just wanted to let you know early. > > > > See: http://www.rfc-editor.org/policy.html > > > > And specifically these sub-topics: > > http://www.rfc-editor.org/policy.html#policy.auth2 > > http://www.rfc-editor.org/policy.html#policy.authlist > > > > Thanks, > > Bert > > > > > -----Original Message----- > > > From: Yang, Lily L [mailto:lily.l.yang@intel.com] > > > Sent: woensdag 24 maart 2004 23:32 > > > To: Capwap-DT (E-mail) > > > Subject: [Capwap-DT] authors' info for the draft > > > > > > > > > Hi, Dear Design Team Members: > > > > > > I need all of you to fill out your author's info according to > > > the XML format shown in the example. > > > Please follow the exact format to save me editing trouble. > > > Just send it back to me after filling in. > > > This is for the draft. > > > > > > Lily > > > --------------example ------------ > > > > > > > > surname="Yang"> > > > Intel Corp. > > >

> > > > > > MS JF3 206, 2111 NE 25th > Avenue > > > Hillsboro > > > OR > > > 97124 > > > > > > +1 503-264-8813 > > > lily.l.yang@intel.com > > >
> > > > > > _______________________________________________ > > > Capwap-DT mailing list > > > Capwap-DT@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap-dt > > > > > > From: LMM@acm.org (Larry Masinter) Date: Wed, 24 Mar 2004 15:21:12 -0800 Subject: [xml2rfc] Hanging indents? In-Reply-To: <20040323090318.23731ed5.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <0HV300EM7SVBVX@mailsj-v1.corp.adobe.com> I've been trying to get the ASCII text to do a definition list in ASCII of the form this.is.option.one Here is the text that defines option one. It runs on for a while, on several lines, indented under the definition. this.is.option.two Here is the text for option two. It is also several lines long, where each line is indented. With Open to a specified named destination (which includes a view). Open the specified (physical) page. I get reasonable HTML, but the .txt version runs on this.is.option.one Here is the text that defines option one. Adding a after the Open to a specified named destination (which includes a view). Open the specified (physical) page. fixes up the .txt version, but adds extra unwanted breaks into the HTML version. And the nroff output .ti 3 nameddest= Open to a specified named destination (which includes a view). .ti 3 page= Open the specified (physical) page. winds up without putting a .bp between the definition term and its value, so that it's run on in the nroff output. I keep thinking somehow I'm coding this wrong anyway, but I'm not sure what I'm asking for. Should this be an option on the hanging list style? (Actual document http://larry.masinter.net/draft-zilles-pdf-03.xml). Larry -- http://larry.masinter.net From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Tue, 23 Mar 2004 09:03:18 -0800 Subject: [xml2rfc] URI (un-)escaping In-Reply-To: <405F5916.5060207@gmx.de> References: <405F5916.5060207@gmx.de> Message-ID: <20040323090318.23731ed5.mrose+internet.xml2rfc@dbc.mtview.ca.us> > Looking at... > ...it seems that xml2rfc misses to XML-unescape URIs before putting them > into text content (note the "&" is an artifact of XML-escaping, the > URI itself only contains a single "&"). actually, the bug is even more serious: the parser used by xml2rfc interprets each attribute value literally (no unescaping at all). the fix is easy. now i just need to do some regression testing... /mtr From: julian.reschke@gmx.de (Julian Reschke) Date: Mon, 22 Mar 2004 22:22:30 +0100 Subject: [xml2rfc] URI (un-)escaping Message-ID: <405F5916.5060207@gmx.de> Looking at... ...: [Perry] U.S. Supreme Court, "Perry Education Association v. Perry Local Educators' Association", 460 U.S. 37 (1983), February 1983, . ...it seems that xml2rfc misses to XML-unescape URIs before putting them into text content (note the "&" is an artifact of XML-escaping, the URI itself only contains a single "&"). Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: clive@demon.net (Clive D.W. Feather) Date: Fri, 19 Mar 2004 17:52:03 +0000 Subject: [xml2rfc] Bug report - xref and nbsp In-Reply-To: <20040319090634.69c5f29a.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040318120745.GJ33190@finch-staff-1.thus.net> <20040318093514.0e5aaf82.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20040319110652.GP63413@finch-staff-1.thus.net> <20040319090634.69c5f29a.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <20040319175203.GA32691@finch-staff-1.thus.net> Marshall Rose said: >> Sorry, on experimenting I find that what I actually did is: >> >> a word > > yes, that's a bug. here's a fix that will be in the next release. Thanks very much for the quick response. > *** 6529,6535 **** About 40 lines earlier in the 1.22 release, but easy to find. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | *** NOTE CHANGE *** Demon Internet | WWW: http://www.davros.org | Fax: +44 870 051 9937 Thus plc | | Mobile: +44 7973 377646 From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Fri, 19 Mar 2004 09:06:34 -0800 Subject: [xml2rfc] Bug report - xref and nbsp In-Reply-To: <20040319110652.GP63413@finch-staff-1.thus.net> References: <20040318120745.GJ33190@finch-staff-1.thus.net> <20040318093514.0e5aaf82.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20040319110652.GP63413@finch-staff-1.thus.net> Message-ID: <20040319090634.69c5f29a.mrose+internet.xml2rfc@dbc.mtview.ca.us> > Sorry, on experimenting I find that what I actually did is: > > a word yes, that's a bug. here's a fix that will be in the next release. /mtr *** _xml2rfc.tcl Tue Mar 16 10:11:50 2004 --- xml2rfc.tcl Fri Mar 19 09:05:34 2004 *************** *** 6529,6535 **** } if {![string compare $format none]} { ! if {![string compare [set line $text] ""]} { set eatP -1 return } --- 6529,6535 ---- } if {![string compare $format none]} { ! if {![string compare [set line [chars_expand $text]] ""]} { set eatP -1 return } From: clive@demon.net (Clive D.W. Feather) Date: Fri, 19 Mar 2004 11:06:52 +0000 Subject: [xml2rfc] Bug report - xref and nbsp In-Reply-To: <20040318093514.0e5aaf82.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040318120745.GJ33190@finch-staff-1.thus.net> <20040318093514.0e5aaf82.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <20040319110652.GP63413@finch-staff-1.thus.net> Marshall Rose said: >> Source a word, when converted to plain text, >> retains the   instead of converting it to a space. The conversion >> happens correctly in other contexts. > > what version are you running? 1.22. > when i use > > a word Sorry, on experimenting I find that what I actually did is: a word What I'm after is that the plain text says "a word" with no section references or anything else, while the HTML still links: a word. and that format did it when I tried. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | *** NOTE CHANGE *** Demon Internet | WWW: http://www.davros.org | Fax: +44 870 051 9937 Thus plc | | Mobile: +44 7973 377646 From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Thu, 18 Mar 2004 09:35:14 -0800 Subject: [xml2rfc] Bug report - xref and nbsp In-Reply-To: <20040318120745.GJ33190@finch-staff-1.thus.net> References: <20040318120745.GJ33190@finch-staff-1.thus.net> Message-ID: <20040318093514.0e5aaf82.mrose+internet.xml2rfc@dbc.mtview.ca.us> > Source a word, when converted to plain text, > retains the   instead of converting it to a space. The conversion > happens correctly in other contexts. what version are you running? when i use a word produces (.txt) a word [1] or (.nr) a\0word [1] or (.html)

a word[1]

/mtr From: clive@demon.net (Clive D.W. Feather) Date: Thu, 18 Mar 2004 12:07:45 +0000 Subject: [xml2rfc] Bug report - xref and nbsp Message-ID: <20040318120745.GJ33190@finch-staff-1.thus.net> Source a word, when converted to plain text, retains the   instead of converting it to a space. The conversion happens correctly in other contexts. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | *** NOTE CHANGE *** Demon Internet | WWW: http://www.davros.org | Fax: +44 870 051 9937 Thus plc | | Mobile: +44 7973 377646 From: carl@media.org (Carl Malamud) Date: Wed, 17 Mar 2004 09:19:29 -0800 (PST) Subject: [xml2rfc] Feature request: element for representing XML docs in I-Ds In-Reply-To: <40585D6E.8030602@gmx.de> Message-ID: <200403171719.i2HHJTEU024591@bulk.resource.org> Hi - I have pretty good luck with HTML Tidy for this kind of stuff. Use the -xml flag to say it is incoming xml, use the wrap option to set your line length. You can control a variety of other things as well. In terms of edits, etc... I use a little makefile. E.g., tidy < raw file > new file then use an entity to get the data into my xml2rfc doc. It requires a bit of setup, but it sounds like you're doing the doc over and over so it might be worth it. Regards, Carl > Niemi Aki (Nokia-M/Espoo) wrote: > > All, > > > > In many drafts nowadays it is necessary to display XML schemas or XML > > documents in general, as examples or otherwise. Usually people generate > > that XML somewhere else, using more appropriate tools, and merely > > copy-paste the results into an element. > > > > The problem is that this usually results in overflows, since the XML > > many times spans wider than 70 chars, therefore requiring manual edits > > to the XML. This becomes a real pain, if the XML changes, needs to be > > validated, etc, since each round requires going back and manually > > editing the to fit the page width. > > > > My suggestion is to define a new element, perhaps called , > > where you would insert valid XML, and have the xml2rfc converter add > > line breaks, adjust the indents and so on automatically, so that the > > results fit into the 70 or so character lines, and looks nice without > > breaking the XML. > > > > Thoughts? > > This basically requires adding > > a) an XML parser > > and > > b) a pretty-printing XML serializer. > > Also, expressing where whitespace is allowed and where it isn't is > absolutely non-trivial. > > Suggestion: write a preprocessor that does what you want. > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > From: julian.reschke@gmx.de (Julian Reschke) Date: Wed, 17 Mar 2004 15:15:10 +0100 Subject: [xml2rfc] Feature request: element for representing XML docs in I-Ds In-Reply-To: <40585375.90308@nokia.com> References: <40585375.90308@nokia.com> Message-ID: <40585D6E.8030602@gmx.de> Niemi Aki (Nokia-M/Espoo) wrote: > All, > > In many drafts nowadays it is necessary to display XML schemas or XML > documents in general, as examples or otherwise. Usually people generate > that XML somewhere else, using more appropriate tools, and merely > copy-paste the results into an element. > > The problem is that this usually results in overflows, since the XML > many times spans wider than 70 chars, therefore requiring manual edits > to the XML. This becomes a real pain, if the XML changes, needs to be > validated, etc, since each round requires going back and manually > editing the to fit the page width. > > My suggestion is to define a new element, perhaps called , > where you would insert valid XML, and have the xml2rfc converter add > line breaks, adjust the indents and so on automatically, so that the > results fit into the 70 or so character lines, and looks nice without > breaking the XML. > > Thoughts? This basically requires adding a) an XML parser and b) a pretty-printing XML serializer. Also, expressing where whitespace is allowed and where it isn't is absolutely non-trivial. Suggestion: write a preprocessor that does what you want. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: hgs@cs.columbia.edu (Henning Schulzrinne) Date: Wed, 17 Mar 2004 09:04:07 -0500 Subject: [xml2rfc] Feature request: element for representing XML docs in I-Ds In-Reply-To: <40585375.90308@nokia.com> References: <40585375.90308@nokia.com> Message-ID: <40585AD7.80106@cs.columbia.edu> The other problem is that currently inclusion requires adding CDATA wrappers around the file, again requiring manual intervention after each change. Or can you put the inclusion All, > > In many drafts nowadays it is necessary to display XML schemas or XML > documents in general, as examples or otherwise. Usually people generate > that XML somewhere else, using more appropriate tools, and merely > copy-paste the results into an element. > > The problem is that this usually results in overflows, since the XML > many times spans wider than 70 chars, therefore requiring manual edits > to the XML. This becomes a real pain, if the XML changes, needs to be > validated, etc, since each round requires going back and manually > editing the to fit the page width. > > My suggestion is to define a new element, perhaps called , > where you would insert valid XML, and have the xml2rfc converter add > line breaks, adjust the indents and so on automatically, so that the > results fit into the 70 or so character lines, and looks nice without > breaking the XML. > > Thoughts? > > Cheers, > Aki > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc From: aki.niemi@nokia.com (Niemi Aki (Nokia-M/Espoo)) Date: Wed, 17 Mar 2004 15:32:37 +0200 Subject: [xml2rfc] Feature request: element for representing XML docs in I-Ds Message-ID: <40585375.90308@nokia.com> All, In many drafts nowadays it is necessary to display XML schemas or XML documents in general, as examples or otherwise. Usually people generate that XML somewhere else, using more appropriate tools, and merely copy-paste the results into an element. The problem is that this usually results in overflows, since the XML many times spans wider than 70 chars, therefore requiring manual edits to the XML. This becomes a real pain, if the XML changes, needs to be validated, etc, since each round requires going back and manually editing the to fit the page width. My suggestion is to define a new element, perhaps called , where you would insert valid XML, and have the xml2rfc converter add line breaks, adjust the indents and so on automatically, so that the results fit into the 70 or so character lines, and looks nice without breaking the XML. Thoughts? Cheers, Aki From: clive@demon.net (Clive D.W. Feather) Date: Wed, 17 Mar 2004 08:06:28 +0000 Subject: [xml2rfc] last call on the 'toc' attribute for the
element In-Reply-To: <20040316091544.266289c5.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040312134541.0653f95a.mrose+internet.xml2rfc@dbc.mtview.ca.us> <4055A999.1040705@gmx.de> <20040316071307.029f6cae.mrose+internet.xml2rfc@dbc.mtview.ca.us> <405727DC.4050104@gmx.de> <20040316091544.266289c5.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <20040317080628.GD90348@finch-staff-1.thus.net> Marshall Rose said: > > but it opens the possibility to create things like > > > > 3 foo > > 3.1.1 bar2 > > 3.1.3 bar3 > > > > ...which I don't think we should support. > > but, that is exactly the functionality allowed in the request! Yes, but only by accident. As the original requestor, I don't need that functionality. Let me be clear: I will happily accept anything that you offer that means I don't have to keep hacking it in myself. Anything else I say in this thread is secondary to that. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | *** NOTE CHANGE *** Demon Internet | WWW: http://www.davros.org | Fax: +44 870 051 9937 Thus plc | | Mobile: +44 7973 377646 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Tue, 16 Mar 2004 21:16:12 +0100 Subject: [xml2rfc] last call on the 'toc' attribute for the
element In-Reply-To: <20040316071307.029f6cae.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040312134541.0653f95a.mrose+internet.xml2rfc@dbc.mtview.ca.us> <4055A999.1040705@gmx.de> <20040316071307.029f6cae.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <20040316211612.074dea70.henrik@levkowetz.com> --Signature=_Tue__16_Mar_2004_21_16_12_+0100_3RoZ8Mp+ecmp+wHO Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Jumping into the fray... Tuesday 16 March 2004, Marshall Rose wrote: > it just seems to me that the simplest solution is to have an optional attribute > for the
element that overrides whatever policy is used by the > processor. > > i think that the 'toc' attribute does just that. This is a simple solution, straightforward and easy to understand. True, it makes it possible to produce weird and undesireable TOCs, but for an exception mechanism I think that's OK, and better than making it too restrictive. So I'm for this, as described in Marshall's last call note from March 12th. Henrik --Signature=_Tue__16_Mar_2004_21_16_12_+0100_3RoZ8Mp+ecmp+wHO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAV2CMeVhrtTJkXCMRAuzUAKDRK7ZIMueCoMOIFLHQndOANFpmGQCgi90M GazP1gMK1Q3raUZDYL5U1TE= =ZtUl -----END PGP SIGNATURE----- --Signature=_Tue__16_Mar_2004_21_16_12_+0100_3RoZ8Mp+ecmp+wHO-- From: julian.reschke@gmx.de (Julian Reschke) Date: Tue, 16 Mar 2004 18:32:45 +0100 Subject: [xml2rfc] last call on the 'toc' attribute for the
element In-Reply-To: <20040316091544.266289c5.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040312134541.0653f95a.mrose+internet.xml2rfc@dbc.mtview.ca.us> <4055A999.1040705@gmx.de> <20040316071307.029f6cae.mrose+internet.xml2rfc@dbc.mtview.ca.us> <405727DC.4050104@gmx.de> <20040316091544.266289c5.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <40573A3D.80107@gmx.de> Marshall Rose wrote: >>but it opens the possibility to create things like >> >>3 foo >>3.1.1 bar2 >>3.1.3 bar3 >> >>...which I don't think we should support. > > > but, that is exactly the functionality allowed in the request! Well, no. The request was about the ability to leave it specific sections and their descendants. The *proposal* made to implement this allowed that, but - as I said - I'd prefer a more restrictive syntax. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Tue, 16 Mar 2004 09:18:50 -0800 Subject: [xml2rfc] last call on the 'toc' attribute for the
element In-Reply-To: <16471.11784.47000.292691@gargle.gargle.HOWL> References: <20040312134541.0653f95a.mrose+internet.xml2rfc@dbc.mtview.ca.us> <4055A999.1040705@gmx.de> <20040316071307.029f6cae.mrose+internet.xml2rfc@dbc.mtview.ca.us> <405727DC.4050104@gmx.de> <16471.11784.47000.292691@gargle.gargle.HOWL> Message-ID: <20040316091850.17de69d5.mrose+internet.xml2rfc@dbc.mtview.ca.us> > If something is included, all levels above are automatically included? as currently written, no. and i think that's the correct behavior. the issue is, hopefully, simple: right now, each 2629 processor has a policy that it uses for generating a table of contents. the request was a way to alter this policy. there are two choices: externalize all the supported policies, or, provide a mechanism for making an exception to the policy. i prefer the latter because it allows each processor to implement whatever policies work for them and still allows for obsessive authors to use their favorite processor and tinker with the table of contents... /mtr From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Tue, 16 Mar 2004 09:15:44 -0800 Subject: [xml2rfc] last call on the 'toc' attribute for the
element In-Reply-To: <405727DC.4050104@gmx.de> References: <20040312134541.0653f95a.mrose+internet.xml2rfc@dbc.mtview.ca.us> <4055A999.1040705@gmx.de> <20040316071307.029f6cae.mrose+internet.xml2rfc@dbc.mtview.ca.us> <405727DC.4050104@gmx.de> Message-ID: <20040316091544.266289c5.mrose+internet.xml2rfc@dbc.mtview.ca.us> > > but it opens the possibility to create things like > > 3 foo > 3.1.1 bar2 > 3.1.3 bar3 > > ...which I don't think we should support. but, that is exactly the functionality allowed in the request! /mtr From: julian.reschke@gmx.de (Julian Reschke) Date: Tue, 16 Mar 2004 17:50:09 +0100 Subject: [xml2rfc] last call on the 'toc' attribute for the
element In-Reply-To: <16471.11784.47000.292691@gargle.gargle.HOWL> References: <20040312134541.0653f95a.mrose+internet.xml2rfc@dbc.mtview.ca.us> <4055A999.1040705@gmx.de> <20040316071307.029f6cae.mrose+internet.xml2rfc@dbc.mtview.ca.us> <405727DC.4050104@gmx.de> <16471.11784.47000.292691@gargle.gargle.HOWL> Message-ID: <40573041.1010206@gmx.de> Scott W Brim wrote: > On 16 Mar 2004 at 17:14 +0100, Julian Reschke allegedly wrote: > >>but it opens the possibility to create things like >> >>3 foo >>3.1.1 bar2 >>3.1.3 bar3 >> >>...which I don't think we should support. > > > If something is included, all levels above are automatically included? Sure, that would be one solution. I'd prefer the other one because I think it better reflects the intended semantics. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: swb@employees.org (Scott W Brim) Date: Tue, 16 Mar 2004 11:40:40 -0500 Subject: [xml2rfc] last call on the 'toc' attribute for the
element In-Reply-To: <405727DC.4050104@gmx.de> References: <20040312134541.0653f95a.mrose+internet.xml2rfc@dbc.mtview.ca.us> <4055A999.1040705@gmx.de> <20040316071307.029f6cae.mrose+internet.xml2rfc@dbc.mtview.ca.us> <405727DC.4050104@gmx.de> Message-ID: <16471.11784.47000.292691@gargle.gargle.HOWL> On 16 Mar 2004 at 17:14 +0100, Julian Reschke allegedly wrote: > but it opens the possibility to create things like > > 3 foo > 3.1.1 bar2 > 3.1.3 bar3 > > ...which I don't think we should support. If something is included, all levels above are automatically included? From: julian.reschke@gmx.de (Julian Reschke) Date: Tue, 16 Mar 2004 17:14:20 +0100 Subject: [xml2rfc] last call on the 'toc' attribute for the
element In-Reply-To: <20040316071307.029f6cae.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040312134541.0653f95a.mrose+internet.xml2rfc@dbc.mtview.ca.us> <4055A999.1040705@gmx.de> <20040316071307.029f6cae.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <405727DC.4050104@gmx.de> Marshall Rose wrote: >>I think I'd prefer something that makes skipping section levels in the >>TOC impossible, such as the proposal in >>. > > > "impossible" ??? > > it just seems to me that the simplest solution is to have an optional attribute > for the
element that overrides whatever policy is used by the > processor. > > i think that the 'toc' attribute does just that. Yes, but it opens the possibility to create things like 3 foo 3.1.1 bar2 3.1.3 bar3 ...which I don't think we should support. Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Tue, 16 Mar 2004 07:13:07 -0800 Subject: [xml2rfc] last call on the 'toc' attribute for the
element In-Reply-To: <4055A999.1040705@gmx.de> References: <20040312134541.0653f95a.mrose+internet.xml2rfc@dbc.mtview.ca.us> <4055A999.1040705@gmx.de> Message-ID: <20040316071307.029f6cae.mrose+internet.xml2rfc@dbc.mtview.ca.us> > I think I'd prefer something that makes skipping section levels in the > TOC impossible, such as the proposal in > . "impossible" ??? it just seems to me that the simplest solution is to have an optional attribute for the
element that overrides whatever policy is used by the processor. i think that the 'toc' attribute does just that. /mtr From: clive@demon.net (Clive D.W. Feather) Date: Mon, 15 Mar 2004 14:03:19 +0000 Subject: [xml2rfc] last call on the 'toc' attribute for the
element In-Reply-To: <002201c40a8f$4baa9c90$0400a8c0@DFNJGL21> References: <20040312134541.0653f95a.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20040315090819.GC9851@finch-staff-1.thus.net> <002201c40a8f$4baa9c90$0400a8c0@DFNJGL21> Message-ID: <20040315140319.GB36899@finch-staff-1.thus.net> Spencer Dawkins said: > I am confused... Clive, what are you actually happy with? I'm happy with anything that does one or the other of these: (1) lets me say "omit this section from the ToC" on any given section (2) lets me say "omit all sub-sections of this section from the ToC" on any given section, leaving this section in the ToC (if the level is high enough, of course). Either of those will suffice for me, but I won't object to more flexibility than that. > I like the proposal, but like Clive's previous proposal that this > attribute be set at the level ABOVE the sections being included or > excluded. The section-by-section processing makes it possible that > half the sections at the same level, with the same ancestor, would be > included while the other half were not (careless markup, two editors > that didn't synchronize, etc.). If you mean "same parent" rather than "same ancestor", I'd be happy. I do, however, want to be able to include 1.2.3.X in the ToC while excluding 1.2.2.X. > Unless there's a reason why section-by-section flexibility is needed, > I'd like to see it work the way Clive suggested (e-mail of 2/27, which > no one who was on a plane to Korea reacted to)... You mean this one? ==== Suppose we call it "structureInToc" (that's not a great name; suggestions for a better one would be welcome):
with the default being to obey the toclevel instruction, then the rule is: * the setting on the section doesn't affect whether that section is in the ToC * if all ancestors have "yes", it is in the ToC * if any ancestor has "no", omit it from the ToC * for levels strictly less than toclevel, the default is the same as "yes" * for levels at or greater than toclevel, the default is "no". So if you don't use this new attribute and set toclevel to 3, then: Section X is included, and has default setting "yes" Section X.Y is therefore included, and has default setting "yes" Section X.Y.Z is therefore included, and has default setting "no" Section X.Y.Z.W is therefore not included. If you put "no" on 3.4, then 3.4.1 to 3.4.99 are omitted. If you put "yes" on 3.2.1, then 3.2.1.1 to 3.2.1.99 are included. The "no" on 3.4 overrides any "yes" on 3.4.1. ==== I'm happy with this, yes. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | *** NOTE CHANGE *** Demon Internet | WWW: http://www.davros.org | Fax: +44 870 051 9937 Thus plc | | Mobile: +44 7973 377646 From: Spencer Dawkins" element References: <20040312134541.0653f95a.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20040315090819.GC9851@finch-staff-1.thus.net> Message-ID: <002201c40a8f$4baa9c90$0400a8c0@DFNJGL21> I am confused... Clive, what are you actually happy with? I like the proposal, but like Clive's previous proposal that this attribute be set at the level ABOVE the sections being included or excluded. The section-by-section processing makes it possible that half the sections at the same level, with the same ancestor, would be included while the other half were not (careless markup, two editors that didn't synchronize, etc.). Maybe this is a requirement, but I'd expect that when this happens, it's usually a mistake. Unless there's a reason why section-by-section flexibility is needed, I'd like to see it work the way Clive suggested (e-mail of 2/27, which no one who was on a plane to Korea reacted to)... Spencer ----- Original Message ----- From: "Clive D.W. Feather" To: "Marshall Rose" Cc: Sent: Monday, March 15, 2004 3:08 AM Subject: Re: [xml2rfc] last call on the 'toc' attribute for the
element > Marshall Rose said: > > ok, everyone should be back from seoul, so i will ask for final confirmation: > > > > is there concensus on adding an optional attribute to the
element, > > called 'toc' that takes one of three values: 'include', 'exclude', or 'default'. > > > > if 'include' or 'exclude' is used, then this overrides the > tocdepth='xxx'?> setting. > > I would be extremely happy. From: julian.reschke@gmx.de (Julian Reschke) Date: Mon, 15 Mar 2004 14:03:21 +0100 Subject: [xml2rfc] last call on the 'toc' attribute for the
element In-Reply-To: <20040312134541.0653f95a.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040312134541.0653f95a.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <4055A999.1040705@gmx.de> Marshall Rose wrote: > ok, everyone should be back from seoul, so i will ask for final confirmation: > > is there concensus on adding an optional attribute to the
element, > called 'toc' that takes one of three values: 'include', 'exclude', or 'default'. > > if 'include' or 'exclude' is used, then this overrides the tocdepth='xxx'?> setting. I think I'd prefer something that makes skipping section levels in the TOC impossible, such as the proposal in . Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: clive@demon.net (Clive D.W. Feather) Date: Mon, 15 Mar 2004 09:08:19 +0000 Subject: [xml2rfc] last call on the 'toc' attribute for the
element In-Reply-To: <20040312134541.0653f95a.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040312134541.0653f95a.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <20040315090819.GC9851@finch-staff-1.thus.net> Marshall Rose said: > ok, everyone should be back from seoul, so i will ask for final confirmation: > > is there concensus on adding an optional attribute to the
element, > called 'toc' that takes one of three values: 'include', 'exclude', or 'default'. > > if 'include' or 'exclude' is used, then this overrides the tocdepth='xxx'?> setting. I would be extremely happy. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | *** NOTE CHANGE *** Demon Internet | WWW: http://www.davros.org | Fax: +44 870 051 9937 Thus plc | | Mobile: +44 7973 377646 From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Fri, 12 Mar 2004 13:45:41 -0800 Subject: [xml2rfc] last call on the 'toc' attribute for the
element Message-ID: <20040312134541.0653f95a.mrose+internet.xml2rfc@dbc.mtview.ca.us> ok, everyone should be back from seoul, so i will ask for final confirmation: is there concensus on adding an optional attribute to the
element, called 'toc' that takes one of three values: 'include', 'exclude', or 'default'. if 'include' or 'exclude' is used, then this overrides the setting. /mtr From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Thu, 4 Mar 2004 14:29:28 -0800 Subject: [xml2rfc] mismatched boilerplate with noDerivativeWorks2026 In-Reply-To: <0HU100B8WXKIDN@mailsj-v1.corp.adobe.com> References: <20040225133730.77bbaf82.mrose+internet.xml2rfc@dbc.mtview.ca.us> <0HU100B8WXKIDN@mailsj-v1.corp.adobe.com> Message-ID: <20040304142928.27713f9b.mrose+internet.xml2rfc@dbc.mtview.ca.us> > If you use > ipr="noDerivativeWorks2026" > > the top of the results says > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026 except that the right to > produce derivative works is not granted. > > but the Full Copyright Statement at the end makes no mention > of the exception. right you are. however, new I-Ds are supposed to use one of: full3667 noModifications3667 noDerivatives3667 if you want me to fix the 2026 stuff, someone will have to tell me what the full copyright statement should say in such cases... /mtr From: LMM@acm.org (Larry Masinter) Date: Thu, 04 Mar 2004 04:33:54 -0800 Subject: [xml2rfc] mismatched boilerplate with noDerivativeWorks2026 In-Reply-To: <20040225133730.77bbaf82.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <0HU100B8WXKIDN@mailsj-v1.corp.adobe.com> If you use ipr="noDerivativeWorks2026" the top of the results says This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. but the Full Copyright Statement at the end makes no mention of the exception. Larry