Bug 14689 - xml-stylesheet with type=text/xsl needs to be handled explicitly
xml-stylesheet with type=text/xsl needs to be handled explicitly
Status: REOPENED
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec
unspecified
PC Windows NT
: P2 normal
: ---
Assigned To: This bug has no owner yet - up for the taking
HTML WG Bugzilla archive list
exclusion
:
Depends on:
Blocks: 17976
  Show dependency treegraph
 
Reported: 2011-11-03 19:02 UTC by Henry S. Thompson
Modified: 2013-03-22 18:06 UTC (History)
15 users (show)

See Also:


Attachments
xml-stylesheet PI test cases (3.96 KB, application/octet-stream)
2011-11-22 13:51 UTC, Henry S. Thompson
Details
multiple stylesheet PI tests (4.36 KB, application/octet-stream)
2012-10-11 22:24 UTC, Henry S. Thompson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Henry S. Thompson 2011-11-03 19:02:01 UTC
Section 5.5.3 "Page load processing model for XML files" currently mentions xml-stylesheet only in connection with its interaction with the application cache.  The XML Core WG requests that prose be added to cover the case where an xml-stylesheet PI is present, with type other than text/css, and in particular to handle the case where type='text/xsl' or type='application/xslt+xml' by invoking XSLT with the referenced stylesheet and starting the page load process over with the results, consistent with existing browser practice.

The WG also suggests that it might be a good idea to cover the case where no stylesheet PI is present and the root element is not 'html', where existing practice is to produce a default indented tree view of the XML itself.
Comment 1 Ian 'Hixie' Hickson 2011-11-03 23:15:13 UTC
What should the requirements be for the first case?

