Hi Mary,
Here is a repro. Basically, the stylesheet matches the element `elem`
in no namespace, and provides a default rule for all elements. It
return some info about which rule matched and about the element. The
stylesheet root element has the default namespace set to `ns` (even
though it's never used).
The overall query applies the stylesheet to an element `elem`, both in
no namespace and in namespace `ns`, with several dialects set on the
stylesheet (or none at all).
The full result is below, but basically it all comes down to this:
<elem xmlns=""/> | no dialect | match="elem"
<elem xmlns=""/> | any dialect | DOES NOT match="elem"
<elem xmlns="ns"/> | no dialect | does not match="elem"
<elem xmlns="ns"/> | any dialect | DOES match="elem"
The most likely explanation is that the default namespace in scope
applies (wrongly) to the match pattern match="elem", when any dialect
is set. Tested on (same results on all of them):
- 8.0-1.1
- 8.0-3
- 9.0-ea1
The repro code:
declare variable $cases :=
<cases>
<case><elem/></case>
<case xdmp:dialect="1.0-ml"><elem/></case>
<case xdmp:dialect="1.0"><elem/></case>
<case xdmp:dialect="3.0"><elem/></case>
<case xdmp:dialect="3.1"><elem/></case>
<case><elem xmlns="ns"/></case>
<case xdmp:dialect="1.0-ml"><elem xmlns="ns"/></case>
<case xdmp:dialect="1.0"><elem xmlns="ns"/></case>
<case xdmp:dialect="3.0"><elem xmlns="ns"/></case>
<case xdmp:dialect="3.1"><elem xmlns="ns"/></case>
</cases>;
for $c in $cases/*
return
xdmp:xslt-eval(
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
xmlns="ns"
exclude-result-prefixes="#all"
version="2.0">
{ $c/@xdmp:dialect }
<xsl:template match="elem">
<result dialect="{ $c/@xdmp:dialect }" match="yes" ns="{{
namespace-uri(.) }}" name="{{ local-name(.) }}">
<xsl:sequence select="."/>
</result>
</xsl:template>
<xsl:template match="*">
<result dialect="{ $c/@xdmp:dialect }" match="NO" ns="{{
namespace-uri(.) }}" name="{{ local-name(.) }}">
<xsl:sequence select="."/>
</result>
</xsl:template>
</xsl:stylesheet>,
$c/*)
The full result:
<result dialect="" match="yes" ns="" name="elem" xmlns="ns">
<elem xmlns=""/>
</result>
<result dialect="1.0-ml" match="NO" ns="" name="elem" xmlns="ns">
<elem xmlns=""/>
</result>
<result dialect="1.0" match="NO" ns="" name="elem" xmlns="ns">
<elem xmlns=""/>
</result>
<result dialect="3.0" match="NO" ns="" name="elem" xmlns="ns">
<elem xmlns=""/>
</result>
<result dialect="3.1" match="NO" ns="" name="elem" xmlns="ns">
<elem xmlns=""/>
</result>
<result dialect="" match="NO" ns="ns" name="elem" xmlns="ns">
<elem/>
</result>
<result dialect="1.0-ml" match="yes" ns="ns" name="elem" xmlns="ns">
<elem/>
</result>
<result dialect="1.0" match="yes" ns="ns" name="elem" xmlns="ns">
<elem/>
</result>
<result dialect="3.0" match="yes" ns="ns" name="elem" xmlns="ns">
<elem/>
</result>
<result dialect="3.1" match="yes" ns="ns" name="elem" xmlns="ns">
<elem/>
</result>
Hope that helps, regards,
--
Florent Georges
http://fgeorges.org/
http://h2oconsulting.be/
On 8 March 2016 at 16:56, Florent Georges <li...@fgeorges.org> wrote:
> Hi Mary,
>
> Thank you, using xdmp:dialect="3.0" indeed works!
>
> But it seems to have also the side-effect to apply the default namespace in
> scope to match patterns. So if you have, say, the HTML namespace declared
> as the default namespace (which is almost required to generate HTML
> properly), then the following will match elements named `elem` in the HTML
> namespace, instead of in no namespace:
>
> <xsl:template match="elem">
>
> Do you want me to work out a repro?
>
> Regards,
>
> --
> Florent Georges
> http://fgeorges.org/
> http://h2oconsulting.be/
>
>
> On 7 March 2016 at 16:33, Mary Holstege wrote:
>>
>>
>>
>> XPath in an XSLT 2.0 context in MarkLogic uses strict 2.0 conformance mode
>> (same as if you declare the XQuery version as 1.0).
>>
>> There is a hook to use different dialects instead and these have the same
>> impact on XPath in XSLT as they do on XPath in XQuery.
>>
>> Add the attribute xdmp:dialect e.g.
>>
>> <xsl:stylesteet xdmp:dialect="1.0-ml"....
>>
>>
>> //Mary
>>
>> On Sun, 06 Mar 2016 02:34:50 -0800, Florent Georges wrote:
>>
>> > Hi,
>> >
>> > If I try to use the XPath 3.0 mapping operator `!` or the concat
>> > operator
>> > `||`,
>> > MarkLogic throws an error:
>> >
>> > XDMP-EXTENSION: (err:XPST0003) MarkLogic extension syntax used,
>> > simple
>> > mapping expressions are not supported in XSLT mode
>> >
>> > But they are not MarkLogic extensions, they are standard XPath operators
>> > (but
>> > in version 3.0, rather than in version 2.0 supported by XSLT 2.0,
>> > supported
>> > by
>> > MarkLogic.) At least in forward compatibility mode, I think they should
>> > be
>> > "unlocked".
>> >
>> > Well, at least if it is only a matter of "unlocking" them. I assume
>> > they
>> > have
>> > been disabled from XSLT, even although their implementation in XQuery
>> > can be
>> > reused as is, but maybe there is an more profound reason why they were
>> > disabled
>> > in the first place.
>> >
>> > Regards,
>> >
>>
>>
>> --
>> Using Opera's revolutionary email client: http://www.opera.com/mail/
>> _______________________________________________
>> General mailing list
>> General@developer.marklogic.com
>> Manage your subscription at:
>> http://developer.marklogic.com/mailman/listinfo/general
>
>
>
>
--
Florent Georges
http://fgeorges.org/
http://h2oconsulting.be/
_______________________________________________
General mailing list
General@developer.marklogic.com
Manage your subscription at:
http://developer.marklogic.com/mailman/listinfo/general
