From: mikko.lonnfors@nokia.com (mikko.lonnfors@nokia.com) Date: Wed, 28 Apr 2004 09:01:06 +0300 Subject: [xml2rfc] Spaces at the End of a Sentence Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DEA9@esebe004.ntc.nokia.com> Hi, > > Then generating txt files using xml2frc 1.23 there is always only a > > single space after a period. Is there way I could force xml2rfc to > > generate two spaces? > > it's supposed to do this automatically, though apparently that's > broken. are you running xml2rfc.tcl locally, or are you using the > web-based service? I have done both and the end result is same. - Mikko > thanks, > > /mtr > > From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Tue, 27 Apr 2004 16:11:31 -0700 Subject: [xml2rfc] Spaces at the End of a Sentence In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17304@esebe004.ntc.nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17304@esebe004.ntc.nokia.com> Message-ID: <385D7F9C-98A0-11D8-B876-000A95CA7FAE@dbc.mtview.ca.us> > Then generating txt files using xml2frc 1.23 there is always only a > single space after a period. Is there way I could force xml2rfc to > generate two spaces? it's supposed to do this automatically, though apparently that's broken. are you running xml2rfc.tcl locally, or are you using the web-based service? thanks, /mtr From: mikko.lonnfors@nokia.com (mikko.lonnfors@nokia.com) Date: Tue, 27 Apr 2004 10:39:31 +0300 Subject: [xml2rfc] Spaces at the End of a Sentence Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17304@esebe004.ntc.nokia.com> Hi, According to draft-rfc-editor-rfc2223bis-07.txt ftp://ftp.isi.edu/in-notes/rfc-editor/instructions2authors.txt section 3.1 - (7): "When a sentence ended by a period is immediately followed by another sentence, there should be two blank spaces after the period. This rule provides clarity when an RFC is displayed or printed with a fixed-width font. Then generating txt files using xml2frc 1.23 there is always only a single space after a period. Is there way I could force xml2rfc to generate two spaces? Thanks - Mikko From: mrose@dbc.mtview.ca.us (Marshall Rose) Date: Fri, 23 Apr 2004 15:46:44 -0700 Subject: [xml2rfc] Idnits In-Reply-To: <20040423184026.73193d66.henrik@levkowetz.com> References: <20040423184026.73193d66.henrik@levkowetz.com> Message-ID: <189BD7C0-9578-11D8-A03E-000A95CA7FAE@dbc.mtview.ca.us> On Apr 23, 2004, at 09:40, Henrik Levkowetz wrote: > Hi, > > I've been working on a tool ("idnits", > http://www.mip4.org/tools/idnits/) > to verify most of the nits listed on the > http://www.ietf.org/ID-nits.html > page. Normally xml2rfc generated documents have passed with flying > colours, but when I recently changed the tool to look for exact > adherence to the RFC 3667 and 3668 boiler-plate, I discovered that the > 3667/8-derived boilerplate in xml2rfc 1.23 doesn't exactly match the > text > given in the RFCs. ... thanks! this is fixed in the next release. /mtr From: henrik@levkowetz.com (Henrik Levkowetz) Date: Fri, 23 Apr 2004 18:40:26 +0200 Subject: [xml2rfc] Idnits Message-ID: <20040423184026.73193d66.henrik@levkowetz.com> Hi, I've been working on a tool ("idnits", http://www.mip4.org/tools/idnits/) to verify most of the nits listed on the http://www.ietf.org/ID-nits.html page. Normally xml2rfc generated documents have passed with flying colours, but when I recently changed the tool to look for exact adherence to the RFC 3667 and 3668 boiler-plate, I discovered that the 3667/8-derived boilerplate in xml2rfc 1.23 doesn't exactly match the text given in the RFCs. The following is the diff I'm getting: ---------------------------------------------------------------------- --- rfc-text.txt 2004-04-23 18:28:36.000000000 +0200 +++ xml-text.txt 2004-04-23 18:35:33.000000000 +0200 @@ -4,8 +4,8 @@ in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. -Information on the procedures with respect to rights in RFC -documents can be found in BCP 78 and BCP 79. +Information on the IETF's procedures with respect to rights in IETF +Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an ---------------------------------------------------------------------- Regards, Henrik From: clive@demon.net (Clive D.W. Feather) Date: Thu, 15 Apr 2004 05:47:04 +0100 Subject: [xml2rfc] Nroff output In-Reply-To: <20040414110637.371fceb9.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040414171117.GM68584@finch-staff-1.thus.net> <20040414110637.371fceb9.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <20040415044704.GA51147@finch-staff-1.thus.net> Marshall Rose said: >> I've just generated text and nroff files from my XML source. I've then fed >> the latter through nroff to get another text file, and they aren't the >> same! > > what are the differences, exactly? I have a 4400 line output from diff; wc on the two files gives: 5824 29414 202299 draft23.txt 6240 29434 199592 draft23.txt.from.nroff Let's see: (1) Page boundaries aren't being done properly (in all the following, < is the text output and > is the nroff output): 335,337c358,364 < Feather Expires September 19, 2004 [Page 6] < < Internet-Draft Network News Transport Protocol March 2004 --- > Feather Expires September 19, 2004 FORMFEED[Page 6] > > > > > > Internet-Draft Network News Transport Protocol March 2004 (2) Table of contents is aligned differently: < 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 < 2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 < 3. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . 8 < 3.1 Commands and Responses . . . . . . . . . . . . . . . . . 8 < 3.2 Response Codes . . . . . . . . . . . . . . . . . . . . . 10 < 3.2.1 Generic Response Codes . . . . . . . . . . . . . . . 11 < 3.2.1.1 Examples . . . . . . . . . . . . . . . . . . . . 13 > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 > 2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 > 3. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . 8 > 3.1 Commands and Responses . . . . . . . . . . . . . . . . . 8 > 3.2 Response Codes . . . . . . . . . . . . . . . . . . . . . 10 > 3.2.1 Generic Response Codes . . . . . . . . . . . . . . . 11 > 3.2.1.1 Examples . . . . . . . . . . . . . . . . . . . . 13 (3) Hyphens in text aren't treated the same: 516,520c555,559 < amount of data from the client while in the midst of sending a < multi-line message to the server (such as during a POST or IHAVE < command) SHOULD suffice to reset the autologout timer. When the timer < expires, the server SHOULD close the TCP connection without sending < any response to the client. --- > amount of data from the client while in the midst of sending a multi- > line message to the server (such as during a POST or IHAVE command) > SHOULD suffice to reset the autologout timer. When the timer expires, > the server SHOULD close the TCP connection without sending any > response to the client. (4) The vspace directive seems to be going wrong; the XML source: 1xx - Informative message. 2xx - Command completed OK. 3xx - Command OK so far; send the rest of it. 4xx - Command was syntactically correct but failed for some reason. 5xx - Command unknown, unsupported, unavailable, or syntax error. generates: 530,535c569,572 < 1xx - Informative message. < 2xx - Command completed OK. < 3xx - Command OK so far; send the rest of it. < 4xx - Command was syntactically correct but failed for some < reason. < 5xx - Command unknown, unsupported, unavailable, or syntax error. --- > 1xx - Informative message. 2xx - Command completed OK. 3xx - > Command OK so far; send the rest of it. 4xx - Command was > syntactically correct but failed for some reason. 5xx - Command > unknown, unsupported, unavailable, or syntax error. If there's anything else, these four are obscuring it enough that I can't see it yet. I don't know if you feel the outputs *should* be the same, but this looks like it may cause me hassle at the RFC-Editor stage, so I would suggest that it is a desirable outcome. -- 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: Wed, 14 Apr 2004 11:06:37 -0700 Subject: [xml2rfc] Nroff output In-Reply-To: <20040414171117.GM68584@finch-staff-1.thus.net> References: <20040414171117.GM68584@finch-staff-1.thus.net> Message-ID: <20040414110637.371fceb9.mrose+internet.xml2rfc@dbc.mtview.ca.us> > I've just generated text and nroff files from my XML source. I've then fed > the latter through nroff to get another text file, and they aren't the > same! what are the differences, exactly? > The source tcl file has some commented out code involving a perl script. Is > this needed and/or available? it's not needed. i haven't used it in about 6 years... (in fact, i don't even have a copy of it any more) /mtr From: clive@demon.net (Clive D.W. Feather) Date: Wed, 14 Apr 2004 18:11:17 +0100 Subject: [xml2rfc] Nroff output Message-ID: <20040414171117.GM68584@finch-staff-1.thus.net> I've just generated text and nroff files from my XML source. I've then fed the latter through nroff to get another text file, and they aren't the same! The source tcl file has some commented out code involving a perl script. Is this needed and/or available? -- 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: lennox@cs.columbia.edu (Jonathan Lennox) Date: Tue, 13 Apr 2004 15:15:57 -0400 Subject: [xml2rfc] Empty tooltip in html output of xml2rfc 1.23 In-Reply-To: <20040412214634.3abf2ba9.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <16507.22218.112700.148696@cnr.cs.columbia.edu> <20040412214634.3abf2ba9.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <16508.15469.747586.329272@cnr.cs.columbia.edu> On Monday, April 12 2004, "Marshall Rose" wrote to "Jonathan Lennox, xml2rfc@lists.xml.resource.org" saying: > > I'm using version 1.23 of xml2rfc, and viewing its html output in Mozilla. > > > > I notice that when I mouse over an internal reference (i.e. of the type 'See > > Section 5'), I get an empty tooltip popping up. This is because its 'span' > > value has no content. Presumably it should contain the section's title, > > instead? > > yes. clearly a bug, fairly easy to fix. are you running xml2rfc locally > or are you using the web-based service on http://xml.resource.org/ ? Locally. Are the versions different? -jonathan From: Menachem.Dodge@infineon.com (Menachem.Dodge@infineon.com) Date: Tue, 13 Apr 2004 14:13:21 +0200 Subject: [xml2rfc] Conversion of a text format Internet-Draft or RFC to XML Message-ID: > Hi, > > I'm looking for a tool that will convert an Internet Draft or > RFC from text format into XML format > so that I can use the tool XML2RFC. This is particularly useful when > making changes to an existing document. I would appreciate your suggestions. > Regards, > Menachem Dodge. From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Mon, 12 Apr 2004 21:46:34 -0700 Subject: [xml2rfc] Empty tooltip in html output of xml2rfc 1.23 In-Reply-To: <16507.22218.112700.148696@cnr.cs.columbia.edu> References: <16507.22218.112700.148696@cnr.cs.columbia.edu> Message-ID: <20040412214634.3abf2ba9.mrose+internet.xml2rfc@dbc.mtview.ca.us> > I'm using version 1.23 of xml2rfc, and viewing its html output in Mozilla. > > I notice that when I mouse over an internal reference (i.e. of the type 'See > Section 5'), I get an empty tooltip popping up. This is because its 'span' > value has no content. Presumably it should contain the section's title, > instead? yes. clearly a bug, fairly easy to fix. are you running xml2rfc locally or are you using the web-based service on http://xml.resource.org/ ? thanks, /mtr From: lennox@cs.columbia.edu (Jonathan Lennox) Date: Mon, 12 Apr 2004 22:56:10 -0400 Subject: [xml2rfc] Empty tooltip in html output of xml2rfc 1.23 Message-ID: <16507.22218.112700.148696@cnr.cs.columbia.edu> --ZnNQ7GYbWf Content-Type: text/plain; charset=us-ascii Content-Description: message body and .signature Content-Transfer-Encoding: 7bit I'm using version 1.23 of xml2rfc, and viewing its html output in Mozilla. I notice that when I mouse over an internal reference (i.e. of the type 'See Section 5'), I get an empty tooltip popping up. This is because its 'span' value has no content. Presumably it should contain the section's title, instead? See attached xml and html. -- Jonathan Lennox lennox@cs.columbia.edu --ZnNQ7GYbWf Content-Type: text/xml Content-Disposition: inline; filename="test.xml" Content-Transfer-Encoding: 7bit Testing Tooltips in XML2RFC version 1.23 Columbia University This document tests tooltips in xml2rfc, revealing a bug in version 1.23.
Let us notice that the security considerations section is . If you're viewing html, mouse over that link; note its empty tooltip.
I don't think this problem has security issues, though.
--ZnNQ7GYbWf Content-Type: text/html Content-Disposition: inline; filename="test.html" Content-Transfer-Encoding: 7bit Testing Tooltips in XML2RFC version 1.23
Network Working GroupJ. Lennox
Internet-DraftColumbia University
Expires: October 11, 2004April 12, 2004

