Re: [webkit-dev] XPath Issues?
On Nov 3, 2010, at 17:38 , Alex Milowski wrote: > As far as I can tell, these are the only filed issues with XPath > implementation within WebKit: > > https://bugs.webkit.org/show_bug.cgi?id=26157 > https://bugs.webkit.org/show_bug.cgi?id=12504 > https://bugs.webkit.org/show_bug.cgi?id=13233 > https://bugs.webkit.org/show_bug.cgi?id=12632 > https://bugs.webkit.org/show_bug.cgi?id=12496 > https://bugs.webkit.org/show_bug.cgi?id=36427 > > Anything else out there? Is it complete? I'm curious about how > robust this implementation is and what enhancements have been filed > for it. > > I'm also looking at what it would take to enhance this implementation > to support XPath 2.0 ... Qt has complete XPath 2.0, XQuery 1.0, XSL-T 1.0 and Schema 1.0 stacks as well as a partly complete XSL-T 2.0 stack: http://doc.qt.nokia.com/4.7/xmlprocessing.html#features-and-conformance -- Frans Englich ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
On Nov 7, 2010, at 16:36 , Alex Milowski wrote: > On Sun, Nov 7, 2010 at 1:25 AM, Frans Englich wrote: >> >> Qt has complete XPath 2.0, XQuery 1.0, XSL-T 1.0 and Schema 1.0 stacks as >> well as a partly complete XSL-T 2.0 stack: >> >> http://doc.qt.nokia.com/4.7/xmlprocessing.html#features-and-conformance > > Very interesting. Has this been integrated at all with WebKit? As far as I know, no, but I'm busy with studies these days. I guess one of the first questions is rather how the two stacks, Qt and Webkit, should relate to each other on this particular field, what the aim of the integration is and the nature of the integration, as well as dependencies. But it seems interesting to have these technologies in Webkit. What's your thoughts on how it would be carried be done? (I wrote the XPath, XQuery and XSL-T code and mentored the Schema code. However, I'm no longer employed by Nokia.) -- Frans Englich ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
[...] >> (I wrote the XPath, XQuery and XSL-T code and mentored the Schema code. >> However, I'm no longer employed by Nokia.) >> > > That's good to know! > > Have the compliance tests for XSLT 2.0 and XQuery been run? Yes, the details are at: http://doc.qt.nokia.com/4.7/xmlprocessing.html#features-and-conformance -- Frans Englich ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
