Hi Dave,

>> Yes, or at least partly. If you have an 'as' attribute on
>> <xsl:variable> then it indicates the static type of the variable,
>> but the variable itself can be of a more specific type.
>> 
> Roughly (not using DC speak), the 'as' attribute is the one I want,
> even if the contents (of xsl:variable in this example) might vary?

I can't tell what you *want* because I don't know what you want to do.
If you want to declare the type of the variable, or if you want to use
the content of the <xsl:variable> instruction to set the variable to
something that isn't a temporary tree, then the 'as' attribute is what
you want.

The 'as' attribute sets limits on what the content or select attribute
of the <xsl:variable> must evaluate to, but as long as evaluating the
content (or select attribute) is within those limits, it can vary.

>> Similarly, if you have:
>> 
>>   <xsl:variable name="foo" as="xs:decimal" select="2" />
>> 
>> then the static type is a xs:decimal but the type of the variable's
>> value is a xs:integer.
>
> ?? Dynamic is integer, static is decimal??

Yes. The value returned from evaluating the XPath expression "2" is an
xs:integer with the value 2. The 'as' attribute of the <xsl:variable>
element says that the type of the variable is a xs:decimal. So the
static type is xs:decimal, the dynamic type is xs:integer.

> Assuming such a cast is viable/allowed, any use of $foo will be as a
> decimal thereafter in the stylesheet?

The value of the variable is an xs:integer, and it will remain so: the
xs:integer isn't cast to a xs:decimal because an xs:integer can always
be used where a xs:decimal is expected because xs:integer is a subtype
of xs:decimal.

>> As long as the dynamic type (the type of the value that the
>> variable gets set to) is a subset of the static type (the type of
>> the variable as declared by the 'as' attribute), you're OK.
>
> 'Can be cast to' I guess.

Well, "matches" would be the correct terminology, I guess. I should
rephrase to:

  "As long as the value the variable gets set to matches the static
   type, you're OK."

Whether a value "matches" a particular SequenceType is determined
according to the rules in XPath 2.0 at:

  http://www.w3.org/TR/xpath20/#id-sequencetype-matching

"Can be cast to" isn't the correct terminology because the only
casting that's supported in XPath is the casting of a single atomic
value to a different atomic type. So for example "a sequence of three
elements" can't be "cast to" the SequenceType "element()+", but it
*matches* the SequenceType "element()+".

>> The SequenceType syntax is specified in the XPath 2.0 spec at:
>> 
>>   http://www.w3.org/TR/xpath20/#id-sequencetype
>> 
>> It's impossible to give a complete list of sequence types
>
> Is there a difference (to a user) between sequence types and data
> types?

The term "data type" is usually used to refer to atomic data types
such as xs:decimal, xs:date and so on. A "sequence type" refers to the
type of a sequence, such as "one or more elements". So yes, there is a
meaningful difference.

>> However, to summarize, a SequenceType can be:
>> 
>>   - "empty()"
>>   - an item type with an occurrence indicator; item types are:
>>     - "item()"
>>     - a node kind test, which are:
>>       - "node()"
>>       - a document node test, which can be:
>>         - "document()"
>>         - "document(element())"
>>         - "document(element(Name))"
>>         - "document(element(Name, *))"
>>         - "document(element(Name, Type))"
>>         - "document(element(*, Type))"
>>         - "document(element(SchemaPath))"
>
> What does the 'nth level' mean please Jeni?
> Its a node (most generic)
>   Its a document (less generic)
>      Its an element (even less generic)
>         ????

I was trying to group the possible sequence types for explanatory
purposes, simply to make the list easier to understand. If you'd
prefer a flat list, just look at the things in quotes.

>> For a full list of the built-in atomic data types, look in the F&O
>> spec at:
>> 
>>   http://www.w3.org/TR/xpath-functions/#datatypes
>> 
>> and:
>> 
>>   http://www.w3.org/TR/xpath-functions/#duration-subtypes
>
> The less said about this bunch, the better IMO.
> I'm hoping that the request to castr... reduce to a minimum will be
> supported in the WG :-)

In basic XSLT processors, we might well only require support for
atomic values with a subset of the data types, probably:

  - xs:string
  - xs:boolean
  - xs:decimal
  - xs:integer
  - xs:double
  - xs:date
  - xs:time
  - xs:dateTime
  - xs:QName
  - xs:anyURI
  - xdt:dayTimeDuration
  - xdt:yearMonthDuration
  - xdt:untypedAtomic

When declaring the type of a variable (i.e. in a SequenceType), you
will also be able to refer to the more general type xdt:anyAtomicType.

If you're using a full schema-aware XSLT processor, then you'll be
able to use all the built-in types from XML Schema and XPath 2.0, as
well as the ones that you import from a schema yourself.

>> There's certainly more to learn in XSLT 2.0 than there was in XSLT
>> 1.0, which isn't surprising considering that it can do that much
>> more.
>
> I'd argue over how much more. I'm less convinced the baggage is a
> fair weight to carry when getting the useful subset of the 'more'
> that's provided.

As you may know, I am likewise unconvinced:

  http://www.mulberrytech.com/Extreme/Proceedings/html/2003/Tennison01/EML2003Tennison01.html

Cheers,

Jeni

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


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