RE: [xsl] Re: XSLT 2.0: On xsl:sequence and xsl:copy-of

Subject: RE: [xsl] Re: XSLT 2.0: On xsl:sequence and xsl:copy-of
From: David.Pawson@xxxxxxxxxxx
Date: Tue, 14 Oct 2003 09:15:54 +0100
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:
> "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(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:

Well worth a read people.

At least read the conclusion

Thanks Jeni.

regards DaveP


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 


 XSL-List info and archive:

Current Thread