Re: Content constructors and sequences

David,

>> I don't like the fragility of adding/removing a type attribute
>> having such a big impact on how the variable-binding element is
>
> agreed.
> An alternative would be to say that xsl:item worked in xsl:variable
> a similar way to xsl:attribute in an element:
>
> Namely that any number or xsl:item's are allowed but none are
> allowed once any part of the sequence has been constructed without
> using xsl:item. then, one could say that if xsl:variable has
> constructed a sequence of xsl:item's then the result is a sequence
> consisting of the item values. Otherwise it's a sequence consisting
> just of a document node, the document node having content the
> constructed sequence from xsl:variable.

Putting it another way, sequence constructors can either construct
sequences holding a number of documentless nodes, or a sequence
containing any kind of items. It's a dynamic error if the result
sequence contains documentless nodes and either simple typed values or
pre-existing nodes.

If the sequence constructor for the variable produces a sequence of
documentless nodes, then the variable is set to a new document node
with these nodes as children. Otherwise, the variable is set to the
result sequence.

That would certainly simplify things with the variables, and it would
get around the problems involved in dealing with a mix of different
kinds of items in sequences used to construct result trees.

The only difficulty that I can see with it is what happens if you
have:

  <xsl:variable name="foo">
    <xsl:choose>
      <xsl:when test="not(bar)">
        <bar />
      </xsl:when>
      <xsl:otherwise>
        <xsl:item select="bar" />
      </xsl:otherwise>
    </xsl:choose>
  </xsl:variable>

Here, $foo will either be set to a sequence containing a document node
with a bar element child, or to a sequence containing the existing bar
element child of the current node. I think that's confusing.


Another possibility, again using the type attribute but this time a
bit less fragile, would be to use the type attribute to indicate how
the processor should deal with the sequence. This would require that
you could specify the data type of "document node", but I doubt that's
a major issue.

When the variable is set via its content, the sequence constructor it
contains produces a result sequence.

If the type attribute is missing *or* if the type attribute has the
value "document node" (no occurrence indicator) then, unless the
result sequence is a singleton containing a single document node, the
variable is set to a new document node with the result sequence as
children (which might generate errors). Otherwise, the variable is set
to the result sequence (which again might involve errors if the type
doesn't match the sequence).

I think this is more robust because the correct value for the type
attribute in the case you're generating a document node is, of course,
"document node". If you set it to something else, and then treat it as
a document node, you shouldn't be surprised if you get errors.

>> Namespaces are fairly free-floating, I think (they don't belong to
>> a document).
>
> but you need to put them _somewhere_ if you generate an attribute
> node that has name being a Qname involving a prefix then really you
> need to have some method of reaching some namespace node which maps
> that prefix to a namespace (well you don't have to have but things
> gettricky otherwise) in xslt1 you can always go to the parent
> element and then find such a namespace node in the namespace axis.
> If the attribute node is off on its own it isn't so clear what to
> do.

Hmm, good point.

I see three possibilities:

First, you could just not worry about it. An attribute's name is a
xs:QName, which incorporates the namespace URI so there's no problem
getting that namespace URI. If an attribute's typed value is a
xs:QName or a list of xs:QNames (which it should be if the values have
are qualified names), then each of those xs:QName values must have its
own namespace URI accessible as well. So an attribute doesn't need
namespace nodes. (Possibly - can you think of some examples where you
need to access a namespace node given you have access to a QName?)

Second, you could make the presence of documentless attribute nodes in
sequences assigned to variables a dynamic error (and you might want to
do the same for documentless namespace nodes). That would force people
to use element node 'holders' for them instead.

Third, you could change the data model so that the namespaces
accessor on attribute nodes returned a sequence of in-scope namespaces
for that attribute. That would be a departure from the XML Infoset,
though.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list