[webkit-dev] XPath Issues?

[Frans Englich]

On Nov 10, 2010, at 11:29 , Maciej Stachowiak wrote:

> 
> The first thing we should figure out is whether XSLT 2.0 is something we even want to implement. If it's not backwards compatible with XSLT 1.0 and other browsers are not planning on implementing it, then it's a significant risk to move to XSLT 2.0. We'd likely break backwards compatibility with Web content, and end up long-term incompatible with other browsers. That's not very well aligned with the goals of the project. Breaking backwards compatibility is generally considered unacceptable, unless we can convincingly show it won't affect real-world content.
> 
> If, in addition, XSLT 2.0 requires a major engineering effort and/or a large external dependency, then this would not be a cheap experiment. Now, we could add it under a new API, but then we'd be stuck carrying around two versions of XSLT forever, and Web content might not be able to reliably use the new version in any case.
> 
> What we'd normally do in a situation like this is check with other implementors whether they are prepared to implement the new technology. I would recommend starting there, before we talk implementation strategy.

It could be that everyone is sitting on the fence waiting for someone to take initiative(who brings technology forward?). In that case it could be good to look one step further back and see if there's user interest in the technology, as opposed to if any implementor has decided to please that demand, which needs to be followed.

One could look at if significant things could be achieved with the technology, and then potentially Webkit could take the lead in this area.

Although the technology is huge, it's good to know that it's stable(it's no html situation), the specifications are clean, and the backward/forward compatibility modes function well.


-- 
Frans Englich