>>>>Can any knowledgeable people help me clarify the followings:
>>>>
>>>>1. Does XSL supports either the above 2 scenarios (i.e. condition in
>>action
>>>>rules or processing descendants in scripts). I may overlook something.
>>>>
>>>>2. If neither of above is available in XSL, what are the good work around?
>>>>Will my 'hacking' work?
I don't know if a knowledgeable person can help, but meanwhile I'll have
a go ...
The conditions for XSL are set by the structure that you specify, e.g.:
<element type="object">
<target-element>
<attribute name="REND" has-value="yes"/>
</target-element>
</element>
defines the target elements for a rule as being those elements which are
children of an "object" element, and which have a value set for their
"REND" attribute. If the condition matches for an element, the rule
fires. This is a pretty powerful mechanism, although it doesn't do the
'else' case you mention - that has to be another rule (perhaps a more
general rule - only the most 'specific' rule (3.2.6) applies to each
element).
I'm not sure about the ability to invoke a bit of script when testing
the attribute value. The XSL spec allows you to invoke ECMAscript when
_setting_ attribute values on (output) flow objects - there is no reason
at all why it couldn't allow the same feature when _testing_ attribute
values on source elements. (Obviously in this case the script would
have to return true/false rather than a string.)
When trying out a bit of code to show how easy this all is, I couldn't
get MSXSL to take any notice of an <attribute> statement inside a
<target-element> as per the above example. But I think it should have
done!
One point is that the spec uses both 'name="XXX"' and 'type="XXX"' to
qualify <attribute> in its examples in 3.2.3. I think, though, that the
'type="XXX"' is an error. (Neither worked with MSXSL.)
Any more knowledgeable people out there?
Richard.
Richard Light
SGML/XML and Museum Information Consultancy
richard@light.demon.co.uk