Subject: Re: [xsl] Content constructors and sequences From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx> Date: Wed, 9 Jan 2002 13:13:44 +0000 |
Hi David, >> [I don't think that people get the string values of result tree >> fragments that contain elements very often because it's rarely useful >> to create a result tree fragment with internal structure and then >> proceed to ignore that internal structure, but it does happen.] > > Actually I have stylesheets (production ones, not toy answers for > this list) that use rtf precisely to gain that effect. For some uses > you want to discard the markup in document oriented cases where > "markup" is being used as originally intended, as an annotation on > text that is usable without the markup, and I want, in some cases to > get rid of this annotation. Often it's easier to build an rtf first > as you just copy some filtered branch of a tree so get the markup as > well... Yes, I'm sure I've used it as well on occasion. The vast majority of uses of the string value of result tree fragment variables, though, I think is when you have: <xsl:variable name="foo">bar</xsl:variable> or (more justifiably): <xsl:variable name="foo"> <xsl:choose> <xsl:when test="...">bar</xsl:when> <xsl:otherwise>baz</xsl:otherwise> </xsl:choose> </xsl:variable> >> These backwards compatibility issues could be resolved by having >> the type attribute on the variable-binding element determine the >> behaviour of the variable-binding element. If the type attribute is >> not present, then the variable-binding element creates a result >> tree (as described later), and the variable is bound to a new >> document node; if the type attribute is specified, then the >> variable is bound to the sequence. > > I'm not sure what the type would be though for "sequence of whatever > gets constructed, be it nodes or values of any type". According to the XPath 2.0 WD, it's "item*". If you want to say "sequence of nodes" then you can use "node*". If you expect one or more items, you can use "item+". (The keywords "item" and "node" conflict with referring to simple data types by name, btw.) See: http://www.w3.org/TR/xpath20/#id-referring-to-datatypes > Having xsl:variable generate a root node by default does have some > advantages as well as compatibility > > <xsl:variable name="x"> > <a/> > <b/> > <c/> > <a/> > </xsl:variable> > > in xslt 1.0 you go ext:node-set($x)/a to access the a's in xslt 2.0 > current draft you go $x/a (which seems quite nice) if the above > generated a sequence then you'd have to go $x[self::a] which isn't > totally horrible but isn't as nice as $x/a. Yes, absolutely. And navigating between the siblings is even worse. See also my message in reply to Mike - you can use a wrapper element or you might suggest having a xsl:document instruction to explicitly create a document node for these cases. I don't like the fragility of adding/removing a type attribute having such a big impact on how the variable-binding element is interpreted (the same applies to a lesser extent to the separator attribute on xsl:value-of) but I can't see a way round it aside from breaking backward compatibility. > So while I do think the general direction of your proposal is > correct (allow XSLT to create constructs in the data model rather > than pushing control constructs into Xpath) Looks like you didn't finish this sentence? ;) > As for rootless nodes I think there are some problems with defining > / (and the new xpath 2 shared namespace nodes) when there is no > document (and id() and key() and any other function that has a > definition involving the "current document") but they are probably > not insurmountable. Yes. According to the XQuery/XPath data model, the parent accessor for an element (for example) can be empty, which means that I don't think / is a problem. Namespaces are fairly free-floating, I think (they don't belong to a document). On the context document front, according to the XPath 2.0 WD: "The context document is the document currently being processed. Its value is a node, which is always a document node. If there is a context node, and if the tree containing the context node has a document node as its root, then this document node will be the context document. When an inner focus is created and the context item in the inner focus is not a node, or is a node belonging to a tree whose root is not a document node, then the context document in this inner focus will be the same as the context document in the outer focus. The context document is returned by the XPath expression "/", and is used implicitly as the base for any absolute path expression, as well being used as input to certain functions such as xf:id." So I think that there isn't a problem there. Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Content constructors and , David Carlisle | Thread | Re: [xsl] Content constructors and , David Carlisle |
RE: mapping (Was: Re: [xsl] Re: . i, Joerg Pietschmann | Date | Re: Regular expression functions (W, Jeni Tennison |
Month |