When "@path" is included in a Schema file, an error is output.

[GoogleCodeExporter]

What steps will reproduce the problem?

1. I want to create a Schematron validation function on Java and Saxon.
2. When I use a Schema file, such as the file "sample.sch" shown below.
3.

--sample.sch------------------------------------
<schema xmlns="http://purl.oclc.org/dsdl/schematron" queryBinding="xslt2"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <phase id="General">
        <active pattern="sample"/>
    </phase>
    <pattern id="sample">
        <rule context="*">
            <assert test="if (empty(@xml:lang)) then true()
                                else string(@xml:lang) = ('en', 'ja-JP')">
                <name path="@xml:lang"/> attribute value must be "en" or "ja-JP".
            </assert>
        </rule>
    </pattern>
</schema>
------------------------------------------------

What is the expected output? What do you see instead?

The following error is output:
"Bad name element: XPath error. No XPath."

What version of the product are you using? On what operating system?

http://schematron.googlecode.com/files/iso-schematron-xslt2.zip
OS:Windows 7 Professional SP1
Java:jre-7u51-windows-i586.exe
Saxon:saxonb9-1-0-8j

Please provide any additional information below.

In the file iso_dsdl_include_xsl, is it okay to use (B) instead of (A)?
(A) <xslt:template match="iso:name[@path]" mode="dsdl:go">...<xsl:with-param 
name="string" select=" @select "  />
(B) <xslt:template match="iso:name[@path]" mode="dsdl:go">...<xsl:with-param 
name="string" select=" @path "  />

Also, is there a better way do this?

Original issue reported on code.google.com by UserExpe...@gmail.com on 21 Apr 2014 at 1:26

[rjelliffe]

There is a confusion over whether sch:name allows @select or @path. Whatever the ISO standard says should be used. (Both can be supported to allow a transition, I suppose, if necessary.)

This was also reported by Burkhart Lingner:

Recently I came to use Schematron as an extension to existing XSD Schemas and I like it a lot. Recently I got a warning message that after some digging led me to believe that maybe there’s a bug in the iso_dsdl_include.xsl that I downloaded from http://www.schematron.com/implementation.html as part of the iso-schematron-xslt1.zip file.

When using a sch:name element with @path but without @select I get the message “Bad name element: XPath error. No XPath.” from the XSLT processor. I traced this message back to line 203 with . That template calls another template named “sch-check:xpath-wf-message” with a “string” parameter set to “ @select “. What ultimately happens is that an is invoked if the name element’s @select has a string-length of zero. The problem is easily mitigated by supplying the name element with a @select that contains a dummy string with at least one character. I did some tests and the @select didn’t influence the output of the name element whereas the @path did, just as expected. After all, the ISO spec refers to the name/@path. The only occurrence of a name/@select that I found was in the EXSLT-related Annex J of the preparatory draft from 2010-04-02:

The name query is interpreted according to Production 14 of

XPath, as returning a string value. Typically, the select attribute

contains an expression returning an element node: the name

query takes the local or prefixed name of the node, not its value.

If I understand the situation correctly, all would be well by modifying iso_dsdl_include.xsl so as to use @path for the “string” parameter of sch-check:xpath-wf-message in line 205. Additionally, Annex J of the ISO draft should probably refer to @path instead of @select. However, I’m new to Schematron and I examined only parts of the XSLT, so I’d be happy to hear your assessment.

[rjelliffe]

This is a bug for abstract patterns that affects IPDF. See https://code.google.com/p/epub-revision/issues/detail?id=194