This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 30145 - [xslt30ts] streamable-015 expected result assumes validation of xsl:source-document input
Summary: [xslt30ts] streamable-015 expected result assumes validation of xsl:source-do...
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 Test Suite (show other bugs)
Version: Proposed Recommendation
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Abel Braaksma
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
: 30218 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-07-14 11:42 UTC by Botond Biró
Modified: 2019-02-26 00:38 UTC (History)
2 users (show)

See Also:


Attachments

Description Botond Biró 2017-07-14 11:42:15 UTC
The test case streamable-015 in the streamable test-set assumes validation/type info on the document processed by xsl:source-document.
From https://www.w3.org/TR/xslt-30/#validation §3 I'd assume that the lack of the validation attribute on the xsl:source-document has the same effect as validation="strip".
So when constructing the attributes UnpaidPrincipalBalanceAmount the value won't be converted to string via FmAmount/xs:decimal (as it would be with available psvi) and thus retaining the trailing .0 in the values. However the 3rd assert expects the integer form:

 <assert>deep-equal(//@UnpaidPrincipalBalanceAmount/string(), 
                                 ('350000', '350000', '500000', '750000', '175000'))</assert>

Imho one could choose from the following resolutions:
a) add a validation attribute to the xsl:source-document with a value other than strip
b) update the test asserts
c) the default validation mode on xsl:source-document is other than strip - in which case I kindly ask for a reference to the relevant part of the xslt spec.

best regards,
Botond Biró

p.s. in the streamable test-set there are several other test cases -specifying  a source with @validation="strict" - that could be also affected
Comment 1 Michael Kay 2017-07-14 16:06:34 UTC
Thanks for the comment.

Firstly, you raise questions about the spec. In the absence of xsl:source-document/@validation (or @type), validation is either preserve or strip based on the value of @input-type-annotations, which defaults to "unspecified". The meaning of "unspecified" appears to be unspecified (!). So I think my reading of the spec is that for this stylesheet, it is implementation-defined whether the source document is schema-validated or not (and if it is schema-validated, whether type annotations are stripped or retained). Although not highly interoperable, this default has the merit of being consistent with the document() function.

In the test metadata, the test uses environment "loans", and this environment specifies that the file loans.xml should be parsed with validation="strict". So we could legitimately argue that although the spec leaves it undefined, the test metadata does not.

But I have some sympathy with an argument that says the processor is not required to provide an API that allows the calling application to decide whether files read using xsl:source-document should or should not be validated, and therefore we should not rely on such an API being available. (For the doc() and document() functions, it's pretty much essential to provide such an API, because there's no other way of controlling the decision.) I think it would do no harm for all tests that assume xsl:source-document will perform strict validation to be explicit about it by using the xsl:source-document/@validation attribute.
Comment 2 Botond Biró 2017-07-17 11:23:53 UTC
Thanks for the clarification!
It wasn't immediately obvious that in this case the default value from @input-type-annotations would take precedence over the default value of @validation(="strip").
What confused me was the second part of - 25.4 Validation §5:
"The [xsl:]default-validation attribute has no effect on the xsl:source-document and xsl:merge-source elements, which perform no validation unless explicitly requested." 

Probably just missed the history of (@strip-)@input-type-annotations and resolution of the bug 29793 - as from the test context it can be taken the validation for this file to be explicitly requested.

I like your suggestion for test interoperability with the explicit @input-type-annotations="preserve" or @validation

cheers,
Botond
Comment 3 Michael Kay 2018-01-15 16:41:47 UTC
I've stumbled across this one again while writing a new test driver.

I'm not sure now that my comment #1 is entirely accurate. 

I think type annotations are stripped only if some module in the stylesheet specifies input-type-annotations="strip" and the others specify either "strip" or "unspecified" (or are absent).

I think that the effect of xsl:source-document/@validation combined with input-type-annotations is as follows:

validation        Input-type-annotations
                     = preserve               = strip

strict/lax        Perform validation,         Perform validation, 
                  keep type annotations       drop type annotations

preserve/strip    No validation               No validation

Test cases such as streamable-015 are requesting validation implicitly in the test metadata. I don't think there's anything in the spec of xsl:source-document that suggests this should be possible. I therefore propose to add an explicit validation="strict" to the xsl:source-document instruction of such tests
Comment 4 Abel Braaksma 2019-02-26 00:36:32 UTC
(In reply to Michael Kay from comment #1)
> The meaning of "unspecified" appears to be unspecified (!).

(In reply to Michael Kay from comment #3)
> I think type annotations are stripped only if some module in the stylesheet
> specifies input-type-annotations="strip" and the others specify either
> "strip" or "unspecified" (or are absent).

This omission in the spec has now been addressed in a proposed erratum, see HTML version online: https://htmlpreview.github.io/?https://github.com/w3c/qtspecs/blob/master/errata/xslt-30/html/xslt-30-errata.html#E43 (or bug #30383).

(In reply to Michael Kay from comment #3)
> I therefore propose to add an explicit validation="strict" to the 
> xsl:source-document instruction of such tests

I see that that this change was applied. Unless someone objects (please reopen in that case), I think we can close this bug as resolved.
Comment 5 Abel Braaksma 2019-02-26 00:38:14 UTC
*** Bug 30218 has been marked as a duplicate of this bug. ***