Cart
[Home] [By Thread] [By Date] [Recent Entries]
Henry Thompson writes: Richard Light <richard@l...> writes: > 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> > > . . . > > 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.) You're right, in XSL as currently proposed you can't do that, but it is consistent with the existing (but unimplemented) part of the DSSSL model of construction rules via the 'query' construction rule, so not out of the question in principle. The more XSL allows us to call scripts at _any_ stage of the process, the better. Most of the action of delivering XML documents over the web will take place when you apply the style rules to the text. Many of the things our clients are asking us to do with style rules, such as applying formatting or triggering browser behavior based on combinations of document context and conditions outside of the document (who is the user? which option did she select two pages back? is the pump running hot right now?) require pretty serious use of scripts to fire external queries and set/get memory variables.* To the extent that XSL contains non-critical restrictions on when we can make those calls and what we can do with them, I'd like to see those restrictions removed. *(Though an alternative to maintaining traditional memory variables could be to manipulate attributes of the parsed tree, provided that the scripts were allowed to get at it... style rules manipulating the DOM... there's food for thought.) Btw, any chance of removing the requirement that we must use ECMAScript as the first layer we shell out to? I'm not clear what the standard gains by this. I'd rather see a mechanism by which we declare what language we're shelling out to, like declaring an encoding, or perhaps some form of standardized API. (I'm new to this thicket of standardization issues so don't want to push specific suggestions too hard; just looking for less restrictive options than always using ECMAScript.) Regards, Tony Stewart RivCom "Publishing Structured Information" tony.stewart@r... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
