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
Re: [webkit-dev] XPath Issues?
On Tue, Nov 9, 2010 at 8:00 PM, Eric Seidel e...@webkit.org wrote: This conversation is heading in a dangerous direction... :) Allowing QXML parser support to be added to WebKit was probably a mistake. Adding custom QXPath or QXSLT support would be another. WebKit is one platform. If XSLT or XPath 2.0 is good for the web, we should add them to all ports, just like we did XPath 1.x. The only reason XMLDocumentParserQt hasn't been a bigger compatibility problem (or source of crashes, security bugs, etc.) for the Qt Port is that XML is used so very very very little on the web (and it's relatively simple to parse). (The XMLDocumentParserQt was a huge headache for Adam and I when trying to re-factor DocumentParser for HTML5, for example. I'm sure we introduced still-present bugs in it.) Implementing XSLT 2.0 or just XPath 2.0 is a huge engineering effort. Like many other things, we should rely on an existing implementation if possible that can be used on the various platforms. I'd rather see a general solution where you can turn on 2.0 support and swap out the current use of libxslt. XSLT 2.0 is continuously asked about by those people who use XSLT in the browser. There are so many things that just work better or features that are now standard. It would be a real win to have such support that also runs efficiently within the context of transforming XML. Most of the implementations that I've looked at would also solve a number of issues with the current integration of libxslt as they wouldn't require serialization of the document to transform an exist XML DOM (e.g. transforming a node via javascript). The question is which one? I'm leaning towards xquilla as a choice but their XSLT 2.0 implementation isn't quite finished. The API is relatively clean and their implementation is active. It would also provide the ability to use XPath 2.0 and XQuery (although there is no API for that as of yet). The technical issue with xquilla is that their API uses XMemory, MemoryManager and few other low-level base classes for certains aspects like memory management, strings, etc. This would have to be resolved (or accepted) so that it would integrate well with WebKit. I suspect this sounds like a radical departure to many of you out there. In the case of things like libxslt, we expect it to be available on the platform or development environment so that it can be linked into WebKit somehow. We'd now add another such dependency for a new library that you might have to compile somehow. Thoughts on that? Also, keep in mind that I'm still trying to figure out which implementation would be the best choice given the architecture and API design of WebKit. -- --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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
On Wed, Nov 10, 2010 at 10:29 AM, Maciej Stachowiak m...@apple.com 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. XSLT 2.0 provides what it calls backwards compatibility mode. When an XSLT 2.0 processor encounters a transformation labeled with a version of 1.0, it can run that transform in the backwards compatibility mode. There are very minor differences but I highly doubt they would break existing uses (see [1]). For example, XPath 2.0 has the concept of sequences rather than node sets and within certain context, the string value will be space separated rather than the string value of the first node. If someone wrote a stylesheet assuming (or more likely accidentally using) that fact, with an XSLT 2.0 processor, the string value in the result would be from all the nodes. The output would essentially be slightly different. One could argue that was a poorly written stylesheet and it would be very easy to fix so that it had consistent behavior in XSLT 1.0 and 2.0 stylesheets. 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. 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. I guess I was thinking, to begin with, that this would be a compile-time feature that you could turn on. That's not a cheap experiment but, to begin with, I'm really talking about *my* time to implement such an integration. I have uses for such things and I just want to do it in such a way that the work would be an acceptable implementation if vendors choose to switch to 2.0. 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. 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. [1] http://www.w3.org/TR/xslt20/#backwards-compatibility-behavior -- --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 ___ 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 2:54 AM, Alex Milowski wrote: On Wed, Nov 10, 2010 at 10:29 AM, Maciej Stachowiak m...@apple.com 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. XSLT 2.0 provides what it calls backwards compatibility mode. When an XSLT 2.0 processor encounters a transformation labeled with a version of 1.0, it can run that transform in the backwards compatibility mode. There are very minor differences but I highly doubt they would break existing uses (see [1]). Do most existing XSLT 1.0 stylesheets have an explicit 1.0 label? Does XSLT require this? How would unlabeled stylesheets be processed? For example, XPath 2.0 has the concept of sequences rather than node sets and within certain context, the string value will be space separated rather than the string value of the first node. If someone wrote a stylesheet assuming (or more likely accidentally using) that fact, with an XSLT 2.0 processor, the string value in the result would be from all the nodes. The output would essentially be slightly different. One could argue that was a poorly written stylesheet and it would be very easy to fix so that it had consistent behavior in XSLT 1.0 and 2.0 stylesheets. 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. 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. I guess I was thinking, to begin with, that this would be a compile-time feature that you could turn on. That's not a cheap experiment but, to begin with, I'm really talking about *my* time to implement such an integration. I have uses for such things and I just want to do it in such a way that the work would be an acceptable implementation if vendors choose to switch to 2.0. 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. 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. (I also gave Alex some contact info for relevant folks at Opera and Mozilla out of band.) Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
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. Regards, Maciej On Nov 10, 2010, at 1:53 AM, Alex Milowski wrote: On Tue, Nov 9, 2010 at 8:00 PM, Eric Seidel e...@webkit.org wrote: This conversation is heading in a dangerous direction... :) Allowing QXML parser support to be added to WebKit was probably a mistake. Adding custom QXPath or QXSLT support would be another. WebKit is one platform. If XSLT or XPath 2.0 is good for the web, we should add them to all ports, just like we did XPath 1.x. The only reason XMLDocumentParserQt hasn't been a bigger compatibility problem (or source of crashes, security bugs, etc.) for the Qt Port is that XML is used so very very very little on the web (and it's relatively simple to parse). (The XMLDocumentParserQt was a huge headache for Adam and I when trying to re-factor DocumentParser for HTML5, for example. I'm sure we introduced still-present bugs in it.) Implementing XSLT 2.0 or just XPath 2.0 is a huge engineering effort. Like many other things, we should rely on an existing implementation if possible that can be used on the various platforms. I'd rather see a general solution where you can turn on 2.0 support and swap out the current use of libxslt. XSLT 2.0 is continuously asked about by those people who use XSLT in the browser. There are so many things that just work better or features that are now standard. It would be a real win to have such support that also runs efficiently within the context of transforming XML. Most of the implementations that I've looked at would also solve a number of issues with the current integration of libxslt as they wouldn't require serialization of the document to transform an exist XML DOM (e.g. transforming a node via javascript). The question is which one? I'm leaning towards xquilla as a choice but their XSLT 2.0 implementation isn't quite finished. The API is relatively clean and their implementation is active. It would also provide the ability to use XPath 2.0 and XQuery (although there is no API for that as of yet). The technical issue with xquilla is that their API uses XMemory, MemoryManager and few other low-level base classes for certains aspects like memory management, strings, etc. This would have to be resolved (or accepted) so that it would integrate well with WebKit. I suspect this sounds like a radical departure to many of you out there. In the case of things like libxslt, we expect it to be available on the platform or development environment so that it can be linked into WebKit somehow. We'd now add another such dependency for a new library that you might have to compile somehow. Thoughts on that? Also, keep in mind that I'm still trying to figure out which implementation would be the best choice given the architecture and API design of WebKit. -- --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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
On Wed, Nov 10, 2010 at 11:25 AM, Maciej Stachowiak m...@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
divWahooo!/div
/xsl:when
xsl:otherwise
divBooo!/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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
On 11/09/2010 09:00 PM, Eric Seidel wrote: This conversation is heading in a dangerous direction... :) Allowing QXML parser support to be added to WebKit was probably a mistake. Adding custom QXPath or QXSLT support would be another. I agree with the first statement but disagree with the second. One of the strengths of WebKit is the integration into the base technology (or whatever you want to pick), we don't have to find the least common denominator to make everyone happy. On the other hand it is a pity that Nokia is so behind in many ways, they should have had the engineering force to assist you and Adam to fix the XML support with your new parser work. They should have the resources to go through the LayoutTests and make QtWebKit pass more... sorry for sidetracking the discussion a bit. z. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
On Wed, Nov 10, 2010 at 2:12 PM, Alex Milowski a...@milowski.org wrote: * 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.)? One more datum, that I just discovered, Apple has implemented XPath 2.0, XSLT 2.0, and XQuery: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/NSXML_Concepts/NSXML.html (oh, the use of the fragment identifier for content location is just horrific!) Thus, on some platforms (Mac OS X, iOS 4.x), you get XSLT 2.0 support for free. Seems like the ability to use an OS's native support would be ideal as long as the same specification version support is available through some means on each port. -- --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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
This conversation is heading in a dangerous direction... :) Allowing QXML parser support to be added to WebKit was probably a mistake. Adding custom QXPath or QXSLT support would be another. WebKit is one platform. If XSLT or XPath 2.0 is good for the web, we should add them to all ports, just like we did XPath 1.x. The only reason XMLDocumentParserQt hasn't been a bigger compatibility problem (or source of crashes, security bugs, etc.) for the Qt Port is that XML is used so very very very little on the web (and it's relatively simple to parse). (The XMLDocumentParserQt was a huge headache for Adam and I when trying to re-factor DocumentParser for HTML5, for example. I'm sure we introduced still-present bugs in it.) Please excuse me if I mis-understood your suggestions of integrating these Qt features with WebKit. -eric On Tue, Nov 9, 2010 at 1:46 AM, Alex Milowski a...@milowski.org wrote: On Mon, Nov 8, 2010 at 7:09 PM, Frans Englich fengl...@fastmail.fm wrote: 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 think the simplest answer is for one to be able to turn on Qt XML support without having to use the whole Qt port. In my research into how all this is put together, the XPath and XSLT support within the browser is separable. Any library could be integrated by simply adding a build option to do so. I've been looking at XQuilla in this same way. They have an XPath 2.0, XQuery, and XSLT 2.0 implementation that looks to be very easy to integrate. The only is that they rely on some internals from Xerces-C that seem rather superfluous. That is, you don't have to use the Xerces-C parser to use their system. Any implementation of XSLT or XPath needs to be able to use the XML DOM directly in some way. This would avoid any kind of strange serialization (which is what happens when XSLT is called from Javascript with libxslt) that currently causes bugs. In addition, the XPath implementation can't really serialize and expect to get the context node correct. (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? -- --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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ 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 fengl...@fastmail.fm 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?
On Sun, Nov 7, 2010 at 1:25 AM, Frans Englich fengl...@fastmail.fm 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? -- --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 ___ 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 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 Wed, Nov 3, 2010 at 6:28 PM, Alexey Proskuryakov a...@webkit.org wrote: 03.11.2010, в 10:11, Alex Milowski написал(а): many of the incompatibilities may not occur within the context of the browser with a pre-built DOM. WebKit currently applies XSLT to document source, not to pre-built DOM. This is different from Firefox, but in strict compliance to the spec. WebKit currently applies XSLT to a serialization of the pre-build XML DOM. As such, we have several bugs relating to cases where that serialization is not the same as the data received off the wire. Also, we can't expect to stay at XPath 1.0 forever. Actually, I see this situation as similar to XHTML 2.0. XPath is embedded into browsers both directly and via XSLT. Any incompatible specification featuring the same name is likely to end up as an academic exercise, dead on arrival. Looking at Mozilla bugs, they seem to have zero interest in XPath 2.0 and XSLT 2.0: https://bugzilla.mozilla.org/show_bug.cgi?id=396966 https://bugzilla.mozilla.org/show_bug.cgi?id=370173 They might not but users do. Mozilla has its own XSLT 1.0 implementation that is not complete. I don't think that's a great comparison. We would need to pull an off the shelf implementation of XPath and XSLT 2.0. -- --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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
On Thu, Nov 4, 2010 at 2:16 PM, Alex Milowski a...@milowski.org wrote: WebKit currently applies XSLT to document source, not to pre-built DOM. This is different from Firefox, but in strict compliance to the spec. WebKit currently applies XSLT to a serialization of the pre-build XML DOM. As such, we have several bugs relating to cases where that serialization is not the same as the data received off the wire. My belief, and please correct me if I'm wrong, is that once the XML has been parsed and built into a DOM, applyXSLTransform() at Document.cpp:3954 is eventually called with the correct XSLT from some xml-stylesheet processing instruction. With the libxslt, the DOM is serialized back into a string so it can be loaded into their internal format as they don't provide a way to give them a pre-existing DOM. I've been trying to trace through all the places where XSLT is used and how this all fits together. Finding an alternative to libxslt is something I think is a worthwhile endeavor due to the inability to integrate tightly with a pre-built DOM instance. -- --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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
On Thu, Nov 4, 2010 at 2:17 PM, Alex Milowski a...@milowski.org wrote: On Thu, Nov 4, 2010 at 2:16 PM, Alex Milowski a...@milowski.org wrote: WebKit currently applies XSLT to document source, not to pre-built DOM. This is different from Firefox, but in strict compliance to the spec. WebKit currently applies XSLT to a serialization of the pre-build XML DOM. As such, we have several bugs relating to cases where that serialization is not the same as the data received off the wire. Nevermind. My mistake. I should have dug further. Yes, I see that in the case of XSLT via the xml-stylesheet, we use the cached source. In the case of the Javascript XSLT processor, that's not the case and that's how we get differences. Nevertheless, I don't see how the xml-stylesheet spec [1] says you have to use the bytes off the wire. [1] http://www.w3.org/TR/xml-stylesheet/ -- --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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] XPath Issues?
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 ... -- --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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
03.11.2010, в 9:38, Alex Milowski написал(а): https://bugs.webkit.org/show_bug.cgi?id=26157 This is a request to implement an optimization, and one that doesn't seem particularly likely to provide material benefits. The optimization has an observable effect of reusing the same object though. https://bugs.webkit.org/show_bug.cgi?id=12504 Namespace nodes are pure evil, we shouldn't do that. https://bugs.webkit.org/show_bug.cgi?id=13233 This is a place to track future optimization ideas and performance tests. https://bugs.webkit.org/show_bug.cgi?id=12632 This is correct behavior, but Firefox has a bug. We could match Firefox, but with no actual sites known to be affected that doesn't seem important. https://bugs.webkit.org/show_bug.cgi?id=12496 An optimization opportunity. https://bugs.webkit.org/show_bug.cgi?id=36427 Unspecified behavior, different from Firefox. 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 think that the only actual bug we have was not on the list, https://bugs.webkit.org/show_bug.cgi?id=34231. JS wrappers should be preserved for all reachable nodes, which includes nodes in XPath result sets. I'm also looking at what it would take to enhance this implementation to support XPath 2.0 ... XPath 2.0 is not fully compatible with 1.0. JavaScript API for XPath doesn't provide a way to choose version - at least, it didn't when I last checked. So, we can't really support 2.0. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
On Wed, Nov 3, 2010 at 9:56 AM, Alexey Proskuryakov a...@webkit.org wrote: XPath 2.0 is not fully compatible with 1.0. JavaScript API for XPath doesn't provide a way to choose version - at least, it didn't when I last checked. So, we can't really support 2.0. I'm not sure that turns out to be a real issue considering this particular context. I've been shopping this idea around here at the W3C TPAC meeting and many of the incompatibilities may not occur within the context of the browser with a pre-built DOM. I'll have to dig further on that. It is certainly flawed that you can't choose a version. Unfortunately, there isn't a good way to test for XPath 1.0 but you can use an XPath 2.0 only expression to test for XPath 2.0 support. This should be fixed in the API. Also, we can't expect to stay at XPath 1.0 forever. At any rate, this would be considered completely experimental. -- --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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
03.11.2010, в 10:11, Alex Milowski написал(а): many of the incompatibilities may not occur within the context of the browser with a pre-built DOM. WebKit currently applies XSLT to document source, not to pre-built DOM. This is different from Firefox, but in strict compliance to the spec. We have separate XPath implementations for XSLT and for DOM bindings though, and the latter operates on DOM indeed (which is in accordance with http://www.w3.org/TR/2004/NOTE-DOM-Level-3-XPath-20040226/DOM3-XPath.html). Also, we can't expect to stay at XPath 1.0 forever. Actually, I see this situation as similar to XHTML 2.0. XPath is embedded into browsers both directly and via XSLT. Any incompatible specification featuring the same name is likely to end up as an academic exercise, dead on arrival. Looking at Mozilla bugs, they seem to have zero interest in XPath 2.0 and XSLT 2.0: https://bugzilla.mozilla.org/show_bug.cgi?id=396966 https://bugzilla.mozilla.org/show_bug.cgi?id=370173 - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
