The effect on sequences containing whitespace text nodes, was: RE: [Bug 29692] xsl:strip-space and packages

Taking this discussion first offline, to prevent cluttering the bug entry too much, and with the intent to gather some more understanding of the issue.

I'm curious about stripping spaces/annotations from input sequences when these sequences are the initial match selection. It is my understanding that stripping spaces only applies to elements. 

Then you proposed the following:
> <quote>
> If the stripping process strips a whitespace text node that is present in the
> sequence provided as the initial match selection, or in the sequence that
> forms the result of the collection function, then the relevant node is
> removed from this sequence.
> </quote>

This seems to suggest that "the node is removed from the sequence". I don't see how that can happen.

1) if the sequence contains a whitespace-only text node, the NameTest will never match against this node
2) if the sequence contains a document node containing a whitespace-only text node child, the NameTest will never match against this node
3) the text seems to suggest that if any ws-only text node (however deep) is removed from a node in the supplied sequence, the whole node is removed

Proposal:
Remove this part, I don't think it can happen in practice (or can it?) and it may be confusing to readers. Or replace it with something like:

<quote>
Note:
If the sequence provided as the initial match selection contains items that are single whitespace text nodes, these nodes are not affected by this process. Document nodes that contain a single whitespace text node child will not be stripped either. This is a consequence of the mapping process: a NameTest can never match a single text node or the document node. Furthermore, stripping space or annotations only applies to elements.
</quote>

Unless of course we want to give users freedom to remove text-nodes in a supplied sequence if such text-nodes are whitespace-only. But then we should change the requirement of NameTest and make it a NodeTest.

Cheers,
Abel


> -----Original Message-----
> From: bugzilla@jessica.w3.org [mailto:bugzilla@jessica.w3.org]
> Sent: Friday, June 24, 2016 4:04 PM
> To: public-qt-comments@w3.org
> Subject: [Bug 29692] xsl:strip-space and packages
> 
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=29692
> 
> --- Comment #5 from Michael Kay <mike@saxonica.com> --- I propose the
> following changes:
> 
> 1. Merge sections 4.4 and 4.5 into a single section (4.4 Preprocessing Source
> Documents) with the current sections as subsections, and put shared
> material in the introduction to this new section. Specifically:
> 
> <quote>
> Source documents supplied as input to a transformation may be subject to
> preprocessing. Two kinds of preprocessing are defined: stripping of type
> annotations (see 4.4.1), and stripping of whitespace text nodes (see 4.4.2).
> 
> Stripping of type annotations happens before stripping of whitespace text
> nodes.
> 
> The source documents to which this applies are as follows:
> 
> * The document containing the global context item if it is a node
> 
> * Any documents containing nodes present in the initial match selection
> 
> * Any document containing a node that is returned by the functions
> document, docFO30, or collectionFO30
> 
> * Any document read using xsl:stream.
> 
> Note: this list excludes documents passed as the values of stylesheet
> parameters or parameters of the initial template or function, trees created
> by functions such as parse-xmlFO30, parse-xml-fragment, analyze-
> stringFO30, or json-to-xml, and values returned from extension functions.
> 
> If a node other than a document node is supplied (for example as the global
> context item), then the preprocessing is applied to the entire document
> containing that node. If several nodes within the same document are
> supplied (for example as nodes in the initial match selection, or as nodes
> returned by the collection function), then the preprocessing is only applied
> to that document once.
> 
> The rules determining whether or not stripping of annotations and/or
> whitespace happens are defined at the level of a package. Declarations
> within a library package only affect the handling of documents loaded using a
> call on the document, docFO30, or collectionFO30 functions or an evaluation
> of an xsl:stream instruction appearing lexically within the same package.
> Declarations within the top-level package also affect the processing of the
> global context item and the initial match selection.
> 
> The semantics of the doc, document, and collection functions are formally
> defined in terms of mappings from URIs to document nodes maintained
> within the dynamic context. The effect of the declarations that control
> stripping of type annotations and whitespace is therefore to modify this
> mapping (so it now maps the URI to a stripped document). The modification
> applies to the dynamic context for calls to these function appearing within a
> particular package; each package therefore has a different set of mappings.
> This means that when two calls to the doc function appear in different
> packages, specifying the same absolute URI, then in general different
> documents are returned. An implementation MAY return the same
> document if it is able to determine that the effect of the annotation and
> whitespace stripping rules in both packages is the same.
> 
> The effect of dynamic calls to the doc, document, and collection functions is
> defined in the same way as for other functions with dependencies on the
> dynamic context. As described in 5.3.4, named function references (such as
> doc#1) and calls on function-lookupFO30 (for example, function-
> lookup("doc", 1)) are defined to retain the XPath static and dynamic context
> at the point of invocation as part of the closure of the resulting function item,
> and to use this preserved context when a dynamic function call is
> subsequently made using the function item.
> 
> </quote>
> 
> 2. In 4.4, delete this paragraph:
> 
> <quote>
> The source trees to which this applies are the same as those affected by
> xsl:strip-space and xsl:preserve-space: see 4.5 Stripping Whitespace from a
> Source Tree. As with whitespace stripping, the rules for stripping of type
> annotations may vary from one package to another, and have the effect of
> modifying the mapping from URIs to document nodes defined in the XPath
> dynamic context; this means that two calls to the docFO30 function (for
> example) supplying the same URI may produce different document nodes if
> the calls appear in different packages.
> </quote>
> 
> 3. Inn 4.5, delete the following paragraphs:
> 
> <quote>
> 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 xsl:stream. It does not include documents passed as the values of
> stylesheet parameters or parameters of the initial template or function,
> trees created by functions such as parse-xmlFO30, parse-xml-fragment,
> analyze-stringFO30, or json-to-xml, nor values returned from extension
> functions.
> 
> Each source tree is associated with a package: the relevant package for the
> global context item is the top-level package; the relevant package for a call
> on document, docFO30, or collectionFO30; is the package in which that call
> appears; and the relevant package for evaluation of xsl:stream is the package
> in which that instruction appears.
> </quote>
> 
> Change the following paragraph:
> <quote>
> Formally, the stripping process modifies the mapping from URIs to document
> nodes defined in the XPath dynamic context. This mapping can therefore
> vary from one package to another. The mapping that applies to a particular
> call on document, docFO30, or collectionFO30, or a particular evaluation of
> xsl:stream, is affected by the xsl:strip-space and xsl:preserve-space
> declarations within the package in which that construct appears. This means
> that two calls on the
> docFO30 function (for example) may return different nodes if the calls
> appear in different packages.
> </quote>
> 
> to
> <quote>
> The stripping process that applies for a particular package is determined by
> the xsl:strip-space and xsl:preserve-space declarations within that package.
> </quote>
> 
> After
> <quote>
> The xml:space attributes are not removed from the tree.
> </quote>
> 
> add:
> <quote>
> If the stripping process strips a whitespace text node that is present in the
> sequence provided as the initial match selection, or in the sequence that
> forms the result of the collection function, then the relevant node is
> removed from this sequence.
> </quote>
> 
> Delete the following paragraph:
> <quote>
> The effect of xsl:strip-space and xsl:preserve-space is local to the package in
> which they appear. Declarations within a library package only affect the
> handling of documents loaded using a call on the document, docFO30, or
> collectionFO30 functions or an evaluation of an xsl:stream instruction
> appearing lexically within the same package. Declarations within the top-level
> package also affect the processing of the main input document.
> </quote>
> 
> --
> You are receiving this mail because:
> You are the QA Contact for the bug.

Received on Friday, 24 June 2016 17:02:14 UTC