John L. Clark wrote:
>
> Alright, I'm going to discuss the benefits and weaknesses (as I see
> them) of each implementation approach here, for the sake of
> completeness. These points should be rather straightforward.
>
> First, wrapping the siblings in a clipboard element very clearly marks
> them as the ones selected, and cuts down on wasted content passed to the
> XSLT script. It has the additional advantage that it takes advantage of
> preexisting mechanisms within XXE, and will enable transparent
> processing to and from the clipboard. The major disadvantage in my mind
> is that it automatically limits the transparent portability of XSLT
> scripts when performing processing in multiple environments (although,
> granted, performing processing on "selected siblings" only really makes
> sense in an interactive editor context).
>
> The other option, returning an XPath expression describing selected
> nodes, might be useful in other contexts besides performing XSL
> transforms. Also, this approach allows portable, parameterized XSLT
> scripts to be developed (see similar comment above). To its detriment,
> this approach would likely require more engineering, although it seems
> that XXE does have an ability to identify single nodes using XPath (for
> example, see the output when XXE describes warnings or errors in XSLT
> processing). Also, it can be problematic if the siblings are children
> of the root node, as transforms starting with the root node cannot be
> directly substituted back into XXE.
>
> In summary, I think each approach has benefits and problems; I just
> wanted to make sure all the information was out in the open. I'm very
> glad this functionality will be included in the next release.
Well, it is a bit too late for a discussion because this feature has
already been implemented.
Here's how it works (forget what I've said in my previous email because
we have implemented something totally different).
When the user selects several sibling nodes in XXE, <copyDocument
selection="true"> will save the parent element of these nodes *but will
add a processing-instruction specifying which nodes have been selected
by the user*.
Example (say the paragraphs with content 2, 3, and 4 are selected):
---
<div>
<?select-child-nodes 3-5?>
<p>1</p>
<p>2</p>
<p>3</p>
<p>4</p>
</div>
---
(3-5 is a node range intended to be tested using position(), the XPath
built-in function)
If you add the following snippet to your XSLT style sheet, you'll be
able to detect multi-node selection and process it properly.
---
<xsl:template
match="/*[./processing-instruction('select-child-nodes')]">
<xsl:variable name="pi"
select="./processing-instruction('select-child-nodes')" />
<xsl:variable name="first" select="substring-before($pi, '-')" />
<xsl:variable name="last" select="substring-after($pi, '-')" />
<c:clipboard
xmlns:c="http://www.xmlmind.com/xmleditor/namespace/clipboard";>
<xsl:for-each select="child::node()[position() >= $first and
position() <= $last]">
<xsl:apply-templates select="." />
</xsl:for-each>
</c:clipboard>
</xsl:template>
---
Note that:
* The above XSLT snippet is generic and will work for any XSLT style
sheet used by interactive XXE process commands.
* The above <xsl:template> is ignored by the XSLT engine when the user
selects a single element.
I think this implementation is conceptually clean, even if it uses an
XXE-specific processing-instruction. It is in fact close to the solution
you have suggested.
I hope you'll not find unacceptable drawbacks with it.
>
> Will there be a "Clear Cache" button for style sheet caching as there is
> for the DTD/Schema cache? Regardless, this should not be a problem;
> there are always considerations that must be made when developing a
> product or extension.
No, but by default, XSLT style sheets will not be cached.
