Re: xml-stylesheet issues--suggested resolutions

On Sat, 18 Apr 2009 12:48:35 +0200, Simon Pieters <simonp@opera.com> wrote:

>> In most cases, I'm tempted to say "is an error; the
>> xml-stylesheet processor MAY ignore the entire PI; if
>> it tries to recover, it SHOULD xxxx."  Thoughts?
>
> I would prefer if for different errors it was either "is an error: MUST  
> ignore the entire PI" or "is an error: MUST recover as follows: xxxx".

My preference for which of those to follow for different errors are as  
follows:


On Tue, 17 Feb 2009 17:38:22 +0100, Simon Pieters <simonp@opera.com> wrote:

> * What happens when the PI is XML 1.0-well-formed but doesn't follow the  
> xml-stylesheet syntax?

> * What happens when there are duplicate pseudo-attributes? (This seems  
> to actually be allowed in the syntax.)
>
> * What happens when a CharRef hits the [WFC: Legal Character] constraint  
> in XML 1.0? (Unclear to me whether this is allowed in the syntax.)

Syntax error: must ignore the entire PI. We should tighten up the syntax  
so that duplicate pseudo-attributes and NCRs that are syntax errors in XML  
1.0 are also syntax errors in xml-stylesheet.


> * What happens when there are unknown pseudo-attributes?

Must recover by ignoring unknown pseudo-attributes.


> * What happens when there are unknown values?

> * Browsers support type="text/xsl" but text/xsl is not a registered  
> media type and is not an XML media type per RFC 3023.

> * media='' references HTML4 which is outdated; browsers use the Media  
> Queries spec here.

Invalid value for 'alternate': must recover by acting as if the value was  
'no'.

Unexpected value for 'type': must either abort processing the PI or  
continue as if type was absent. We should probably say that 'text/xsl' is  
to be treated the same as 'text/xml' for the purposes of 'type' (for  
compat with existing content).

Invalid IRI in 'href': interpret the value using the rules in "Web  
Addresses" (currently called "URLs" and specified here:  
http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#parsing-urls  
). If that returns an error: must ignore the entire PI.

'media': refer to the Media Queries spec. If it's an invalid media query,  
must ignore the entire PI.


> * When is the processing of the PI invoked?
>   - What happens if you change the PI's 'data'?
>   - What happens if you change the PI's 'target'?
>   - What happens if you remove the PI from the DOM?
>   - What happens if you add the PI to the DOM (with scripting)?
>   - What happens if you insert the PI somewhere other than in the  
> prologue?
>   - What happens if the PI is a child of Document but after the root  
> element and you then move the root element so that the PI becomes part  
> of the prologue?

In browsers, for CSS things are updated on the fly, but for XSLT changes  
are ignored. We could leave this up to the CSS and XSLT (and other) specs.


>  * Is it conforming for a document to have an xml-stylesheet PI anywhere  
> other than in the prologue? Is it used or ignored?

Misplaced xml-stylesheet PI: must ignore the entire PI. Documents must not  
use misplaced xml-stylesheet PIs.


> * If charset is specified and the PI points to an XSLT transformation,  
> should the charset='' information be used?

No, RFC 3023 and XML 1.0 say which encoding to use.


> * CSSOM integration:  
> http://dev.w3.org/cvsweb/~checkout~/csswg/cssom/Overview.html?content-type=text/html;%20charset=utf-8#the-linkstyle  
> defines the LinkStyle interface that HTML <link> and <?xml-stylesheet?>  
> implement -- we should coordinate with Anne here.
>
> * CSS issues: it's unclear whether referencing an element should work if  
> type="text/css" -- the type of the document would be an XML type which  
> is not a CSS type, and browsers largely don't support this anyway.

-- 
Simon Pieters
Opera Software

Received on Wednesday, 10 June 2009 12:00:28 UTC