Testing a function/template that returns an attribute with x:expect/@test

[AxelCourt]

Hi,

Testing a function or a named template that returns an attribute seems to generate incorrect XSL code. See the attached example: test.zip.

<x:expect label="Should work but doesn't" test=". = 'value'"/>

Using @test with an XPath expression that returns a boolean value (where . here is an attribute node) causes the generated XSL to fail with the following error:
XTDE0420: Cannot create an attribute node (class) whose parent is a document node.

I managed to make the test work by using <x:variable> to create the expected result, and comparing it to the template result with @select:

<x:variable name="tmp.result">
  <_null class="value"/>
</x:variable>
<x:expect label="Works OK" select="$tmp.result/@class"/>

Is there another way to test such a template or is this a bug?
Is the use of <x:variable> safe and/or recommended, since it is not in the RNG schema?

Thanks.
Axel

[AirQuick]

Is the use of <x:variable> safe and/or recommended, since it is not in the RNG schema?

I was going to file an issue regarding this. test/*.xspec files do not pass validation due to x:variable...

[AirQuick]

Another workaround (without worrying about x:variable) would be

    ...
    </x:call>
    <x:expect label="Works OK" select="_null/@class">
      <_null class="value"/>
    </x:expect>

[AxelCourt]

Thank you for the workaround, that should do the trick for now! The solution was right under my nose though...

[cirulls]

@AxelCourt : thanks for uncovering the issue of x:variable not in the RNG Schema. Are you happy with the workaround provided by @AirQuick? Can we close this issue?

@AirQuick : thanks for providing support to @AxelCourt. Shall we raise a ticket for assessing the inclusion of x:variable to the RNG Schema?

[cirulls]

@AirQuick : I just noticed that you already raised #60 for the RNG Schema, thanks.

[AirQuick]

Though there is a workaround, I think this is a bug. I have a possible fix. Will submit it in a few days.
If the fix is not feasible, then the behavior should be documented, I think.
So let me update the label and the milestone.

[cirulls]

That's fine, feel free to send a pull request for this.

[AxelCourt]

Thanks for your answer @cirulls but I agree with @AirQuick : there is a bug with the @test attribute that should be dealt with, or at least the documentation should be updated to explain the proper way to test functions / templates that return attributes.

[cirulls]

@AxelCourt : Ok, let's keep this issue open until @AirQuick submits a pull request. We will address this in v0.6.0.

[cmarchand]

Hello !

@AirQuick sample from 01/11 doesn't work with 0.5.0, but was working before.
Error is :
ERROR in scenario "xxx": can't have both @select and context at the same time

Attached a sample.
expect_select_context.zip

Best,
Christophe

[AirQuick]

Hi @cmarchand,
The sample works fine on my end.
Make sure you're using the last released version of v0.5.0. The error message suggests it's one of the pre-release versions.

[cmarchand]

You should be right, I've build xspec-maven-plugin just after the first announcement.

It is important that we do not publish many versions of the same release, because it is confusing.

For 0.6.0, we could publish RCx before publishing the 0.6.0.
Or use 0.6.0, 0.6.1, 0.6.2...

I check this.

Thanks

[AirQuick]

I've incorporated your "two attributes" case into the test cases for the proposed fix (not submitted yet). So your sample scenario should work reliably in the future.

Regarding the versioning, I also remember the v0.5.0 tag was floating. Looks like @cirulls has stopped it, following the discussion in #53. So, for v0.6.0+, my understanding is that the master branch is the continuous RC, and the tagged version is the released version.

[cirulls]

That's correct. I initially created the tag v0.5.0 back in November 2016 to allow @cmarchand to retrieve XSpec via a single zip file for his projects. When the official release was done in January 2017, I updated that tag with the latest release.

I keep track of the changes we make in a release draft (I'm not sure you can see it in https://github.com/xspec/xspec/releases) but I will only make an official release at a specific point in time (and ask for approval from the XSpec community). All the latest changes are available in master branch but if you want to have a less bleeding edge and more stable release I suggest to use the official releases.

[cmarchand]

Thanks a lot !

Regarding versionning, I build xspec-maven-plugin from release.
It is important that these "release"s don't change. Does the zip file has the same content than the tagged sources ?

[AirQuick]

I've submitted the pull request to fix this.

Included @AxelCourt 's case and its possible workaround in test/xspec-59_use-case-1.*.

Also included @cmarchand 's use case in test/xspec-59_use-case-2.*.

With the fix, both cases should work.

[AirQuick]

At the end of this month, this issue will finally be fixed for XSLT by merging #317.
XQuery is fixed by #498 which is not very soon to be merged.
Anyone still interested in this issue can test the fixes by cloning #498. (git clone -b xquery-report-sequence https://github.com/AirQuick/xspec)