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

Re: Splitting up the spec

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 24 Nov 2008 23:36:37 +0100
Message-ID: <492B2C75.1070305@gmx.de>
To: Jonas Sicking <jonas@sicking.cc>
CC: Jim Jewett <jimjjewett@gmail.com>, HTML WG <public-html@w3.org>

Jonas Sicking wrote:
> 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.

Understood, and yes that's a problem (this is, for instance, about 
disable-output-escaping, right?).

So I think what *is* a problem is that the XSLT-PI spec is too terse, 
and didn't get maintained.

> 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.

I thought there is a specific spec for it, but right now I can't check 
because www.w3.org seems to be down...

> 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.

I agree it can happen, but I would think the problem isn't the number of 
specs, but lack of clarity who's responsible for what.

> 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?

I do agree that *if* we split the spec into smaller parts, we make sure 
that things like the one you mentioned do not occur.

BR, Julian
Received on Monday, 24 November 2008 22:38:22 GMT

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