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.


Reply via email to