Testing Tooltips in XML2RFC version 1.23

draft-lennox-foo

Status of this Memo

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.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on October 11, 2004.

Copyright Notice

Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

This document tests tooltips in xml2rfc, revealing a bug in version 1.23.


1. Introduction

Let us notice that the security considerations section is Section 2. If you're viewing html, mouse over that link; note its empty tooltip.


2. Security Considerations

I don't think this problem has security issues, though.


Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Disclaimer of Validity

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

Acknowledgment

Funding for the RFC Editor function is currently provided by the Internet Society.

--ZnNQ7GYbWf-- From: ned.freed@mrochek.com (ned.freed@mrochek.com) Date: Thu, 08 Apr 2004 12:57:16 -0700 (PDT) Subject: [xml2rfc] poll: what editor do you use to author 2629? In-Reply-To: "Your message dated Thu, 08 Apr 2004 09:35:17 +0300" <4074F2A5.2050406@nokia.com> References: <20040407100826.1b7535d6.mrose+internet.xml2rfc@dbc.mtview.ca.us> <4074F2A5.2050406@nokia.com> Message-ID: <01L8OSLL8CEE0027NR@mauve.mrochek.com> I use either Exchanger XML Editor or BBEdit. The latter has much more extensive editing capabilities while the former gives me structural navigation and visualization, DTD/Schema based element and attribute completion, schema/DTD/Relax validity checking, XSLT support, the ability to immediately test XPath queries, and probably a lot of other stuff I haven't tried yet. Only really annoying thing about it so far are the PC-style key bindings. Ned From: aki.niemi@nokia.com (Niemi Aki (Nokia-M/Espoo)) Date: Thu, 08 Apr 2004 17:19:47 +0300 Subject: [xml2rfc] poll: what editor do you use to author 2629? In-Reply-To: <20040408063009.3a867f91.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040407100826.1b7535d6.mrose+internet.xml2rfc@dbc.mtview.ca.us> <4074F2A5.2050406@nokia.com> <20040408055238.4611ebd1.mrose+internet.xml2rfc@dbc.mtview.ca.us> <40754FCC.8080808@gmx.de> <20040408063009.3a867f91.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <40755F83.9040705@nokia.com> This is a multi-part message in MIME format. --------------050104030805010802060102 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Here's a copy in RELAX NG compact syntax. Cheers, Aki ext Marshall Rose wrote: >>Trang will happily take the DTD and generate an RNG file... > > > and if only i had a version of java on my system that trang would run on... > > /mtr --------------050104030805010802060102 Content-Type: text/plain; name="rfc2629.rnc" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rfc2629.rnc" # 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 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" NUMBER = string NUMBERS = string DAY = string MONTH = string YEAR = string URI = string ATEXT = string CTEXT = text TEXT = text # 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. rfc = element rfc { attlist.rfc, front, middle, back? } attlist.rfc &= attribute number { NUMBER }?, [ a:defaultValue = "" ] attribute obsoletes { NUMBERS }?, [ a:defaultValue = "" ] attribute updates { NUMBERS }?, [ a:defaultValue = "info" ] attribute category { "std" | "bcp" | "info" | "exp" | "historic" }?, attribute seriesNo { NUMBER }?, attribute ipr { "full2026" | "noDerivativeWorks2026" | "none" | "full3667" | "noModification3667" | "noDerivatives3667" }?, attribute iprExtract { xsd:IDREF }?, attribute docName { ATEXT }?, [ a:defaultValue = "en" ] attribute xml:lang { ATEXT }? # Front matter front = element front { attlist.front, title, author+, date, area*, workgroup*, keyword*, abstract?, note* } attlist.front &= empty # the "abbrev" attribute is used for headers, etc. title = element title { attlist.title, CTEXT } attlist.title &= attribute abbrev { ATEXT }? author = element author { attlist.author, organization, address? } attlist.author &= attribute initials { ATEXT }?, attribute surname { ATEXT }?, attribute fullname { ATEXT }?, attribute role { "editor" }? organization = element organization { attlist.organization, CTEXT } attlist.organization &= attribute abbrev { ATEXT }? address = element address { attlist.address, postal?, phone?, facsimile?, email?, uri? } attlist.address &= empty # at most one of each the city, region, code, and country # elements may be present postal = element postal { attlist.postal, street+, (city | region | code | country)* } attlist.postal &= empty street = element street { attlist.street, CTEXT } attlist.street &= empty city = element city { attlist.city, CTEXT } attlist.city &= empty region = element region { attlist.region, CTEXT } attlist.region &= empty code = element code { attlist.code, CTEXT } attlist.code &= empty country = element country { attlist.country, CTEXT } attlist.country &= empty phone = element phone { attlist.phone, CTEXT } attlist.phone &= empty facsimile = element facsimile { attlist.facsimile, CTEXT } attlist.facsimile &= empty email = element email { attlist.email, CTEXT } attlist.email &= empty uri = element uri { attlist.uri, CTEXT } attlist.uri &= empty date = element date { attlist.date, empty } attlist.date &= attribute day { DAY }?, attribute month { MONTH }?, attribute year { YEAR } # meta-data... area = element area { attlist.area, CTEXT } attlist.area &= empty workgroup = element workgroup { attlist.workgroup, CTEXT } attlist.workgroup &= empty keyword = element keyword { attlist.keyword, CTEXT } attlist.keyword &= empty abstract = element abstract { attlist.abstract, t+ } attlist.abstract &= empty note = element note { attlist.note, t+ } attlist.note &= attribute title { ATEXT } # The body # later on, may be (section+,appendix*,section*) middle = element middle { attlist.middle, section+ } attlist.middle &= empty section = element section { attlist.section, (t | figure | texttable | iref | section)* } attlist.section &= attribute anchor { xsd:ID }?, attribute title { ATEXT }, [ a:defaultValue = "default" ] attribute toc { "include" | "exclude" | "default" }? # # # use of
is deprecated... t = element t { attlist.t, (TEXT | \list | figure | xref | eref | iref | cref | spanx | vspace)* } attlist.t &= attribute hangText { ATEXT }? # the value of the style attribute is inherited from the closest # parent \list = element list { attlist.list, t+ } attlist.list &= [ a:defaultValue = "empty" ] attribute style { ATEXT }?, attribute hangIndent { NUMBER }?, attribute counter { ATEXT }? xref = element xref { attlist.xref, CTEXT } attlist.xref &= attribute target { xsd:IDREF }, [ a:defaultValue = "false" ] attribute pageno { "true" | "false" }?, [ a:defaultValue = "default" ] attribute format { "counter" | "title" | "none" | "default" }? eref = element eref { attlist.eref, CTEXT } attlist.eref &= attribute target { URI } iref = element iref { attlist.iref, empty } attlist.iref &= attribute item { ATEXT }, [ a:defaultValue = "" ] attribute subitem { ATEXT }?, [ a:defaultValue = "false" ] attribute primary { "true" | "false" }? cref = element cref { attlist.cref, CTEXT } attlist.cref &= attribute source { ATEXT }? spanx = element spanx { attlist.spanx, CTEXT } attlist.spanx &= [ a:defaultValue = "emph" ] attribute style { ATEXT }? vspace = element vspace { attlist.vspace, empty } attlist.vspace &= [ a:defaultValue = "0" ] attribute blankLines { NUMBER }? figure = element figure { attlist.figure, preamble?, artwork, postamble? } attlist.figure &= attribute anchor { xsd:ID }?, [ a:defaultValue = "" ] attribute title { ATEXT }? preamble = element preamble { attlist.preamble, (TEXT | xref | eref | iref | cref | spanx)* } attlist.preamble &= empty artwork = element artwork { attlist.artwork, TEXT* } attlist.artwork &= [ a:defaultValue = "preserve" ] attribute xml:space { "default" | "preserve" }?, [ a:defaultValue = "" ] attribute name { ATEXT }?, [ a:defaultValue = "" ] attribute type { ATEXT }?, attribute src { URI }?, [ a:defaultValue = "" ] attribute width { ATEXT }?, [ a:defaultValue = "" ] attribute height { ATEXT }? postamble = element postamble { attlist.postamble, (TEXT | xref | eref | iref | cref | spanx)* } attlist.postamble &= empty texttable = element texttable { attlist.texttable, preamble?, ttcol+, c*, postamble? } attlist.texttable &= attribute anchor { xsd:ID }?, [ a:defaultValue = "" ] attribute title { ATEXT }? ttcol = element ttcol { attlist.ttcol, CTEXT } attlist.ttcol &= attribute width { ATEXT }?, [ a:defaultValue = "left" ] attribute align { "left" | "center" | "right" }? c = element c { attlist.c, (TEXT | xref | eref | iref | cref | spanx)* } attlist.c &= empty # Back matter # sections, if present, are appendices back = element back { attlist.back, references*, section* } attlist.back &= empty references = element references { attlist.references, reference+ } attlist.references &= [ a:defaultValue = "References" ] attribute title { ATEXT }? reference = element reference { attlist.reference, front, seriesInfo*, format*, annotation* } attlist.reference &= attribute anchor { xsd:ID }?, attribute target { URI }? seriesInfo = element seriesInfo { attlist.seriesInfo, empty } attlist.seriesInfo &= attribute name { ATEXT }, attribute value { ATEXT } format = element format { attlist.format, empty } attlist.format &= attribute target { URI }?, attribute type { ATEXT }, attribute octets { NUMBER }? annotation = element annotation { attlist.annotation, (TEXT | xref | eref | iref | cref | spanx)* } attlist.annotation &= empty start = rfc --------------050104030805010802060102-- From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Thu, 8 Apr 2004 06:30:09 -0700 Subject: [xml2rfc] poll: what editor do you use to author 2629? In-Reply-To: <40754FCC.8080808@gmx.de> References: <20040407100826.1b7535d6.mrose+internet.xml2rfc@dbc.mtview.ca.us> <4074F2A5.2050406@nokia.com> <20040408055238.4611ebd1.mrose+internet.xml2rfc@dbc.mtview.ca.us> <40754FCC.8080808@gmx.de> Message-ID: <20040408063009.3a867f91.mrose+internet.xml2rfc@dbc.mtview.ca.us> > > Trang will happily take the DTD and generate an RNG file... and if only i had a version of java on my system that trang would run on... /mtr From: julian.reschke@gmx.de (Julian Reschke) Date: Thu, 08 Apr 2004 15:12:44 +0200 Subject: [xml2rfc] poll: what editor do you use to author 2629? In-Reply-To: <20040408055238.4611ebd1.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040407100826.1b7535d6.mrose+internet.xml2rfc@dbc.mtview.ca.us> <4074F2A5.2050406@nokia.com> <20040408055238.4611ebd1.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <40754FCC.8080808@gmx.de> Marshall Rose wrote: >>Emacs, with nXML mode. > > > do you, or anyone else, have a RELAX NG schema for rfc2629? if so, care to > share? Trang will happily take the DTD and generate an RNG file... Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Thu, 8 Apr 2004 05:52:38 -0700 Subject: [xml2rfc] poll: what editor do you use to author 2629? In-Reply-To: <4074F2A5.2050406@nokia.com> References: <20040407100826.1b7535d6.mrose+internet.xml2rfc@dbc.mtview.ca.us> <4074F2A5.2050406@nokia.com> Message-ID: <20040408055238.4611ebd1.mrose+internet.xml2rfc@dbc.mtview.ca.us> > Emacs, with nXML mode. do you, or anyone else, have a RELAX NG schema for rfc2629? if so, care to share? /mtr From: aki.niemi@nokia.com (Niemi Aki (Nokia-M/Espoo)) Date: Thu, 08 Apr 2004 09:35:17 +0300 Subject: [xml2rfc] poll: what editor do you use to author 2629? In-Reply-To: <20040407100826.1b7535d6.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040407100826.1b7535d6.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <4074F2A5.2050406@nokia.com> Emacs, with nXML mode. Cheers, Aki ext Marshall Rose wrote: > > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc From: john+xml@jck.com (John C Klensin) Date: Wed, 07 Apr 2004 20:34:34 -0400 Subject: [xml2rfc] poll: what editor do you use to author 2629? In-Reply-To: <20040408005423.60474fed.henrik@levkowetz.com> References: <20040407190003.24214.76317.Mailman@qawoor.dbc.mtview .ca.us> <76332870.1081351053@scan.jck.com> <20040408005423.60474fed.henrik@levkowetz.com> Message-ID: <95353290.1081370074@scan.jck.com> --On Thursday, 08 April, 2004 00:54 +0200 Henrik Levkowetz wrote: > Hi John, > > Wednesday 7 April 2004, John C Klensin wrote: >> Epsilon under Windows. Epsilon or GNU Emacs under FreeBSD. >> Various tools under FreeBSD, including the XML toolkit, when >> I get myself into trouble. > > Which XML toolkit is that? I tried to google for it, but there > seems to be many tens of different ones... I've been using Libxml2 from http://xmlsoft.org/ and Libxml for Windows from http://www.zlatkovic.com/libxml.en.html. The pointer to the first came from Carl Malamud; I think I found the Windows port poking around that site. xmllint from that kit has been especially useful, again suggested by Carl. john From: stpeter@jabber.org (Peter Saint-Andre) Date: Wed, 7 Apr 2004 18:12:55 -0500 Subject: [xml2rfc] poll: what editor do you use to author 2629? In-Reply-To: <20040407224839.GA42727@finch-staff-1.thus.net> References: <20040407100826.1b7535d6.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20040407224839.GA42727@finch-staff-1.thus.net> Message-ID: <20040407231255.GA3664@jabber.org> On Wed, Apr 07, 2004 at 11:48:39PM +0100, Clive D.W. Feather wrote: > vi vi forever! Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.php From: henrik@levkowetz.com (Henrik Levkowetz) Date: Thu, 8 Apr 2004 00:54:23 +0200 Subject: [xml2rfc] poll: what editor do you use to author 2629? In-Reply-To: <76332870.1081351053@scan.jck.com> References: <20040407190003.24214.76317.Mailman@qawoor.dbc.mtview .ca.us> <76332870.1081351053@scan.jck.com> Message-ID: <20040408005423.60474fed.henrik@levkowetz.com> --Signature=_Thu__8_Apr_2004_00_54_23_+0200_YYakwb8hjF=1c_PZ Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi John, Wednesday 7 April 2004, John C Klensin wrote: > Epsilon under Windows. Epsilon or GNU Emacs under FreeBSD. > Various tools under FreeBSD, including the XML toolkit, when I > get myself into trouble. Which XML toolkit is that? I tried to google for it, but there seems to be many tens of different ones... Henrik --Signature=_Thu__8_Apr_2004_00_54_23_+0200_YYakwb8hjF=1c_PZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAdIareVhrtTJkXCMRAvDnAJwPQGPfrO5Tva1WU5f9Ody5vxuYLQCdF6me 1436ZGlr4zBQiNK5UBURnGE= =C3Zr -----END PGP SIGNATURE----- --Signature=_Thu__8_Apr_2004_00_54_23_+0200_YYakwb8hjF=1c_PZ-- From: clive@demon.net (Clive D.W. Feather) Date: Wed, 7 Apr 2004 23:48:39 +0100 Subject: [xml2rfc] poll: what editor do you use to author 2629? In-Reply-To: <20040407100826.1b7535d6.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040407100826.1b7535d6.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <20040407224839.GA42727@finch-staff-1.thus.net> vi -- 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: rousskov@measurement-factory.com (Alex Rousskov) Date: Wed, 7 Apr 2004 16:12:36 -0600 (MDT) Subject: [xml2rfc] editorial comments In-Reply-To: <20040407234017.6808ffe7.henrik@levkowetz.com> References: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20040405080425.GD32517@finch-staff-1.thus.net> <4073ADFD.1040309@gmx.de> <20040407134328.4e5a19d9.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20040407234017.6808ffe7.henrik@levkowetz.com> Message-ID: On Wed, 7 Apr 2004, Henrik Levkowetz wrote: > 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 -1 on having it as the only possibility Alex. From: henrik@levkowetz.com (Henrik Levkowetz) Date: Wed, 7 Apr 2004 23:40:17 +0200 Subject: [xml2rfc] editorial comments In-Reply-To: <20040407134328.4e5a19d9.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20040405080425.GD32517@finch-staff-1.thus.net> <4073ADFD.1040309@gmx.de> <20040407134328.4e5a19d9.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <20040407234017.6808ffe7.henrik@levkowetz.com> --Signature=_Wed__7_Apr_2004_23_40_17_+0200_NWJPBe.u6aIUU=FJ Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi Marshall, Wednesday 7 April 2004, Marshall Rose wrote: > 1. i prefer the name for the reason noted here. > > > >>1. a element that can appear anywhere , , or > > >> may appear: Works for me. > > > 2. since everyone except me seems to like inline comments, i would prefer > to have > > > > indicate whether comments should be rendered; if so, they will always > be rendered inline. Wednesday 31 March 2004, I wrote: > > 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 > 3. we can add an optional anchor attribute to the element which > will work just like the anchors in
,
, > , and . Works for me. Henrik --Signature=_Wed__7_Apr_2004_23_40_17_+0200_NWJPBe.u6aIUU=FJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAdHVIeVhrtTJkXCMRAmnlAJ9J+DHAT0z1AK+zXWHRwA2OKr3oXwCfWwgK RGILI6ZfoMjVPVW7uJajNCE= =5BGX -----END PGP SIGNATURE----- --Signature=_Wed__7_Apr_2004_23_40_17_+0200_NWJPBe.u6aIUU=FJ-- From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Wed, 7 Apr 2004 13:43:28 -0700 Subject: [xml2rfc] editorial comments In-Reply-To: <4073ADFD.1040309@gmx.de> References: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20040405080425.GD32517@finch-staff-1.thus.net> <4073ADFD.1040309@gmx.de> Message-ID: <20040407134328.4e5a19d9.mrose+internet.xml2rfc@dbc.mtview.ca.us> 1. i prefer the name for the reason noted here. > >>1. a element that can appear anywhere , , or > >> may appear: 2. since everyone except me seems to like inline comments, i would prefer to have indicate whether comments should be rendered; if so, they will always be rendered inline. 3. we can add an optional anchor attribute to the element which will work just like the anchors in
,
, , and . /mtr From: dmm@1-4-5.net (David Meyer) Date: Wed, 7 Apr 2004 13:34:14 -0700 Subject: [xml2rfc] poll: what editor do you use to author 2629? In-Reply-To: <20040407195910.GA1848@sbrim-w2k01> References: <20040407100826.1b7535d6.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20040407195910.GA1848@sbrim-w2k01> Message-ID: <20040407203414.GA12461@1-4-5.net> >> emacs xemacs Dave From: henrik@levkowetz.com (Henrik Levkowetz) Date: Wed, 7 Apr 2004 22:03:35 +0200 Subject: [xml2rfc] poll: what editor do you use to author 2629? In-Reply-To: <20040407100826.1b7535d6.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040407100826.1b7535d6.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <20040407220335.2026e44d.henrik@levkowetz.com> Epsilon on Linux. Gives XML highlighting (colouring) but no validity checks. Henrik From: swb@employees.org (Scott W Brim) Date: Wed, 7 Apr 2004 15:59:10 -0400 Subject: [xml2rfc] poll: what editor do you use to author 2629? In-Reply-To: <20040407100826.1b7535d6.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040407100826.1b7535d6.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <20040407195910.GA1848@sbrim-w2k01> emacs From: john+xml@jck.com (John C Klensin) Date: Wed, 07 Apr 2004 15:17:33 -0400 Subject: [xml2rfc] poll: what editor do you use to author 2629? In-Reply-To: <20040407190003.24214.76317.Mailman@qawoor.dbc.mtview.ca.us> References: <20040407190003.24214.76317.Mailman@qawoor.dbc.mtview .ca.us> Message-ID: <76332870.1081351053@scan.jck.com> --On Wed, 7 Apr 2004 10:08:26 -0700, Marshall Rose wrote... Epsilon under Windows. Epsilon or GNU Emacs under FreeBSD. Various tools under FreeBSD, including the XML toolkit, when I get myself into trouble. john From: julian.reschke@gmx.de (Julian Reschke) Date: Wed, 07 Apr 2004 21:13:56 +0200 Subject: [xml2rfc] poll: what editor do you use to author 2629? In-Reply-To: <20040407100826.1b7535d6.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040407100826.1b7535d6.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <407452F4.9050300@gmx.de> HTML-Kit (free, does XML highlighting, wf- and validity checks through plugins, and has a quick preview feature by just opening the document in a browser using mx XSLT code). -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Wed, 7 Apr 2004 10:08:26 -0700 Subject: [xml2rfc] poll: what editor do you use to author 2629? Message-ID: <20040407100826.1b7535d6.mrose+internet.xml2rfc@dbc.mtview.ca.us> From: rousskov@measurement-factory.com (Alex Rousskov) Date: Wed, 7 Apr 2004 09:12:09 -0600 (MDT) Subject: [xml2rfc] editorial comments In-Reply-To: <4073ADFD.1040309@gmx.de> References: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20040405080425.GD32517@finch-staff-1.thus.net> <4073ADFD.1040309@gmx.de> Message-ID: On Wed, 7 Apr 2004, Julian Reschke wrote: > Clive D.W. Feather wrote: > > > I'd suggest rather than , particularly if you're going to > > allow inline versions. > > Sounds reasonable. I agree that or something shorter like , , or would match the semantics a lot better than (regardless of how it is rendered). > I'd like to be able to control the identifiers for the comments, so > that I can have stable URI references to them (anchor?). Makes a lot of sense to me. FWIW, I think that anchor should be an optional part of every element that can potentially be linked to via a URI. Thank you, Alex. From: julian.reschke@gmx.de (Julian Reschke) Date: Wed, 07 Apr 2004 13:59:58 +0200 Subject: [xml2rfc] editorial comments In-Reply-To: <015b01c41c94$6776c130$0200a8c0@DFNJGL21> References: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20040405080425.GD32517@finch-staff-1.thus.net> <4073ADFD.1040309@gmx.de> <015b01c41c94$6776c130$0200a8c0@DFNJGL21> Message-ID: <4073ED3E.5010904@gmx.de> Spencer Dawkins wrote: > A newbie interpretation... > > From: "Julian Reschke" > > >>Clive D.W. Feather wrote: >> >>Good idea. In addition, I'd like to be able to control the > > identifiers > >>for the comments, so that I can have stable URI references to them >>(anchor?). > > > So the idea would be that I could have all my comments look like > > Spencer: this is less brilliant than usual > > by using the same identifier each time ("Spencer"), and you could have > unique identifiers for each comment that look like > > JR-frommage: The frommage doesn't actually work this way > > and use them in URIs, or did I misunderstand? Almost. I'd have both an identifier for who has made the comment, and a specific one for the comment itself. When rendering to HTML, you can then generate in-document fragment identifiers for use in URI references. In particular, a comment would keep it's identifier if a new comment is inserted before that one. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: Spencer Dawkins" <20040405080425.GD32517@finch-staff-1.thus.net> <4073ADFD.1040309@gmx.de> Message-ID: <015b01c41c94$6776c130$0200a8c0@DFNJGL21> A newbie interpretation... > From: "Julian Reschke" > Clive D.W. Feather wrote: > > Good idea. In addition, I'd like to be able to control the identifiers > for the comments, so that I can have stable URI references to them > (anchor?). So the idea would be that I could have all my comments look like Spencer: this is less brilliant than usual by using the same identifier each time ("Spencer"), and you could have unique identifiers for each comment that look like JR-frommage: The frommage doesn't actually work this way and use them in URIs, or did I misunderstand? Spencer From: julian.reschke@gmx.de (Julian Reschke) Date: Wed, 07 Apr 2004 09:30:05 +0200 Subject: [xml2rfc] editorial comments In-Reply-To: <20040405080425.GD32517@finch-staff-1.thus.net> References: <20040329165552.096517ae.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20040405080425.GD32517@finch-staff-1.thus.net> Message-ID: <4073ADFD.1040309@gmx.de> Clive D.W. Feather wrote: >>1. a element that can appear anywhere , , or >> may appear: >> >> >> > source %ATEXT; #REQUIRED> > > > I'd suggest rather than , particularly if you're going to > allow inline versions. Sounds reasonable. >>2. a processing instruction, , that directs the >> processor whether to render the comments (by default, 'no'). > > > I support those who'd also like a way to put it inline. I'm not sure yet > whether that's better as a processing instruction or as a flag on each > comment. > > My experience with my own pre-processing suggests that you need two kinds > of comment: > - "short" comments that sit within text, as you've suggested; > - "long" comments that can be made visible or hidden, but that contain > one or more paragraphs and other things (structurally, they're a variant > on
but with no number. Same here. > The former are used for the "check this with Fred" type of comment, and the > latter for "here are the pros and cons of this approach" type of comment. > > Finally, based on a previous suggestion, it would be good to have a flag > that indicates resolved/unresolved, and a PI that generates a major error > if there are any unresolved comments. Good idea. In addition, I'd like to be able to control the identifiers for the comments, so that I can have stable URI references to them (anchor?). Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Mon, 5 Apr 2004 07:13:10 -0700 Subject: [xml2rfc] v1.23 released In-Reply-To: <40712860.4020607@gmx.de> References: <20040402091505.62998338.mrose+internet.xml2rfc@dbc.mtview.ca.us> <40712860.4020607@gmx.de> Message-ID: <20040405071310.00cef8c6.mrose+internet.xml2rfc@dbc.mtview.ca.us> > Added to rfc2629.xslt. I would habe preferred a syntax that doesn't > allow "illegal" combinations, though. Shouldn't we make these > warnings/errors? (for instance, not having a toc entry for the parent > section of a section that *does* have a toc entry) i guess it depends on whether one views that as "illegal" or not. > > - multiple elements are placed under a top-level section > > called "References" > > As far as I understand this means also that the single references > section we have now also has been changed to appear as last regular > (numbered) section in the document. > > Are there more similar changes ahead? Such as adding IPR or Authors to > the regular sections? Does the RFC Editor now have a single approach for > this? i have not been so informed. there are about six other "issues" they have, which i've asked for clarification, but have not yet heard back on. /mtr From: julian.reschke@gmx.de (Julian Reschke) Date: Mon, 05 Apr 2004 11:35:28 +0200 Subject: [xml2rfc] v1.23 released In-Reply-To: <20040402091505.62998338.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20040402091505.62998338.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <40712860.4020607@gmx.de> Marshall Rose wrote: > enhancements: > - optional "toc" attribute for the
element Added to rfc2629.xslt. I would habe preferred a syntax that doesn't allow "illegal" combinations, though. Shouldn't we make these warnings/errors? (for instance, not having a toc entry for the parent section of a section that *does* have a toc entry) > - additional use of CSS for HTML generation > - proper exit value when running under make > > bug fixes: > - proper interpretation of ampersand ("&") in attribute values and > character data > - boilerplate citation RFC 3668 (instead of RFC 3667) Fixed in rfc2629.xslt. > - the "subcompact" PI now defaults correctly > - proper escaping of apostrophe ("'") for nroff generation > > other changes: > - the "tocident" PI now defaults to "yes" Is ignored by rfc2629.xslt (which happens to indent always). > - multiple elements are placed under a top-level section > called "References" (Implemented in rfc2629.xslt). As far as I understand this means also that the single references section we have now also has been changed to appear as last regular (numbered) section in the document. Are there more similar changes ahead? Such as adding IPR or Authors to the regular sections? Does the RFC Editor now have a single approach for this? > experimental changes (still under development): > - addition of element (see separate mail). The updated rfc2629.xslt is available from . Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: clive@demon.net (Clive D.W. Feather) Date: Mon, 5 Apr 2004 09:04:25 +0100 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: <20040405080425.GD32517@finch-staff-1.thus.net> Marshall Rose said: > i wish to propose markup that will allow authors to insert editorial > comments into their documents. [Just back off holiday, so I've only just seen this.] > there are two parts to the proposal: > > 1. a element that can appear anywhere , , or > may appear: > > > source %ATEXT; #REQUIRED> I'd suggest rather than , particularly if you're going to allow inline versions. > 2. a processing instruction, , that directs the > processor whether to render the comments (by default, 'no'). I support those who'd also like a way to put it inline. I'm not sure yet whether that's better as a processing instruction or as a flag on each comment. My experience with my own pre-processing suggests that you need two kinds of comment: - "short" comments that sit within text, as you've suggested; - "long" comments that can be made visible or hidden, but that contain one or more paragraphs and other things (structurally, they're a variant on
but with no number. The former are used for the "check this with Fred" type of comment, and the latter for "here are the pros and cons of this approach" type of comment. Finally, based on a previous suggestion, it would be good to have a flag that indicates resolved/unresolved, and a PI that generates a major error if there are any unresolved comments. -- 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: john+xml@jck.com (John C Klensin) Date: Sun, 04 Apr 2004 13:08:07 -0400 Subject: [xml2rfc] editorial comments In-Reply-To: <20040330200002.10332.89222.Mailman@qawoor.dbc.mtview.ca.us> References: <20040330200002.10332.89222.Mailman@qawoor.dbc.mtview .ca.us> Message-ID: <2045791.1081084087@[10.1.1.14]> --On Tuesday, March 30, 2004 12:00 -0800 xml2rfc-request@lists.xml.resource.org wrote: > 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? Marshall, Sorry for the delay in answering -- on travel and a bit overloaded. I think there nearly has to be at least option for breaking up the flow -- in many cases, anything else would not be useful. Perhaps a useful way to look at the distinction is that, as a document editor, I use these comments in two ways: (i) to write notes to myself about some loose end I need to tie up in the current draft before posting or in some future draft and (ii) to write notes to the relevant reader (perhaps the membership in a WG) to call attention to things they need to do or to which they need to pay careful attention. john From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Fri, 2 Apr 2004 09:15:05 -0800 Subject: [xml2rfc] v1.23 released Message-ID: <20040402091505.62998338.mrose+internet.xml2rfc@dbc.mtview.ca.us> enhancements: - optional "toc" attribute for the
element - additional use of CSS for HTML generation - proper exit value when running under make bug fixes: - proper interpretation of ampersand ("&") in attribute values and character data - boilerplate citation RFC 3668 (instead of RFC 3667) - the "subcompact" PI now defaults correctly - proper escaping of apostrophe ("'") for nroff generation other changes: - the "tocident" PI now defaults to "yes" - multiple elements are placed under a top-level section called "References" experimental changes (still under development): - addition of element ####### From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Thu, 1 Apr 2004 08:13:29 -0800 Subject: [xml2rfc] Bug report: 3667 - 3668 exchanged In-Reply-To: <406A77BF.4060000@nokia.com> References: <406A77BF.4060000@nokia.com> Message-ID: <20040401081329.166e3028.mrose+internet.xml2rfc@dbc.mtview.ca.us> > 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. > ^^^^ i agree. the next release, which should be quite soon, will contain a fix. /mtr From: aki.niemi@nokia.com (Niemi Aki (Nokia-M/Espoo)) Date: Thu, 01 Apr 2004 10:13:21 +0300 Subject: [xml2rfc] Bug report: 3667 - 3668 exchanged In-Reply-To: <406A9506.8090505@nokia.com> References: <406A77BF.4060000@nokia.com> <406A9506.8090505@nokia.com> Message-ID: <406BC111.3080308@nokia.com> This is a multi-part message in MIME format. --------------070902080802020009010501 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Here's a patch that should fix this. Cheers, Aki ext Miguel Garcia wrote: > > 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 > > --------------070902080802020009010501 Content-Type: text/plain; name="xml2rfc.tcl.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xml2rfc.tcl.patch" --- xml2rfc.tcl 2004-02-20 22:24:58.000000000 +0200 +++ xml2rfc.tcl.new 2004-04-01 09:57:53.000000000 +0300 @@ -3313,14 +3313,14 @@ 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."} +in accordance with RFC 3668."} {noModification3667 "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. +in accordance with RFC 3668. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other @@ -3331,7 +3331,7 @@ 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. +in accordance with RFC 3668. This document may not be modified, and derivative works of it may not be created%IPREXTRACT%."} } --------------070902080802020009010501--