RE: xml-stylesheet issues--suggested resolutions

Assuming we have the necessary participants on the telcon
this week, I plan to go through these suggested clarifications.

Simon has suggested more SHOULDs should be MUSTs.  Other than
that, I have seen no comments.

Please be prepared to discuss on the telcon.

paul

> -----Original Message-----
> From: public-xml-core-wg-request@w3.org 
> [mailto:public-xml-core-wg-request@w3.org] On Behalf Of Grosso, Paul
> Sent: Friday, 2009 April 17 16:42
> To: public-xml-core-wg@w3.org
> Subject: 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 Monday, 4 May 2009 15:09:34 UTC