- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 24 Nov 2008 23:36:37 +0100
- 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 UTC