The second case is already handled by the navigation algorithm as far as I can tell.
Comment 2 Henry S. Thompson 2011-11-03 23:22:13 UTC
(In reply to comment #1)
> What should the requirements be for the first case?

I attempted to give them: invoke XSLT on the current Document with the referenced stylesheet, adopt the result as the current Document.  There are signs you had already anticipated this, for example wrt the timing of <script> in the result, so I'm not sure what you're missing. . .

> The second case is already handled by the navigation algorithm as far as I can
> tell.

Hmm, I tried to track it through the steps of that algorithm and it seemed to fall all the way through -- which clause do you think picks it up?
Comment 3 Ian 'Hixie' Hickson 2011-11-11 20:05:19 UTC
(we spoke about this in person; the second issue will be split into a second bug, and for the first issue we need either some tests demonstrating exactly what is going on, or some proposed text.
Comment 4 Henry S. Thompson 2011-11-22 13:51:33 UTC
Created attachment 1046 [details]
xml-stylesheet PI test cases

A modest set of test cases illustrating existing browser behaviour in response to XML documents with xml-stylesheet processing instructions which reference XSLT stylesheets
Comment 5 Henry S. Thompson 2011-11-22 13:57:06 UTC
Note that the above test cases only cover _single_ xml-stylesheet PIs.  There's
rather a lot of variation in how _multiple_ PIs (of the same type) are handled,
more tests will eventually be forthcoming wrt this issue.  Preliminary
investigation with type='text/css' suggests that Firefox and Opera implement
the spec'd behaviour of offering user choice when the alternate="yes"
pseudo-attribute is present, but Chrome and IE do not (at least, I haven't
found a place where they make the offer, if there is one).
Comment 6 Henry S. Thompson 2011-11-23 09:59:27 UTC
(In reply to comment #5)
> . . .  Preliminary
> investigation with type='text/css' suggests that Firefox and Opera implement
> the spec'd behaviour of offering user choice when the alternate="yes"
> pseudo-attribute is present, but Chrome and IE do not (at least, I haven't
> found a place where they make the offer, if there is one).

Ah, I found it for IE -- at least IE9 -- I had failed to get the menu bar up, but once I did, the necessary controls are there under View > Style.
Comment 7 Julian Reschke 2011-11-23 10:34:55 UTC
<http://greenbytes.de/tech/tc/httplink/> has a few test cases relevant to referencing the style sheet using the HTTP Link header fields (as opposed to the stylesheet PI); some of them should be relevant as well, such as support for the correct internet media types, and exposing the stylesheet title through the CSS object model.
Comment 8 Ian 'Hixie' Hickson 2012-05-03 16:52:05 UTC
To resolve this we need a lot more tests, e.g. testing whether the handling of this PI is blocking (by putting a <script> element in the source and having an XSL sheet where the server blocks so it takes a few seconds to download), testing what happens when the XML file or the XSL file (or both) are malformed, testing what happens with various MIME types for the XSL file, testing all the various attributes (e.g. are alternative style sheets honoured? What happens with multiple XSL links?), testing what happens when using <link> elements rather than XML PIs, etc.
Comment 9 Henri Sivonen 2012-05-14 08:32:20 UTC
(In reply to comment #8)
> To resolve this we need a lot more tests, e.g. testing whether the handling of
> this PI is blocking (by putting a <script> element in the source and having an
> XSL sheet where the server blocks so it takes a few seconds to download),

FWIW, Firefox's behavior in this scenario is considered a bug.
Comment 10 contributor 2012-07-18 07:27:12 UTC
This bug was cloned to create bug 17976 as part of operation convergence.
Comment 11 Robin Berjon 2012-09-06 09:26:09 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:


   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Rationale:

Hi Henry,

this would indeed be worth defining, especially since there is a lot of variation in some of the possible cases. That being said, the amount of research required to properly specify it does not fit into this release's timeline. We'll be looking at this for .next.

Thanks!
Comment 12 Henry S. Thompson 2012-09-06 09:35:58 UTC
I'm taken completely aback by this decision.  All shipping browsers already implement this!  Surely it's appropriate to document the mainstream behaviour, as illustrated by the test cases I supplied nearly a year ago.
Comment 13 Robin Berjon 2012-09-06 09:43:01 UTC
(In reply to comment #12)
> I'm taken completely aback by this decision.  All shipping browsers already
> implement this!  Surely it's appropriate to document the mainstream behaviour,
> as illustrated by the test cases I supplied nearly a year ago.

Yes it is appropriate — no one said otherwise! RESOLVED LATER means we'll resolve it later, not never. It may even be soon; it just won't be in this release is all I'm saying.
Comment 14 Henry S. Thompson 2012-09-06 10:21:54 UTC
Sorry, what does "this release" mean, if not HTML 5?  The idea that HTML5 should not include support for a core behaviour of XML on the web, which has been supported by all shipping browsers for many years, seems bonkers.  I'm speaking for myself, but I expect the XML Core WG will shortly say exactly the same thing, officially and strenuously.
Comment 15 Simon Pieters 2012-09-06 12:46:43 UTC
Why is this considered to be in scope for the HTML spec at all? Shouldn't the XSLT spec define XSLT processing?
Comment 16 Julian Reschke 2012-09-06 12:54:09 UTC
It's not part of an HTML spec, but it *is* part of a *browser* spec, and this is what the HTML spec is actually.

The XSLT spec defines the transformation, the stylesheet PI spec defines the format of the PI. Optimally, the browser spec doesn't need to do much more than referencing the PI spec.
Comment 17 Robin Berjon 2012-09-06 13:55:46 UTC
(In reply to comment #14)
> Sorry, what does "this release" mean, if not HTML 5?  The idea that HTML5
> should not include support for a core behaviour of XML on the web, which has
> been supported by all shipping browsers for many years, seems bonkers.  I'm
> speaking for myself, but I expect the XML Core WG will shortly say exactly the
> same thing, officially and strenuously.

It means 5.0 — after that there's 5.1. We're pursing an aggressive timeline to get 5.0 out and there simply is no way that I can see of the work required here to fit into that frame.

We're going to be developing the current version and the next version in parallel, and HTML.next is not expected to come 15 years later but rather in relatively quick succession, with incremental changes being folded in as they are ready.

So the idea is not that we're excluding this but rather that we're not solving it this month. I can only hope that the XML WG will understand that as consensus creeps in this petty pace from day to day we can't address all problems at once, and do have to prioritise so that we release something before our brief candles are out.
Comment 18 Henry S. Thompson 2012-09-06 14:26:00 UTC
My worry is that if HTML5 goes to CR without support for xml+xml-stylesheet[XSLT], browser vendors/suppliers may _remove_ XSLT from their browsers, and then we'll never get it back.

I'm also perplexed by the assertion that there's a lot of editorial work involved here:  the work for xml-stylesheet[CSS] will surely be done -- adding basic support for an additional stylesheet language isn't a big deal.  Both I (above) and Julian have provided test materials.
Comment 19 Simon Pieters 2012-09-06 14:57:45 UTC
(In reply to comment #18)
> My worry is that if HTML5 goes to CR without support for
> xml+xml-stylesheet[XSLT], browser vendors/suppliers may _remove_ XSLT from
> their browsers, and then we'll never get it back.

No need to worry about that, browsers won't remove anything just because it's not in the HTML5 CR.

> I'm also perplexed by the assertion that there's a lot of editorial work
> involved here:  the work for xml-stylesheet[CSS] will surely be done -- 

This is already specified in http://dev.w3.org/csswg/cssom/#requirements-on-user-agents-implementing-the-xml-stylesheet-processing-instruction
Comment 20 Edward O'Connor 2012-09-06 15:35:38 UTC
Instead of resolving as later, shouldn't this be reassigned to the HTML.next component?
Comment 21 Jirka Kosek 2012-09-06 15:42:21 UTC
(In reply to comment #17)
> It means 5.0 — after that there's 5.1. We're pursing an aggressive timeline to
> get 5.0 out and there simply is no way that I can see of the work required here
> to fit into that frame.

Would providing complete text of needed editoral changes in a form of Git pull request change this?

Jirka
Comment 22 Henry S. Thompson 2012-09-06 16:19:15 UTC
In agreeing to accept https://www.w3.org/Bugs/Public/show_bug.cgi?id=15180 (XML _without_ xml-stylesheet), you say

  "Rationale: It's already implemented, might as well be described correctly."

That's precisely the case here as well!  And the necessary scaffolding is already in place. . .
Comment 23 Robin Berjon 2012-09-07 08:01:57 UTC
(In reply to comment #18)
> My worry is that if HTML5 goes to CR without support for
> xml+xml-stylesheet[XSLT], browser vendors/suppliers may _remove_ XSLT from
> their browsers, and then we'll never get it back.

I wouldn't worry about that — either there's content relying on that and it won't get removed, or there isn't content relying on XSLT anywhere on the big wide Web and what's in the spec won't change that. So that should definitely not be a concern.

> I'm also perplexed by the assertion that there's a lot of editorial work
> involved here:  the work for xml-stylesheet[CSS] will surely be done -- adding
> basic support for an additional stylesheet language isn't a big deal.  Both I
> (above) and Julian have provided test materials.

Well if it's not much work, rest assured that we accept patches :) Can you answer all the questions in comment #8 and those that stem from there?

(In reply to comment #22)
>  "Rationale: It's already implemented, might as well be described correctly."
> 
> That's precisely the case here as well!  And the necessary scaffolding is
> already in place. . .

You'll note that the other bug which you're quoting was reopened (with good reason).
Comment 24 Robin Berjon 2012-09-07 08:03:45 UTC
(In reply to comment #20)
> Instead of resolving as later, shouldn't this be reassigned to the HTML.next
> component?

My understanding was that it was exactly the same thing — but I've just arrived so I could be wrong :)
Comment 25 Robin Berjon 2012-09-07 08:07:39 UTC
(In reply to comment #21)
> (In reply to comment #17)
> > It means 5.0 — after that there's 5.1. We're pursing an aggressive timeline to
> > get 5.0 out and there simply is no way that I can see of the work required here
> > to fit into that frame.
> 
> Would providing complete text of needed editoral changes in a form of Git pull
> request change this?

It always helps, but it would need to be reviewed and given the time constraints might still only be accepted in v.next. While we'd be grateful, I would be sorry if you were to put a lot of work into this and it got deferred anyway.
Comment 26 Robin Berjon 2012-09-10 10:51:33 UTC
Now using the HTML.next component instead of RESOLVED LATER. Purely administrative change, sorry for the noise.
Comment 27 A Goldberg 2012-09-13 10:36:29 UTC
As I have said before, I need Gillian Gordon Crozier removed as adim. Also,  a compleat separation from her work group.  In my opinion, she should be subject to a general investigation

Andrew H Goldberg
Comment 28 Norman Walsh 2012-10-11 15:44:25 UTC
The XML Core Working Group objects to the decision to mark discussion of the XML stylesheet PI with type='text/xsl' as either "RESOLVED LATER" or "HTML.next".

The stylesheet PI is widely supported and has been in use for a long time. It is an important part of the browser API. Some test cases[1] for the XML stylesheet PI with type='text/xsl' have been attached to the bug report[2].

In a sampling of the University of Amsterdam XML Web Collection, around 10% of the documents[3] have an XML stylesheet PI with type='text/xsl'.

The XML Core WG remains concerned that the absence of a mention of support for the XML stylesheet PI with type='text/xsl' would serve to discourage users from taking advantage of the existing functionality and might set implementers on a path towards deprecating the feature.

The XML Core WG feels strongly that some mention of support for the XML stylesheet PI with type='text/xsl' or type='application/xslt+xml' needs to be included in the initial HTML5 Recommendation.

[1] http://www.w3.org/XML/2011/11/ssTests/
[2] https://www.w3.org/Bugs/Public/attachment.cgi?id=1046
[3] http://lists.w3.org/Archives/Public/public-xml-core-wg/2012Sep/0041.html
Comment 29 Robin Berjon 2012-10-11 16:11:21 UTC
(In reply to comment #28)
> The stylesheet PI is widely supported and has been in use for a long time.
> It is an important part of the browser API. Some test cases[1] for the XML
> stylesheet PI with type='text/xsl' have been attached to the bug report[2].
> (...) 
> The XML Core WG feels strongly that some mention of support for the XML
> stylesheet PI with type='text/xsl' or type='application/xslt+xml' needs to
> be included in the initial HTML5 Recommendation.

Norm,

no one is contesting that there are people using xml-stylesheet with XSLT or that it is important to users who rely on it. The heart of the matter is that it is simply not feasible to define how it works at the requisite level of concision within the very small time frame we have before entering CR. We are fixing bugs, not taking new features.

Please note that as soon as 5.0 hits CR, we will be issuing a FPWD or 5.1 — I must therefore emphasise that it is not as if all specification work was about to stop until 2015.

I would be happy to work with the XML Core WG to properly specify this feature as part of 5.1.

In the meantime, you seem to indicate that you might be satisfied with "some mention of support". Can you clarify what that would involve? Do you have some suggested text? Would a non-normative paragraph work for you?

If not then I'm afraid that the next step will have to be escalation.
Comment 30 Sam Ruby 2012-10-11 16:16:51 UTC
(In reply to comment #29)
> 
> The heart of the matter is
> that it is simply not feasible to define how it works at the requisite level
> of concision within the very small time frame we have before entering CR.

Norm: feel free to prove Robin wrong by making a concrete proposal.  :-)

I'll also note that it is possible for this to be documented in a separate spec.  See Plan 2014:

http://dev.w3.org/html5/decision-policy/html5-2014-plan.html

And in particular:

http://dev.w3.org/html5/decision-policy/html5-2014-plan.html#extension-specs
http://dev.w3.org/html5/decision-policy/decision-policy-v3.html#cr-integration
Comment 31 Ian 'Hixie' Hickson 2012-10-11 16:29:36 UTC
Henry, Norm: I'm happy to write the text that should go in the spec (and am indeed planning to do so — bug 17976 isn't closed), but what I need before that can happen is the tests described in comment 8. Without those tests, I have no way to know what to spec. I don't have the necessary knowledge to write the tests. Once I've written the text, it's easy for Robin and co to take my text and put it in the W3C version, in case that's what you care about (as opposed to just the WHATWG version). Telling us to do work for you without being willing to at least contribute tests isn't going to work since you care about this more than we do.
Comment 32 Henry S. Thompson 2012-10-11 22:07:25 UTC
(In reply to comment #31)
> Henry, Norm: I'm happy to write the text that should go in the spec (and am
> indeed planning to do so — bug 17976 isn't closed)

Great, thanks

> but what I need before that can happen is the tests described in comment 8.

It's not laziness or disinclination that has lead to the lack of reply to comment 8, but rather confusion.  Quoting from comment 8:

> testing what happens when the XML file or the XSL file (or both)
> are malformed

I can easily transform any or all of the tests already attached here to be ill-formed in those ways, but I have no idea what kind of result report you would need

> testing what happens with various MIME types for the XSL file

Can you point me to a parallel set of tests for xml-stylesheet type='text/css' so I can see how you expect this to be done?

> testing whether the handling of this PI is blocking (by putting a
> <script> element in the source and having an XSL sheet where the
> server blocks so it takes a few seconds to download),

Not sure I have the necessary expertise to do this -- maybe Norm Walsh can help here?  I recall recently running across a bunch of xsl-stylesheet tests you had written, can't remember where, which might have begun to cover this???

> testing all the various attributes (e.g. are alternative style sheets
> honoured? What happens with multiple XSL links?), testing what happens
> when using <link> elements rather than XML PIs, etc.

Not sure this gives you enough to work with, but I've attached a further set of tests in this space.  Note also Julian Reshke's offer at comment 7.
Comment 33 Henry S. Thompson 2012-10-11 22:24:58 UTC
Created attachment 1225 [details]
multiple stylesheet PI tests

All the tests in this and the earlier attachment are visible on the web at http://www.w3.org/XML/2011/11/ssTests/
Comment 34 Ian 'Hixie' Hickson 2012-10-31 22:42:50 UTC
Please see my comments in bug 17976.
Comment 35 Norman Walsh 2012-11-01 09:06:49 UTC
The XML Core WG considered this issue again at our face-to-face[1]. We recognize that it's too late to attempt to get normative changes into this version of the spec. We're still committed to helping move something forward normatively in this or another spec in the future.

In the meantime, we suggest a note along the following lines (editor, salt to taste) in section 5.6.3:

  Note: Many existing user agents support the 'text/xsl' (or
  'application/xslt+xml') style sheet type, with XSLT [ref] as the
  relevant supported styling language. When the browsing context has a
  StyleSheet of that style sheet type, such agents transform the
  current XML document using the XSLT stylesheet retrieved from the
  style sheet location (typically supplied via an xml-stylesheet
  processing instruction) and rendering (or otherwise processing) the
  document that results from that transformation. The precise details
  of this process will be defined in a future specification.

[1] http://lists.w3.org/Archives/Public/public-xml-core-wg/2012Oct/0059.html
Comment 36 Julian Reschke 2012-11-01 10:01:33 UTC
+1, but:

(In reply to comment #35)
> The XML Core WG considered this issue again at our face-to-face[1]. We
> recognize that it's too late to attempt to get normative changes into this
> version of the spec. We're still committed to helping move something forward
> normatively in this or another spec in the future.
> 
> In the meantime, we suggest a note along the following lines (editor, salt
> to taste) in section 5.6.3:
> 
>   Note: Many existing user agents support the 'text/xsl' (or
>   'application/xslt+xml') style sheet type, with XSLT [ref] as the

IE and Firefox support application/xslt+xml. Change requests to Apple, Chrome, and Opera have been ignored so far. See http://greenbytes.de/tech/tc/xslt/#pi-ax-ax

>   relevant supported styling language. When the browsing context has a
>   StyleSheet of that style sheet type, such agents transform the
>   current XML document using the XSLT stylesheet retrieved from the
>   style sheet location (typically supplied via an xml-stylesheet
>   processing instruction) and rendering (or otherwise processing) the
>   document that results from that transformation. The precise details
>   of this process will be defined in a future specification.
> 
> [1] http://lists.w3.org/Archives/Public/public-xml-core-wg/2012Oct/0059.html
Comment 37 Robin Berjon 2012-12-06 11:40:52 UTC
(In reply to comment #35)
> In the meantime, we suggest a note along the following lines (editor, salt
> to taste) in section 5.6.3:

This has been committed:

https://github.com/w3c/html/commit/dab090a81e0269b1ad63922ebb5f897ade3488e0

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:

   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Partially Accepted
Change Description: Added a note explaining that XSLT processing is possible, though not defined.
Rationale: Clarifies real-world situation; a proper in-depth definition of the actual processing is nevertheless still required.
Comment 38 Henry S. Thompson 2012-12-06 11:54:16 UTC
Thanks -- Marked this as LATER to remind us that it needs more work in a subsequent edition/version