[rfc-i] Potential RFC format approach: HTML

Dave Crocker dhc at dcrocker.net
Sat Mar 24 03:09:38 PDT 2012



On 3/24/2012 9:33 AM, Julian Reschke wrote:
>> - Subset HTML. The subset would be decided upon based on current wide
>> support, expectation that it will continue to work, repeatability, stability
>> of output, etc. However, as long as old-ish browsers can render the output,
>> they might not need to get the full experience.
>
> +1 in general. The requirement "expectation that it will continue to work" isn't
> really helping, because in practice, anything that is widely used today isn't
> going to go away.

Oh boy.

In spite of the fact that you are an experienced and prudent guy, let me suggest 
your above assertion is not terribly prudent.

The strength of the ASCII base has been its minimal processing requirements and 
its excellent, long-term stability.

HTML isn't even close to trivial, by that metric.  Worse, as soon as you say 
"subset" you mandate specialized software.

"HTML" in the open Internet is spectacularly variable.  It works because HTML 
engines know to process quite a bit of that variation.  The remainder doesn't 
get processed properly.

This establishes an extremely unstable processing base, no matter how widely 
usable it is at any given moment, such as "today".

In an environment like that, any assurances of future support -- say 30 or 50 
years from now, nevermind 100 -- is problematic.


> I believe what's as important is to profile the document structure, define
> default CSS (we want some uniformity, right?), and recommend certain ways to use

css.  Excellent.  A parallel item to support and hope is compatible decades from 
now, if the item can be found.


>> - Define a very strict structure, using a microformat/semantic style, that
>> makes it easy to pull out information semantically with a little bit of
>> jQuery in post-processing tools. Make a choice about XML-style
>> well-formedness, which is probably not needed.
>
> +-0; it's possible to embed all metadata in the HTML, but that makes us depend
> on conventions (microformats) or specs that are currently a bit in flux (RDFa vs

flux.  exactly the right word.

For the current exercise, the requirement to attain long-term viability that is 
on a par with what was achieved with the original ASCII base, is simplicity and 
stability.

It's not enough to be clever with something that can "be made to work".  It 
might or might not work tomorrow.  Anyone thinking otherwise needs to produce a 
comparable historical basis for their belief.


d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net


More information about the rfc-interest mailing list