- From: <bugzilla@jessica.w3.org>
- Date: Wed, 30 Sep 2015 08:04:07 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29162 Bug ID: 29162 Summary: [xslt30] Parameter-document: static or dynamic? Product: XPath / XQuery / XSLT Version: Last Call drafts Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: XSLT 3.0 Assignee: mike@saxonica.com Reporter: mike@saxonica.com QA Contact: public-qt-comments@w3.org Target Milestone: --- xsl:output and xsl:result-document have an attribute parameter-document which is the URI of a file containing serialization parameters. In the case of xsl:result-document, the attribute is an AVT, so there is a clear implication that we don't know the URI until run-time and therefore we don't read the parameter document until run-time. For xsl:output the attribute is known statically, but we don't give any indication of whether we expect the parameter document to be read at compile time or at run-time. If we leave this question open, we create a potential interoperability problem, especially in the context of distributable packages (this also affects the location of the parameter file). For some reason I don't fully understand, we always resisted making the serialisation attributes on xsl:output dynamic (AVTs). Is the introduction of parameter documents supposed to circumvent that restriction? In keeping with the current status of serialization properties, I'm inclined to say that we add the rules: * For xsl:output, processors should read the supplied parameter file during static analysis of the stylesheet; subsequent changes to the content of the file should have no effect. * For xsl:result-document, processors should read the supplied parameter document during the evaluation of the xsl:result-document instruction. If the same parameter file (that is, the same absolute URI) is used in the course of repeated evaluation of one or more xsl:result-document instructions, it is implementation-dependent whether any changes to the content of the file after the first use have any effect. (Alternative resolution: scrap the feature. We currently have no tests, it delivers very little benefit, and it's complexity we can do without.) -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 30 September 2015 08:04:11 UTC