[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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
|