W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2012

[Bug 16089] [FO30] cast vs. constructors (FunctionCall-015)

From: <bugzilla@jessica.w3.org>
Date: Tue, 08 May 2012 20:03:08 +0000
To: public-qt-comments@w3.org
Message-Id: <E1SRqcm-0002La-Ux@jessica.w3.org>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16089

--- Comment #9 from Michael Kay <mike@saxonica.com> 2012-05-08 20:03:07 UTC ---
(In reply to comment #8)
> I presume that this removes the raising of XPTY0117 in section 3.1.5.2 Function
> Conversion Rules.  Thus XPTY00117 is now redundant.

No, I don't think that was the intent.

There's a problem with the function conversion rules that doesn't apply to
casts and constructors: there's no obvious choice of static context to get the
namespaces from.

Using the static context of the function itself doesn't work for system
functions and external functions (perhaps it doesn't even work for user-defined
functions, as it's only expressions that have a static context).

Using the static context of the caller raises lots of problems with dynamic
function invocation, function coercion, and the like. The rule would also need
to cover cases where the (ill-named) function conversion rules are used for
things other than converting function arguments, e.g. conversion of function
results, or conversion of variable bindings in XSLT.

So I think the rule is still that conversion of untypedAtomic to QName does not
happen in the function conversion rules.

-- 
Configure bugmail: https://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 Tuesday, 8 May 2012 20:03:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:38 UTC