Re: [xsl] Content constructors and sequences

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