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 12:48:06 +0100
And again <grin/>
  Im getting there, slowly.
> >> So, you *can* use the 'as' attribute to do implicit casting.
> > But only between a subtype and super of that subtype?
> No. There is never a need to cast a value from a subtype to a
> supertype, because a value of the subtype is *by*definition* a value
> of the supertype already. For example, the xs:integer 2 is a
> xs:decimal value.

OK, that's clear.

> The implicit casting is mainly used when casting from an untyped value
> (of a node) to a particular type. For example, casting the value of
> the 'dob' attribute to a xs:date. In this case, the type of the value
> of the node (xdt:untypedAtomic) is not a subtype of the type to which
> it's being cast (xs:date).

Yes, (for me at least) it was terminology.
  But I shan't try and invent more. I'm  with you.

> (The other time it's used is when promoting values from xs:decimal to
> xs:float or xs:double, and from xs:float to xs:double.)

??? And promoting isn't a cast?

>  ... but just because document-node() comes earlier in the list
> that I gave than element() doesn't mean that you can provide an
> element where a document-node() is expected.

Note: document-node() wasn't in your earlier list, just document()
I'll assume they are one and the same thing.

> >> >     the last line I'm less sure of.
> >
> > I meant the line "                   "element(Name, Type)    "
> Ah. Basically, "element(Name, Type)" only matches elements that are
> called "Name" and have a type "Type". For example, "element(Start,
> xs:dateTime)" will match elements called <Start> with a type of
> xs:dateTime. 

OK. Mike's example showed that clearly.

(It's a bit more complicated than that, because of
> element substitution groups, but I won't go into that because you've
> said you don't care about schema-aware processing.)
Too true.... Until JT comes up with a typing system that relax ng can work
with :-)

> In basic XSLT,

I keep mistaking that (basic XSLT) for XSLT 1.0.
 how about basic xslt 2.0

 all elements have the type xdt:untypedAny (xs:anyType
> in the current specs, but I think that's going to change), so if
> you're using basic XSLT then you don't have to worry about this kind
> of test. The only element node tests you will be interested in are:
>   - element()
>   - element(Name, *)
> which match all elements, and all elements with a particular name,
> respectively.

Why do I get the feeling that this bastard child of XSLT ( this basic)
will never reach maturity? 

  I'm guessing users will fight xslt typing until they either give up
or grok sufficient to use it with a high annoyance factor?

> Note that SequenceTypes are used in other places as well as in the
> 'as' attribute on variable-binding elements. For example, you might
> want to say that a function returns a sequence of <value> elements of
> type xs:integer:
> <xsl:function name="my:get-values" as="element(value, xs:integer)">
>   ...
> </xsl:function>

What says this is a sequence, as apposed to a single element Jeni?

<xsl:function name="my:get-values" as="element(value, xs:integer)+">
would appear the right choice to me here?

> And note that this currently only applies in schema-aware XSLT
> processors. If you try to use a SequenceType like this in a basic XSLT
> processor, you will get an error.

Noted that saxon says
xsl:is-schema-aware property gives no.

At least we can tell.

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