I support the motion.
It would also be nice to be able to store the result of the
transformation in a file, if it is not meant to be used in pick or to
be pasted as xml.
Alain Pierrot
APSED
Le 5 janv. 07 ? 12:50, Hussein Shafie a ?crit :
> 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]/criterion
>> [...@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.
>
>
> --
> XMLmind XML Editor Support List
> xmleditor-support at xmlmind.com
> http://www.xmlmind.com/mailman/listinfo/xmleditor-support
> ----------------------------------------------------------------------
> -----------------
> Orange vous informe que cet e-mail a ete controle par l'anti-virus
> mail.
> Aucun virus connu a ce jour par nos services n'a ete detecte.
>
>
>
