[webkit-dev] XPath Issues?

[Alex Milowski]

On Wed, Nov 10, 2010 at 11:25 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>
>
> Do most existing XSLT 1.0 stylesheets have an explicit 1.0 label? Does XSLT require this? How would unlabeled stylesheets be processed?

You are required to have a version attribute and it is a static error
if it does not.  As a result, most web-oriented stylesheets will have
"1.0" for this attribute.  If the version is, say, 2.0, a 1.0
processor must process the transformation in forwards compatible mode
(without an error).  Obviously, the result won't necessarily be the
same and certain expressions may cause errors (e.g. an unguarded XPath
2.0 only expression).

This allows someone to write a single transform that uses an
xsl:choose and do different things depending on the version available.
 For example:

<xsl:choose>
      <xsl:when test="system-property('xsl:version') = 2.0">
        <div>Wahooo!</div>
      </xsl:when>
      <xsl:otherwise>
        <div>Booo!</div>
      </xsl:otherwise>
</xsl:choose>

>> I need to look/ask around and see if I can quantify the scope of these
>> incompatibilities in live stylesheets used on the web to help answer
>> this question.
>
> Yeah, I am more interested in how much content would be affected, than whether it is poorly written.
>

That is the question.  Define "content".  We're not guarantee the
output is the same but I really wonder about the actual subset of XSLT
1.0 in use due to incompatibilities that exist (or have existed)
between browsers.

Looking at [1], Mozilla does not have full support for these XSLT 1.0 elements:

xsl:fallback (not supported)
xsl:import (mostly supported)
xsl:namespace-alias (not supported)
xsl:number (partially supported)
xsl:output (partially supported)
xsl:stylesheet (partially supported)
xsl:text (partially supported)
xsl:value-of (partially supported)

I personally have had major issues with xsl:import.

>>
>> I'd be curious about that too.  For those that use XSLT in the
>> browser, "better" (e.g. more reliable, consistent, and "modern")
>> support for XSLT would be very, very welcome.
>>
>> It is a long road to getting XSLT and XPath 2.0 support into *all* the
>> major browsers.  It has to start somewhere and a standoff of browser
>> vendors, each looking at each other, waiting for each other to say
>> "yes" first is where I believe we are right now.  Possibly some are
>> hoping that no one will say "yes" and the status quo will reign.
>
> The informal information I have so far is that none of them want to say "yes" and hope no one else does, because they don't like the complexity or featureset.

In this case, "they" is some subset of developers and not "they" as in
users of XSLT on the web.  XSLT 2.0 is just better than XSLT 1.0 in
many ways and vastly improves on the interoperability of
implementations.

Interesting, Mozilla does have a page for XSLT 2.0 [2] and they point
to an extension that provides XSLT 2.0 support via an extension [3].

I still am interested in what criteria would be used to judge a set of
patches to support XSLT 2.0 or XPath 2.0:

* Must it be "home grown"?

* If it is an external library, like XSLT 1.0 support is today, what
are the integration criteria (e.g. platform library vs. statically
linked, etc.)?

* As a library, what licenses are allowed (e.g. some of these
implementations are under the Apache license v2)?

[1] https://developer.mozilla.org/en/XSLT/Elements
[2] https://developer.mozilla.org/en/XSLT_2.0
[3] https://addons.mozilla.org/en-US/firefox/addon/5023/

-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics