Subject: RE: [xsl] characters in xsl From: "Pawson, David" <David.Pawson@xxxxxxxxxxx> Date: Fri, 12 Nov 2004 12:27:22 -0000 |
-----Original Message----- From: David Carlisle XSLT2 (and Xquery) allow you to make and query elements in a single transform and allow sequences of elements. If you want to make a sequence <a/> <b/> <c/> you might have expected it should be <xsl:variable name="x"> <a/> <b/> <c/> </xsl:variable> Groves... no, I can't say that. 'bushes'? I think Mike Kay was right suggested they should be allowed, until you said... That's often convenient but sequences have different properties. Not sharing a parent means that they are not siblings for example. MMM. Yes, I guess the 'distantCousin' axis might be a problem :-) " match="//stone" will only match a stone element that belongs to a document tree. " Does the match just fail .... or is it an error? Suck it and see? Then recall that match="stone" works similarly (in 1.0) to //stone. It's not an error it just doesn't match. If you look back in this thread at Wendell's explanation of why //stone and stone match the same thing you'll see that it essentially depends on the fact that every element is the child of _something_ either another element or a document node. In XSLT2 that is no longer true as it gives access to intermediate results, you can query an element after it has been constructed but _before_ it has been copied into the final result tree. Such a free standing element has no parent. Perhaps WG prudishness is avoiding the obvious axis name then! <snip/> This is OK I think. It's a bit technical but you can't generate parentless elements by mistake, and you can't apply templates to them by mistake. If you know enough to do both of those things on purpose, then you'd better know not to use //foo unless you mean it. All of which leaves a nasty feeling that W3C are digging holes for the future? A clean break with xslt 1.0, and a smartish stylesheet to do most of the porting might have been a better solution. So XSLT 3.0 (if 2.0 lasts) will also be considering these oddities? Agreed its logical... but is backwards compatibility mode all that good anyway? Thanks for the explanation David. regards DaveP -- DISCLAIMER: NOTICE: The information contained in this email and any attachments is confidential and may be privileged. If you are not the intended recipient you should not use, disclose, distribute or copy any of the content of it or of any attachment; you are requested to notify the sender immediately of your receipt of the email and then to delete it and any attachments from your system. RNIB endeavours to ensure that emails and any attachments generated by its staff are free from viruses or other contaminants. However, it cannot accept any responsibility for any such which are transmitted. We therefore recommend you scan all attachments. Please note that the statements and views expressed in this email and any attachments are those of the author and do not necessarily represent those of RNIB. RNIB Registered Charity Number: 226227 Website: http://www.rnib.org.uk
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] characters in xsl, David Carlisle | Thread | Re: [xsl] characters in xsl, David Carlisle |
Re: [xsl] Test for preceding-siblin, David Carlisle | Date | Re: [xsl] characters in xsl, David Carlisle |
Month |