xml-stylesheet in internal subset

On Wed, 07 Oct 2009 18:39:37 +0200, Grosso, Paul <pgrosso@ptc.com> wrote:

> We discussed several issues.
>
> The first edition of the spec allowed the xml-stylesheet PI anywhere
> in the prolog including the internal subset and even including
> the external subset or other external parameter entity (though
> it said such a PI in an external entity might get ignored).
>
> We tentatively decided for this 2nd Edition to disallow the
> xml-stylesheet PI in the doctypedecl, meaning that such a PI
> would not be an xml-stylesheet PI if it occurred in the
> internal subset (or any external entity).
>
> ACTION to Henry:  Check some browsers for what they do with
> an xml-stylesheet PI in the internal subset.
>
> ACTION to Paul:  Check what Arbortext does with an xml-stylesheet
> PI in the internal subset.


On Wed, 07 Oct 2009 18:31:46 +0200, Simon Pieters <simonp@opera.com> wrote:

> On Wed, 07 Oct 2009 18:14:22 +0200, Henry S. Thompson <ht@inf.ed.ac.uk>  
> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> The following displays
>>
>>   nothing to see here, move along
>>
>> in all of Firefox 3.0.14, IE 8 and Opera 10.0
>>
>> foo2.xml:
>> <?xml-stylesheet href="foo.xsl" type="text/xsl"?>
>> <!DOCTYPE foo [
>> ]>
>> <foo/>
>>
>> foo.xsl:
>> <?xml version="1.0" encoding="utf-8"?>
>> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>>                 version="1.0">
>>
>>   <xsl:output method="html"/>
>>
>>   <xsl:template match="/">
>>     <html>
>>       <body bgcolor="#FFFFFF">
>>         <div>nothing to see here, move along</div>
>>       </body>
>>     </html>
>>   </xsl:template>
>>
>> </xsl:stylesheet>
>
> That's good.
>
>
>> And the following displays
>>
>>  <foo/>
>>
>> in both Firefox 3.0.14 and Opera 10.0
>>
>> foo.xml:
>> <!DOCTYPE foo [
>> <?xml-stylesheet href="foo.xsl" type="text/xsl"?>
>> ]>
>> <foo/>
>>
>> Unfortunately, in IE8, regardless of compatibility mode setting,
>> foo.xml displays
>>
>>   nothing to see here, move along
>
> WebKit agrees with IE8.
>
> This is a case I hadn't really considered. I would assume that there are  
> zero or close to zero pages depending on one or the other behavior  
> (since browsers disagree), so we're probably free to define whatever  
> makes most sense.
>
>
>> So if we make the change we were discussing just now on the call, we
>> will render IE non-conforming.
>
> Whichever of the two options we choose, we render two out of four major  
> browser rendering engines non-conforming.
>
> Personally, I tend to prefer to say that PIs in the internal subset are  
> not to be interpreted as xml-stylesheet PIs (i.e. what the current draft  
> says), but I don't feel strongly about it.



On Wed, 07 Oct 2009 18:56:38 +0200, Simon Pieters <simonp@opera.com> wrote:

> On Wed, 07 Oct 2009 18:39:32 +0200, Grosso, Paul <pgrosso@ptc.com> wrote:
>
>>> This is a case I hadn't really considered. I would assume that there
>>> are
>>> zero or close to zero pages depending on one or the other behavior
>>> (since
>>> browsers disagree), so we're probably free to define whatever makes
>>> most sense.
>>
>> I disagree.  Process-wise, I do not believe we can render existing
>> implementations non-compliant in a change from a 1st Ed to a 2nd Ed.
>>
>> Also, your talk of browser pages is wrong for two reasons:
>>
>> 1.  there are lots of pages out there that work with one browser
>>     but not another, so your conclusion that there can't be many
>>     pages out there like this because they wouldn't work in all
>>     browsers does not follow.
>
> Usually, when browsers 2 out of the top 4 browser engines do one thing,  
> and the other two do another, it is an indicator that content doesn't  
> rely on one or the other behavior. If content did rely on it, the  
> browser vendors would have gotten bug reports about sites not working.
>
>
>> 2.  you're talking about web pages an browsers, but you're
>>     forgetting that the whole world is greater than web pages
>>     and browsers--there are editors and other things that may
>>     process stylesheet PIs.
>
> Yeah. Does non-Web content use xml-stylesheet PIs in the internal subset  
> and expect them to work? I realize that it might be hard or impossible  
> to research this, so it might be safer to err on the side of keeping the  
> first edition behavior.
>
>
>>> > So if we make the change we were discussing just now on the call, we
>>> > will render IE non-conforming.
>>>
>>> Whichever of the two options we choose, we render two out of four major
>>> browser rendering engines non-conforming.
>>>
>>> Personally, I tend to prefer to say that PIs in the internal subset are
>>> not to be interpreted as xml-stylesheet PIs (i.e. what the current
>>> draft says), but I don't feel strongly about it.
>>
>> Personally, if we were writing the first edition, I'd agree,
>> but at this time, I feel strongly that we cannot disallow
>> them within the internal subset.
>
> Ok.
>
>
> On Wed, 07 Oct 2009 18:39:37 +0200, Grosso, Paul <pgrosso@ptc.com> wrote:
>
>> And Arbortext also processes xml-stylesheet PIs within
>> the internal subset.
>
> Ok, that's good to know.
>
> Do we know about what other implementations do?
>
>
>> And because the First Edition allowed this behavior, I don't
>> believe we can make such a change in a 2nd Edition.
>>
>> I think we have to allow the PI in the internal subset.
>> We can still have a "might ignore if in internal subset"
>> sentence if we want.
>
> The first edition says "might ignore if in external subset or parameter  
> entity", which follows from non-validating XML processors that opt to  
> not process the external subset. I don't think we should allow it to be  
> ignored in the internal subset if we want it to be processed.


On Wed, 07 Oct 2009 20:10:37 +0200, Simon Pieters <simonp@opera.com> wrote:

> I just found out that DOM Core does not represent PIs in the internal  
> subset at all, other than in the internalSubset attribute which just  
> returns a DOMString. PIs in the external subset are not represented at  
> all in the DOM, even if the XML processor opted to process the external  
> subset.
>
> This poses a problem for implementations that implement xml-stylesheet  
> on top of the DOM; they would have to make changes to the underlying API  
> in order to be able to process PIs in the internal and external subset.
>
> I think it should be possible to implement xml-stylesheet on top of an  
> off-the-shelf DOM Core implementation.


I have not changed the spec wrt xml-stylesheet in the internal subset,  
except that they are now explicitly not allowed.

We cannot require that UAs process PIs in the internal subset, because  
some XML APIs don't represent them (e.g. the DOM). If we allow them to be  
processed, then PIs in the external subset would be processed when using  
an XML processor that processes the external subset but would not when  
using an XML processor that doesn't, which results in inconsistent  
behavior.

I know this is a change from the first edition, but there are other things  
we have changed as well, such as disallowing duplicate pseudo-attributes.  
Personally I didn't even know that PIs (let alone xml-stylesheet PIs) in  
the internal subset were allowed in XML at all until it came up in this  
discussion. I think there's very little risk of content breaking because  
of this change, but it is something we can revisit if implementation  
experience shows otherwise.

-- 
Simon Pieters
Opera Software

Received on Monday, 9 November 2009 09:33:12 UTC