This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 5914 - [FS]: Normalization of treat as
Summary: [FS]: Normalization of treat as
Status: CLOSED INVALID
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Formal Semantics 1.0 (show other bugs)
Version: Recommendation
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Michael Dyck
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-30 12:10 UTC by Tim Mills
Modified: 2008-07-31 07:41 UTC (History)
0 users

See Also:


Attachments

Description Tim Mills 2008-07-30 12:10:30 UTC
In Bug 5672, it was clarified that treat as can be evaluated lazily.

I'm fairly sure that the input of a typeswitch expression _can't_ be evaluated lazily, yet treat as is specified in FS to be normalized to a typeswitch expression:

[Expr treat as SequenceType]Expr
==
typeswitch ([ Expr ]Expr)
  case $fs:new as SequenceType return $fs:new
  default $fs:new return fn:error()

Is this normalization rule correct?

With the function:

declare function local:items()
{
  (1, 2, 3, "four")
};

consider:

(local:items() treat as xs:integer*)[position() lt 4]

and:

(typeswitch ( local:items() )
 case $new as xs:integer* return $new
 default return fn:error())[position() lt 4]
Comment 1 Michael Dyck 2008-07-31 01:47:41 UTC
The dynamic semantics in the FS generally follows an 'eager' or 'strict' evaluation strategy. (E.g., for a function call, it evaluates all arguments
before invoking the function.) The normalization rule for 'treat as' is just another example of that.
Comment 2 Tim Mills 2008-07-31 07:41:16 UTC
OK - thanks.

This (I think) is the only normalization rule that an implementation might want to avoid!