W3C home > Mailing lists > Public > public-qt-comments@w3.org > June 2016

[Bug 29692] xsl:strip-space and packages

From: <bugzilla@jessica.w3.org>
Date: Sun, 12 Jun 2016 11:39:52 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29692-523-Mz7pm5uCIS@http.www.w3.org/Bugs/Public/>

Abel Braaksma <abel.braaksma@xs4all.nl> changed:

           What    |Removed                     |Added
                 CC|                            |abel.braaksma@xs4all.nl

--- Comment #3 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
(In reply to Michael Kay from comment #0)
>  (which I thought we had discussed and agreed) 
In Bug 23326 we say we resolved this by saying that xsl:strip-space and type
annotations are applicable to xsl:stream as well, and only apply to the
relevant package. I did not find a change log entry in the current draft, maybe
it was overlooked and never applied.

In Bug 22663 we concluded (on differences caused by separate compilation, and
the effect of the use of doc() in the static context):

Bug 22663 comment #2
"It was noted that we could require the calls on doc() in different static
contexts to return results that effectively mean the document must only be read
once and then have space stripping applied (ie. disallowing reading a version
of the document that has changed in the interim)"

Then, on the dynamic context we said:

Bug 22663 comment #3
"We should say that the dynamic context for the doc() function depends on which
package the call is contained in, and the mapping from URIs to document nodes
is therefore different for different packages. We could say that these mappings
are permitted to vary ONLY by applying the strip-space and strip-annotations as
modifications to some base mapping which must be common across packages; but
it's simpler to say nothing, which essentially means that implementations have
freedom to allow the mapping in different packages to be completely independent
(one resolver/catalog per package) or not, as they see fit."

Effectively: the intend was to leave it to the implementation by saying
(almost) nothing. 

(In reply to Michael Kay from comment #2)
> In fact generally we don't say anything much about stripping of input 
> nodes other than document nodes

I didn't find former discussion on anything other than document nodes. But we
do say in the spec that it applies to any node (but notice the ambiguity in the

Section 4.5:
"For the purposes of this section, the term source tree means the document
containing the global context item if it is a node, any documents containing
nodes present in the initial match selection, any document returned by the
functions document, docFO30, or collectionFO30, and any document read using

I read this as: the global context item (which can only be accessed in the
principal package) may be something else than a document. The initial match
selection *must* be a document for it to apply.

Furthermore, the text on xsl:strip-space suggests it only applies to elements,
so a document with a whitespace node child is not effected.

This quote above also suggests that they do apply to all of doc, collection,
document and xsl:stream.


Bottom line: I think all the rules are there, albeit hard to disentangle. We
could be more explicit about it. We could also allow stripping of non-document
nodes. Or explicitly state it is disallowed, for clarity reasons.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Sunday, 12 June 2016 11:39:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:58:00 UTC