[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: A beef with XSLT Sometimes too complicated
David Carlisle <davidc@xxxxxxxxx> writes: >> They have 2 different specs and one can exist independently of the >> other > > xpath can exist without xslt but not the other way round. The situation > is (exactly) the same in XQuery, but XQuery is usually regarted as an > extension of XPath: that is XQuery is a single language, with more > constructs than XPath) whereas XSLT is usually described is a > two-language construct consisting of xslt constructs and Xpath > constructs. It's pretty much a marketing angle which way you describe it > really. Although on the surface the XQuery spec doesn't defer to XPath > for the specification of the Xpath-part of XQuery but rather just includes > copies of the definitions, whereas the XSLT spec does refer to the xpath > spec, this is just an artifact of the way the stylesheets making the > public html versions of the spec are built. The XPath and XQuery > documents are built out of a common xml document base. I wouldn't mind if the only if was in xpath. In other words if there were *more* ties that bind between the two worlds: <xsl:variable name="x" select="if $var then select(@id='1') else select (@id='2')"/> <something id="1"> hello! </something> <otherthing> goodbye </otherthing> If we are to have the facilities in xpath I can't see why they can't point into the xslt structure. Ah well. I should have joined the working group (but I couldn't afford it!) -- Nic Ferrier http://www.tapsellferrier.co.uk for all your tapsell ferrier needs
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|