John L. Clark wrote: > There are several small enhancements to the XXE interface and one large > functionality enhancement that I would like to propose here. > > The first idea is one of a configurable document identifying string. > For the purposes of the suggestions here it need not in any way be > unique; rather, it would exist for the user's benefit. 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. > I would suggest that there be a new configuration element, > <cfg:identification source="xpath"/>, which would set a document's > identification string to the string value of the first node in the node > set identified by xpath expression "xpath". Given this, for example, I > would quickly set source="//title" for both DocBook and XHTML. An > additional use for this identification string might be as a default > filename for new files when saved, as opposed to "Untitled". If the > idenfication element is omitted in a particular configuration, XXE could > easily fall back to its current behavior. 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. > 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. I was initially told that this is not possible, which makes > sense because XXE needs to be able to pass a well formed XML segment to > an XSLT processor. What I would ask for, then, is an ability to select > and submit the parent of these siblings for processing (like > ancestorOrSelf but more like singleOrParent), but which would all one to > pass a parameter to the XSLT script which consists of an xpath > expression that evaluates to a node set which is exactly the "originally > selected" siblings. Mind you, generating this xpath expression might be > difficult, but my initial hypothesis is that it would not be. > > An example might help illustrate this second request. Take, for > example, the following XHTML fragment: > > <div> <p>1</p> <p>2</p> <p>3</p> <p>4</p> </div> > > Say the paragraphs with content 2, 3, and 4 are selected. My proposed > extention would allow you to <cfg:command name="selectNode" > parameter="singleOrParent"/> which would actually return as its value > the xpath expression defined above, in this case "/div/p[position() >= 2 > and position() <= 4]" (and there may be a simpler equivalent expression; > it is simply the resulting node set that is important). This would > enable you to, for instance, iterate on that node set within your XSLT > script and modify only those "selected" nodes, for one possible result > of: > > <div> <p>1</p> <p><em>2</em></p> <p><em>3</em></p> <p><em>4</em></p> > </div> > > I haven't fully thought about the different extentions that might be > possible and similar to this, but others may exist. What about this which is much simpler to implement: if multiple sibling nodes are selected, --- <process> . . . <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). Example (space added to make example more readable): --- <?xml version="1.0"?> <ns:clipboard xmlns:ns="http://www.xmlmind.com/xmleditor/namespace/clipboard";> <p>2</p> <p>3</p> <p>4</p> </ns:clipboard> --- 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. --- 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>. Currently <transform> does not cache precompiled XSLT style sheets. This is one of the reasons of this slowness. Don't you need an attribute which could be used to instruct <transform> to cache the XSLT style sheets you use in interactive commands?
