On Fri, Feb 06, 2004 at 10:45:48AM +0100, Hussein Shafie wrote:
> >>creates __doc.xml containing all the selected nodes wrapped in a parent
> >>``envelope element'' (using a fixed, documented, qualified name
> >>belonging to the XXE clipboard namespace).
> >This would be another neat way to accomplish this end, and I thought of
> >suggesting this instead of my initial suggestion. It seems to me that
> >both approaches have interesting characteristics, which we can discuss
> >in a bit more detail if you would like. I would agree that the method
> >you suggest would be perfectly functional in this regard.
>
> OK, you'll have this enhancement in next release.
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. Thank
you, and again for a great XML environment!
> We'll try to implement XSLT style sheet caching for interactive
> commands in next release.
Outstanding, that'll be extremely pleasant to have.
> Note that this means that you'll have to remember removing the cache
> attribute or setting it to false when you are in the process of
> writing your custom XSLT style sheet.
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.
Take care,
John L. Clark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://www.xmlmind.com/pipermail/xmleditor-support/attachments/20040209/341f6670/attachment.sig
