[Bug 5747] [FS] Expansion of castable throws errors

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5747


Michael Dyck <jmdyck@ibiblio.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED




--- Comment #2 from Michael Dyck <jmdyck@ibiblio.org>  2008-07-05 03:03:27 ---
To address the two cases in Comment #0, we could change the normalization rules
in FS 4.12.4 so that the type of $v is xs:anyAtomicType*. At that point, I
think the introduction of $v ceases to have any purpose, so we could "inline"
its definition, and even collapse the two rules into one:

    [[ Expr castable as SingleType ]]_Expr
    ==
    fn:data(( [[Expr]]_Expr )) castable as SingleType

However, this would still have the problem (alluded to in Comment #1) that
failure to atomize the value of Expr would raise FOTY0012 rather than cause the
CastableExpr to yield false. (The latter being the correct behaviour, as
indicated by Bug 4873 comment #1.) Therefore, I believe atomization needs to be
pushed down into the core dynamic samantics of 'castable', rather than being
exposed by normalization. So the normalization rule should be:

    [[ Expr castable as SingleType ]]_Expr
    ==
    ( [[Expr]]_Expr ) castable as SingleType

But I'm not yet sure what the dynamic evaluation rules should be. (Currently,
the DE rules don't address the AtomicType? case, and the second DE rule has
numerous bugs, so I'd want to propose rules that fix those problems too.)


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Saturday, 5 July 2008 03:04:04 UTC