Kevin Flynn wrote:
>
> Thanks for the suggestion, but I'm afraid my problem is rather more
> complicated than that, and I'm certain that it cannot be solved using
> standard CSS.
OK.
> The root "mode" attribute is a kind of shorthand that can
> define the settings of several conditions. Mode="normal" might, for example,
> mean os="linux", customer="Microsoft", version="3.0". There is a lot of
> indirection involved. If the "matches" function I dreamed up were
> implemented, this is how I believe I would need to use it:
>
> E:matches("contains(concat(' ', at value,' '),concat('
> ',/root/local-config/filters/filt...@id=/root/@mode]/criteri...@selector=cur
> rent()/@selector]/@value,' '))"){
> background-color: #ffe4c4;
> }
>
> The E element has two attributes of interest, which might be set as follows:
>
> selector="os" value="linux mac"
>
> meaning that the contents of the element are relevant for both linux and mac
> OSes.
>
> The local-config element referenced in the xpath expression is included in
> documents as an external entity and contains configuration data (including
> filter definitions) for all the documents in a particular project.
>
> A filter defines a set of selection criteria:
>
> <filter id="normal">
> <criterion selector="os" value="linux"/>
> <criterion selector="customer" value="Microsoft"/>
> <criterion selector="version" value="3.0"/>
> </filter>
>
> and the /root/@mode attribute must contain the name of one of these filters
> if it is set.
>
> Selectors and their possible values are defined elsewhere in the config
> file.
>
> This probably seems like a very convoluted structure, but it makes it
> relatively easy and SAFE to produce many variants of a single document.
> Since all filter names, selector names and values are predefined as IDs in
> the local-config file, it's easy to prevent the writer making mistakes.
>
> As I said earlier, the "matches" idea is just a bit of "wishful thinking",
> and a "transform" function would be a perfectly adequate solution for me. If
> you should decide not to implement that, then I will have to find some other
> solution myself...
E:matches() selectors are not hard to implement but they are (1)
non-standard, (2) potentially very slow. That's why we are very
reluctant to implement such beast.
Morever, a CSS style sheet extension (written in Java[tm]) may probably
be used to solve this kind of problem. See
http://www.xmlmind.com/xmleditor/_distrib/doc/dev/styleext.html
> ... and it looks as though Alain Pierrot may have provided me with a means
> of doing that, so thanks very much to him.
>
> It would be nice to know if you intend to implement a "transform" command,
We could implement it in next version if there is sufficient interest.
> and if so, what it will look like.
Like a number of other commands, the "transform" command is only useful
for writing macros.
Using the XSLT style sheet passed as a parameter, the "transform"
command transforms part or all of the document being edited (explicit
selection, implicit selection, whole document, depending on a
parameter) to an output stream (XML, HTML, plain text).
This output stream is ``loaded as a string'' and returned as the result
of the "transform" command.
If this result is the string representation of an XML tree, it could be
directly used by a subsequent "paste" command.
If this result is a plain text list of items, it could be directly used
by a subsequent "pick" command.
The parameters of the "transform" command are:
* The URL of the XSLT style sheet. (The "%c" variable will be made
available in order to resolve URLs relative to the configuration
containing the macro invoking the transform command.)
* Optional parameters for this XSLT style sheet.
* What is to be transformed (explicit selection, implicit selection,
whole document; default: explicit selection).
* The encoding of the output stream (default: UTF-8).
The "transform" command should be much more efficient than a process
command, even when the XSLT style sheet of the process command is cached
and when there is no user feedback during the execution of the process
command.