).
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 within CDATA?
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?
>
> 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