Hi again Jeni.
Thanks for your patience.
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.
Just understand it.
I'm interpreting the as attribute as specifying the datatype I want
the variable to be.
your explanation below clarifies, but surprises.
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.
... In which case the as attribute is redundant.. unless I 'invent'
content (i.e. use a literal) since I can't change the type (my 'cast' idea
above) using the as attribute.
I.e. any xsl:variable which contains source document content will
'determine its own data type' irrespective of the as attribute?
The user concern only needs to be that our 'as' type is a subtype of
the actual result?
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."
Is your 'is a subtype of' still a valid alternative Jeni?
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()+".
OK, thanks.
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.
Is this a break point between xsd and xslt+xpath?
We pull data types from XSD, then add sequence types?
However, to summarize, a SequenceType can be:
- "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.
No, it illustrates nicely the hierarchy.
I was checking my understanding of the nesting?
Is it the 'subtype' mentioned above?
E.g. you had
"a node()
"element()
"element(Name, Type)
Can I read that as element is a subtype of node,
the last line I'm less sure of.
What's the 'type' (is it one from int, decimal, string etc,
referring to the element content?)
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
It will be interesting to see just how constrained such a processor is,
if anyone does produce one.
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.
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/EML2003
Tennison01.html
Well worth a read people.
At least read the conclusion
Thanks Jeni.
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
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list