RE: xml-stylesheet issues--suggested resolutions

Having reviewed what Arbortext does [1] and (thanks to Henry)
what Saxon does [2], embedded herein are my suggestions for 
clarifications to the Associating Stylesheets Rec [3].

In general, we will need to decide if the various error
cases are "it is an error (the xml-stylesheet processor 
may ignore the whole thing, may ignore what it doesn't
understand and try to process the rest, etc.)" or "fatal
xml-stylesheet error (a compliant xml-stylesheet processor
must ignore the entire PI)" or "it is an error; the 
xml-stylesheet processor must recover by XXXX".

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?

[1] http://lists.w3.org/Archives/Public/public-xml-core-wg/2009Feb/0022
[2] http://lists.w3.org/Archives/Public/public-xml-core-wg/2009Apr/0025
[3] http://www.w3.org/1999/06/REC-xml-stylesheet-19990629/

> -----Original Message-----
> From: public-xml-core-wg-request@w3.org 
> [mailto:public-xml-core-wg-request@w3.org] On Behalf Of Simon Pieters
> Sent: Tuesday, 2009 February 17 10:38
> To: public-xml-core-wg@w3.org
> Subject: xml-stylesheet issues
> 
> As promised here are some issues with the existing 
> xml-stylesheet spec (probably not exhaustive):
> 
> 
> * What happens when the PI is XML 1.0-well-formed but doesn't 
> follow the xml-stylesheet syntax?

The entire PI should be ignored by the xml-stylesheet processor.
(That is, it is effectively not considered an xml-stylesheet PI.)
This includes the case where either of the two required
pseudo-attributes--href and type--are omitted (or ignored
due to unacceptable values).

As an aside, I'm not sure why the spec required the type
pseudo-attribute.  It doesn't seem to be required by the
HTML spec, and Arbortext doesn't make use of it.  Perhaps
we should not require it--or at least, not require that
a processor ignore the whole PI if it is missing.  After
all, the processor can use the href value to find the
resource whose type might be obvious by inspection. 
Thoughts?

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

The unknown pseudo-attributes should be ignored.  The rest of 
the PI should be processed by the xml-stylesheet processor.

> 
> * What happens when there are unknown values?

If a known pseudo-attribute has an unknown, unrecognized, or
invalid value, the xml-stylesheet processor should act as though
that pseudo-attribute assignment was not there.  Since href
and type are required, if either of them are ignored (due
to an unacceptable value), the PI should be ignored by the
xml-stylesheet processor.

Specifically, the recognized pseudo-attributes are:
* href -- required
* type -- required (though I'm not sure why)
* title -- can't see how this could be invalid
* media -- not sure how this could be invalid, but if so, ignore
* charset -- if the value isn't a valid charset, ignore
* alternate -- if not yes or no, defaults to no

> 
> * What happens when there are duplicate pseudo-attributes? 
> (This seems to actually be allowed in the syntax.)

The xml-stylesheet processor should use the last one (parsing 
the PI left to right) specified.

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

As far as I can tell, the XML Rec says:

[16] PI ::= '<?' PITarget (S (Char* - (Char* '?>' Char*)))? '?>'

and Char is "any unicode character..." so I don't see how there
could be a CharRef in a 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?

This is outside the scope of the associating stylesheet Rec.
Talk to the XML Processing Model WG.

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

The Assoc SS spec says:

 The xml-stylesheet processing instruction is allowed only in
 the prolog of an XML document. 

So an xml-stylesheet processor should ignore any PI not in the prolog.

I would add that an xml-stylesheet processor should ignore any PI
that is not physically in the document entity.

I would also add that, in the case of multiple xml-stylesheet PIs 
for the same media, the xml-stylesheet processor should ignore all
but the last in document order.

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

I don't think this is an issue for the xml-stylesheet PI spec.
Besides, type="text/xsl" has been in use for so long that the
XSL WG should make it official, but that's not our call.

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

Used for what?  For reading the XSLT resource, yes.  For 
what the XSLT transformation generates, no.  But I'm not
sure the Assoc SS spec needs to say anything here.

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

I'm not sure we have to do anything here.

We could update some references, but this just starts us down
the road of how to reference one spec from another in a changing
world.  I mostly want the Assoc SS spec to say how one gets values
for various things (like media) and let another spec say how to
interpret those values.

Right now the Assoc SS spec says:

 The semantics of the pseudo-attributes are exactly as with
 <LINK REL="stylesheet"> in HTML 4.0.

So where does the Media Queries spec fit in?  Does it modify
what HTML4 says, or are browsers that use the Media Queries
spec not compliant with HTML4?  

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

I don't quite understand this, but I'm pretty sure this is
outside the scope of the xml-stylesheet PI spec.  

I do not feel the Assoc SS spec should define a DOM interface
to the xml-stylesheet PI any more than the XML spec defines
a DOM interface to anything.

> 
> * 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 later gave the following example:

 Consider

   <?xml-stylesheet type='text/css' href='#foo'?>
   <test xml:id='foo'> test { background:lime } </test>

 Should the background be lime, assuming the UA supports 
 xml-stylesheet, xml:id and CSS? 

I don't think the Assoc SS spec needs to say anything here.
What the PI says is that the associated stylesheet--which
it says is of type='text/css'--is:

  <test xml:id='foo'> test { background:lime } </test>

Now, it's up to the CSS processor to see if it can handle this.

I'm guessing most can't, but that's not an Assoc SS issue.

Consider instead:

   <?xml-stylesheet type='text/css' href='#xpath1(id(foo)/text())'?>
   <test xml:id='foo'> test { background:lime } </test>

If the UA supported xml-stylesheet, xml:id, and the xpath1 xpointer 
scheme, then this would be saying that the associated stylesheet--which
it says is of type='text/css'--is:

  test { background:lime }

Assuming the UA also supported CSS, I would expect the background
for the test element to be lime.

But the Assoc SS spec doesn't need to say anything different from 
what it says now for this to be the case.

paul

Received on Friday, 17 April 2009 21:45:27 UTC