[Bug 30145] [xslt30ts] streamable-015 expected result assumes validation of xsl:source-document input

https://www.w3.org/Bugs/Public/show_bug.cgi?id=30145

Michael Kay <mike@saxonica.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mike@saxonica.com

--- Comment #1 from Michael Kay <mike@saxonica.com> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 14 July 2017 16:06:42 UTC