On Thu, Feb 05, 2004 at 01:46:10PM +0100, Hussein Shafie wrote:
> >An identifyig string, for instance, could be used in the title bar to
> >identify a document in a way somewhat more meaningful than the file
> >name of the document.
>
> Like in a web browser.
Precisely.
> What if the user changes the <title> element. Do we need to refresh the
> title bar each time a character is inserted or deleted in this element?
>
> Not that we cannot implement it or that it is difficult, we are just
> very reluctant to make XXE bigger and slower than it already is, for
> what is a (no matter how neat) refinement.
Absolutely, and I would imagine an implementation which would not be
burdensome. Were I to implement it, I would probably update the title
bar on a save event, or maybe using some more intelligent scheme, such
as after an interval of time or perhaps after the user "leaves" the
element selected to be the identification element.
> >My second suggestion relates to a desire I expressed in a previous
> >email, which is to be able to perform processing on a set of sibling
> >nodes.
> What about this which is much simpler to implement: if multiple sibling
> nodes are selected,
> <copyDocument selection="true" to="__doc.xml">
> 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).
> It would not be difficult for the XSLT style sheet to detect this case.
> Suffice to examine the qualified name of the root element of the
> document it has to process.
>
> After transforming the selected nodes, the XSLT style sheet could build
> a result tree using the same envelope in order to allow pasting the
> result back in XXE.
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.
> PS: If you use macro-commands+process-commands to *interactively*
> transform parts of the document being edited, you should be annoyed by
> the slowness of <process>/<transform>.
I don't know if I would go so far as to say "annoyed". When it comes to
wanting to achieve transformations which would otherwise be very tedious
and error prone, I am willing to sacrifice a bit of speed (and really,
not too much - XXE pops up a window, does some processing, and then
substitutes the result - doesn't take but several seconds) to achieve
computational precision (and in the end, I'm almost certain that it is
faster than doing the same thing manually). For example, one of the
requirements that my users have is to be able to "wipe" all change
information in DocBook (delete remark elements or elements with
revisionflag="deleted" and merge those with revisionflag="added" or
revisionflag="modified"), and the slight amount of wait time on this is
well worth it.
Of course, ideally this would be performed from the root (that is,
globally); thinking about this caused me to realize that being able to
process multiple siblings might be worthwhile.
> Currently <transform> does not cache precompiled XSLT style sheets. This
> is one of the reasons of this slowness.
It would be extremely exciting if it did caching like this, but I hadn't
even thought to ask for it because I knowingly and willingly pay the
cost to achieve a certain amount of functionality (described above).
> Don't you need an attribute which could be used to instruct <transform>
> to cache the XSLT style sheets you use in interactive commands?
I wouldn't mind one, but I will continue to happily use <transform>
without it.
What a great discussion this has been, I appreciate it.
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/20040206/fd591593/attachment.sig
