<br><br><div class="gmail_quote">On Sat, May 26, 2012 at 12:43 PM, Tim Bray <span dir="ltr">&lt;<a href="mailto:tbray@textuality.com" target="_blank">tbray@textuality.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Fri, May 25, 2012 at 8:46 AM, Phillip Hallam-Baker <span dir="ltr">&lt;<a href="mailto:hallam@gmail.com" target="_blank">hallam@gmail.com</a>&gt;</span> wrote:<br></div><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Watching this discussion I can see some points that I think that most reasonable people can agree on and I would like to suggest that these actually give us a pretty clear way forward as far as at least a first step goes.<div>


<br></div><div><i><b>Proposition 0:</b> The objective of having IDs and RFCs is to communicate information to readers. Format proposals should be judged on their effectiveness as a communication medium and the demands they impose on document producers</i></div>

</blockquote></div><div><br>-1 The convenience and productivity of authors canít be ignored.† Itís a balancing act.<br></div></div></blockquote><div><br></div><div>The objective is communication. The cost of producing the documents has to be balanced against the advantages but is not the ultimate objective. I did say the damands imposed on the authors is relevant but I am happy to change the wording.</div>
<div><br></div><div>†</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div></div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<b>Proposition 1:</b> It is reasonable for a participant to request the ability to read IDs and RFCs in a particular format.<br><div><i><b>Proposition 2:</b> It is utterly unreasonable for anyone to demand that others read IDs and RFCs in a particular format unless there are specific reasons why a particular format is necessary</i><br>

</div></blockquote></div><div><br>meh - I donít think these propositions are useful in informing the discussion. <br>†</div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div>
<i><b>Proposition 3:</b> How to support included files (images, source code) should be considered separately from whether to support them</i><br></div></blockquote></div><div><br>-1. This is a cost/benefit analysis, nothing more.† In my case, since I think the benefit of adding images is very low, I would be opposed to any proposal where image provision imposed any significant costs on writer or reader.<br>
</div></div></blockquote><div><br></div><div>I don&#39;t think there is much dispute as to the value of included source files. Since the technical demands for images would be identical, can&#39;t we just agree for the sake of argument that we are going to be dealing with a compound document and defer the discussion of which ones we are going to support?</div>
<div><br></div><div>We have had ABNF and XML Schema in RFCs for ages. It would be nice if we had tools that could check syntax and nits for those as well as the main text.</div><div><br></div><div>†</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div></div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><i><b>Proposition 4: </b>XML2RFC MUST continue to be supported as an input format<br>

</i></div></div></blockquote></div><div><br>+1<br>†</div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><i><b>Proposition 5: </b>HTML MUST be supported as an output format</i></div>

</div></blockquote></div><div><br>+1<br>†</div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><i><b>Proposition 6:†</b>HTML output SHOULD use a restricted set of HTML features.</i><i><br>

</i></div></div></blockquote></div><div><br>-1 - Iíd say MUST.† The thought of dealing with the full cruftiness of ďHTML as she are spokeĒ makes my blood run cold.<br></div></div></blockquote><div><br></div><div>OK, strengthen that to a MUST, I don&#39;t think anyone is actually arguing for unrestricted HTML.</div>
<div><br></div><div>†</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div></div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div><div><i>
<b>Proposition 7:</b> HTML is capable of serving as both an input format and an output format</i></div></div></blockquote></div><div><br>Not qualified to comment. Iím perfectly comfy with authoring raw HTML, or xml2rfc input, in an Emacs buffer, but I worry that there are still a lot of people out there who blench at the thought of having to look at pointy brackets.<br>
</div></div></blockquote><div>†</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div></div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><br><div><b>1) A profile of HTML for use in RFCs and IDs</b>. This would specify permitted tags, required metadata and class identifiers to be applied so that the document displays correctly with the associated stylesheet. It MUST be possible to roundtrip information from the HTML profile to the XML2RFC format and back.</div>

</div></blockquote></div><div><br>Agreed on the subset, but Iím unconvinced that the round-tripping is practical.† Not saying I flatly disbelieve; just that it might be harder than you think.</div></div></blockquote><div>
<br></div><div>XML2RFC does have ten years practical experience built in. So being able to convert back and forth would provide at least some form of sanity check on the proposal.</div><div><br></div><div>I don&#39;t think it is particularly hard to do either.</div>
<div><br></div><div>†</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>†</div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div><b>2) Stylesheets</b> for IETF, ISOC, etc documents.</div></blockquote></div><div><br>+1 <br></div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div><br></div><div><b>3) Modify the existing XML2RFC</b> toolchain to generate the new HTML format</div></div></blockquote></div><div><br>I suspect it will be about as easier to reimplement; and far easier to find someone to reimplement than to modify.<br>
</div></div></blockquote><div><br></div><div>Yeah, whatev.</div><div>†</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div></div><div class="im">
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<div><br></div><div><b>4) HTML2RFC tool.</b> This would perform nits checking and be capable of generating the corresponding XML2RFC file.</div></div></blockquote></div><div><br>Unknown degree-of-difficulty<br></div></div>
</blockquote><div><br></div><div>I don&#39;t think it at all hard to do with C# and .NET.</div><div><br></div><div>I will let you know if I was right.</div><div>†</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div></div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><div><b>5) Modify the publication Web</b> site so that the HTML versions of the drafts are visible alongside the traditional format, pdf etc.</div></div></blockquote></div><div><br>+1<br>†</div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div>
<div><b>6) Modify the submission tool</b> so that ALL that is required to submit a draft is to provide either the XML2RFC format or the HTML format (or the traditional format)</div></div></blockquote></div><div><br>+1<br>
</div></div></blockquote></div><br clear="all"><div><br></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br><br>