Saxon » Saxon-CE

Thanks for reporting this - beta 0.1 has a number of namespace issues on the HTML side (see #1455), but this was thought to be less marked with XHTML. I'll check out your test-case on our latest Saxon-CE build (where namespace handling has been re-worked) when I get into the office.

Not sure anymore the problem is namespace or use element related (it was a bit late when I wrote the issue). When you add

	<xsl:result-document href="#clip-path" method="ixsl:append-content" xmlns="http://www.w3.org/2000/svg">
		<use xlink:href="#_1474"/>
	</xsl:result-document>

First, I'll address the namespace problem - because it was definitely an issue in beta 0.1 in certain use cases (though perhaps it's just a contributory factor here):

With the beta 0.2 (pre-release) I get this result in the log - this is, both xsl:message outputs are true:

For info, to achieve this in beta 0.2 I had to: 1) add the namespace declaration for xhtml 2) add the xpath-default-namespace attribute for xhtml and 3) add svg: prefixes for svg name-tests in the XPath. (These extra namespace declarations are what you would expect for a namespace-aware browser, but weren't necessary in beta 0.1). So, the final XSLT looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:transform version="2.0"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns:ixsl="http://saxonica.com/ns/interactiveXSLT"
xmlns:prop="http://saxonica.com/ns/html-property"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xlink="http://www.w3.org/1999/xlink"
extension-element-prefixes="ixsl"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xpath-default-namespace="http://www.w3.org/1999/xhtml"
>
<xsl:variable name="svg" select="ixsl:page()/html/body/svg:svg" as="element()"/>
<xsl:variable name="g" select="$svg/svg:g/svg:g/svg:g" as="element()+"/>

<xsl:template match="/">
<xsl:message select="boolean($g/svg:g[@id='&lt;Raumtrennung&gt;_2'])"/>
<xsl:message select="boolean($g/svg:use[@xlink:href='#Ohne_Bezeichnung_1'])"/>
<xsl:result-document href="#title" method="ixsl:replace-content">
<xsl:value-of select="$svg/title"/>
</xsl:result-document>
</xsl:template>
</xsl:transform>

I'll now check out the second part - writing the use element with an xlink:href attribute...

Testing (in beta 0.2 pre-release) your modified XSLT that replaces clip-path content with the use element is added fine. This case is similar to an SVG test-case I had created.

Note that SVG elements referenced in this way, with xlink:href, are technically outside the DOM, so user-events for these require special handling by Saxon-CE (see issue #1456). From the XSLT developer's perspective the behaviour is the same as if the referenced elements were within the DOM, so you can use ixsl:event handdling templates in the usual way.

This is very good news! These are the last pieces I would need to implement dynamic clipping (I've checked it statically). Thank you!

Thanks for sending in this log.

Firstly, the 'Failed Attribute' warnings that appear are not Saxon-CE issues they're just a browser complaint because we're using a script element in an unrecognised way - that the browser doesn't need to care about.

Here's the key part of the log:

SaxonCE.XSLT20Processor 00:19:32.375 FINE: Aynchronous GET for: file:/E:/saxon-ce/Plaene/test3/svg-t5-011.svg

SaxonCE.XSLT20Processor 00:19:34.272 FINE: Compiling Stylesheet...

SaxonCE.XSLT20Processor 00:19:36.939 FINE: Stylesheet compiled OK

The log appears to finish at this point, but Saxon-CE is still waiting on a response from the asynchronous get for svg-t5-011.svg - the next line should be a 'Response Received' line and then a 'Starting transform...' line.

No response was logged for the asynchronous get, and I don't know quite why - if there was an HTTP error, then this should appear in Saxon-CE's log, but the browser console should report the HTTP error independently also.

I will try this out also as soon as I can, but here are a few things to check:

1. Are you still using Opera?

2. Have you explicitly cleared your browser's cache? - Opera tends to hang on to files a bit longer than other browsers

3. Is the reported URI for the svg file good?

4. Have you tried this in another browser - did it fail there also?

5. As reported earlier in this thread, there were breaking changes in beta 0.2 regarding namespaces, which would definitely require changes to your XSLT - have you updated your XSLT/XPaths for the XHTML and SVG namespaces? (I ask this last, because this won't yet be the main issue - even with namespace issues - we should still see 'Response Received' and 'Transform Started' log entries.)

I missed this earlier:

The URI for the SVG is a file-system URI: file:/E:/saxon-ce/Plaene/test3/svg-t5-011.svg

You are probably going to get strange behaviour with browsers on the file-system (instead of using HTTP) because of security issues, but also because I'm not sure (i.e. it's un-tested) how well XMLHTTPRequest behaves asynchronously in this scenario.

One further point, the timings in the log seem incredibly slow, you have intervals measured in seconds when they should be (at least, from my tests) in milliseconds, e.g. there's nearly a 2 second interval between the GET and the start of the compile. Is this a hardware issue, or were other tasks running in the 'background'?

First the good news: the test works fine on http! To your questions:

1., 4. The console log is from Opera 11.62 and Firfox 11.0

2. Browser cache is cleared.

3. The svg file is good.

4. I simply copied the xsl you modified.

I don't think it's a security issue, as I have

Firefox, about:config security.fileuri.strict_origin_policy;false

Opera, opera:config#UserPrefs Allow File XMLHttpRequest

About the timings, it's only Firefox that slow, Opera is just fine.

Now we know this isn't a security issue, the most likely cause is that XMLHTTPRequest doesn't work properly with the 'file' protocol in asynchronous mode. I will try adding a patch that checks the URI for the protocol and switches to synchronous mode for this case.

I've opened a new issue for this, see #1507.