Re: Re: XSLT 2.0: On xsl:sequence and xsl:copy-of
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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format