RE: characters in xsl

    -----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? [expletive deleted] 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