W3C home > Mailing lists > Public > public-html@w3.org > November 2008

Re: Splitting up the spec

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 24 Nov 2008 14:07:48 -0800
Message-ID: <492B25B4.3070909@sicking.cc>
To: Julian Reschke <julian.reschke@gmx.de>
CC: Jim Jewett <jimjjewett@gmail.com>, HTML WG <public-html@w3.org>

Julian Reschke wrote:
> Jonas Sicking wrote:
>> ...
>> So lets put it the other way around. Say that the CSS 1 spec would
>> have looked the way it does, but it also defined the rel and name
>> attributes for the <link> tag, and how they are used to link
>> alternate, preferred and persistent stylesheets to HTML. Don't you
>> think that someone would have said "That stuff doesn't belong in the
>> CSS spec, that is HTML specific, CSS doesn't define how a specific
>> markup language should link to CSS"?
>> ...
> 
> Good point.
> 
> Funny enough, that's exactly what we have in the situation of XML and 
> XSLT (where the PI is described in a separate document).

Yup, that is one way of doing it. Have separate specs to cover the 
integration points between other specs. However the strategy tends to 
balloon the number of specs. For example there are a number of things 
that needs to be defined in the integration-point between the PI and 
XSLT. The PI spec is generic spec for linking XML resources to 
stylesheets, but there are some special things that need to be defined 
when that stylesheet is an XSLT stylesheet.

This is currently undefined and does result in browser behavior actually 
being vastly different in how they process XSLT stylesheets. For 
example, do scripts in the source document execute? And more 
importantly, how is the output from the XSLT treated? I.e. is the output 
tree displayed directly, or is it serialized and reparsed as the new 
page. Turns out all other browsers than gecko based ones serialize and 
reparse, and pages depend on that, those pages do not work in firefox.

Sure, you can come up with a spec that defines the integration between 
the PI spec and the XSLT spec. And you can argue that the problem with 
undefined behavior right now isn't because the PI spec is missing 
information or that the XSLT spec is missing information, but rather 
that no-one wrote the spec about integrating the two.

However the more you split up specs the more this exact thing occurs. 
There will be more undefined integration spots. Sure, you can patch it 
by adding more specs that define the integration spots, but then you 
also end up with integration points between the integration specs and 
the other specs. As shown above this is not a theoretical problem but 
does actually happen and does cause problems.

So like I said in a recent mail. Splitting up the spec is certainly 
doable. And it does have advantages. But it does also have some very 
serious disadvantages. Some these disadvantages are a major reason that 
the web is as complex as it is today.

Is that a cost that we are willing to take?

/ Jonas
Received on Monday, 24 November 2008 22:10:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:26 GMT