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

[David.Pawson@xxxxxxxxxxx]

Thanks for another view Michael.

> > 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?
> 
> "as" on xsl:variable is an assertion about the type. For 
> example, if you
> do
> 
> <xsl:variable name="x" as="xs:integer" select="my:prime-number()"/>
> 
> then you are asserting that the function my:prime-number() will return
> an integer, or a value that can be (loosely-speaking) treated as an
> integer. If it returns an xs:unsignedInteger, your assertion 
> is correct,
> because xs:unsignedInteger is a subtype of xs:integer. If it 
> returns an
> attribute node that contains an integer, or that contains an untyped
> value that can be read as an integer, then you're also OK. But if the
> function returns a string or a date, then you'll get an error. The
> system can report this error at compile time if it can detect it then,
> otherwise it will be a run-time error.

So rather than saying dear processor I want this function to 
return an integer, its almost saying I hope it returns an integer.
I.e. its not a request for a cast, its .... just to keep the typing
system happy (for those that need one :-) I.e. it does little for 
the end user. 

> > >   <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??
> > 
> > Assuming such a cast is viable/allowed, any use of $foo
> > will be as a decimal thereafter in the stylesheet?
> 
> You don't get casting here, only the weaker kind of conversion allowed
> in function call and assignment contexts.

Ok, I'm with this now.


 This allows (a) 
> extraction of
> the content of a node, (b) numeric promotion (e.g. integer to decimal,
> but not decimal to integer), and (c) casting of untyped values only.
> 
> The static type of $foo is xs:decimal, but the dynamic type 
> of its value
> is integer. Static types aren't likely to affect XSLT processors
> significantly; they are much more important for some XQuery processors
> (such as Microsoft's) which are proposing to implement "conservative"
> static typing: which means the static type of an expression has to be
> right for the context where it is used, not just the dynamic 
> type of its
> value. This might sound complicated but it's exactly what happens in
> many programming languages like Java: it's an error to write
> 
> Node n = xyz.getElement();
> abc.setElement(n);
> 
> if setElement expects an Element; you have to write
> 
> abc.setElement((Element)n);
> 
> This kind of cast is written "treat as" in XPath/XQuery (because SQL
> uses "cast" to mean something different).

A view on this could be that its rather anti-user? 
'I want it to be an integer' is demoted to 'I'll treat it as an integer if
allowed under the rules'. 





> 
> > > 
> > > 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.
> >
> 
> No: this is nothing to do with casting. You can cast a string 
> to a date,
> but you can't use a string in places where a date is expected. 

Yes,  Jeni made that clear.

Thanks Michael.

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