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 1577 - [FS] technical: 4.1.5 Function Calls: Normalization
Summary: [FS] technical: 4.1.5 Function Calls: Normalization
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Formal Semantics 1.0 (show other bugs)
Version: Last Call drafts
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Jerome Simeon
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-07-14 04:09 UTC by Michael Dyck
Modified: 2005-09-06 12:58 UTC (History)
0 users

See Also:


Attachments

Description Michael Dyck 2005-07-14 04:09:35 UTC
4.1.5 Function Calls

Normalization
"Note that this normalization rule depends on the static environment
containing function signatures"
    Specifically, the SequenceTypei in the rule's RHS presumably come from
    one of the function signatures in statEnv.funcType. But which one? It
    seems to me that you need to do Static Type Analysis, which
    (a) might find more than one valid signature; and
    (b) operates on instances of the Core syntax, which requires that we
        first normalize the FunctionCall, and so we have a circularity.
Comment 1 Jerome Simeon 2005-07-19 21:20:28 UTC
The way to break the circularity is that you do not really need static
typing. You can just rely on the actual signature declared for the function.

In the case of F&O overloaded functions, there may be multiple signatures but
they are always for atomic types or sequences of atomic types and this results
in the same normalization whichever signature you choose.

This should probably be indicated more clearly in the document.

- Jerome
Comment 2 Jerome Simeon 2005-08-31 15:21:26 UTC
The XML Query and XSLT WGs have accepted the comment with the fix, as suggested
below, using wording proposed in Bug #1577.
- Jerome
Comment 3 Jerome Simeon 2005-08-31 23:27:57 UTC
What was meant was fixed using the wording in Bug 1578.
- Jerome
Comment 4 Michael Dyck 2005-09-01 00:27:44 UTC
(In reply to comment #1)
>
> The way to break the circularity is that you do not really need static
> typing. You can just rely on the actual signature declared for the function.

Sure, *now*. The acceptance of Bug 1580 means that the original "But which one?"
question now goes away.

Or maybe it was never a valid question; see Bug 1578 comment #3.

> In the case of F&O overloaded functions, there may be multiple signatures but
> they are always for atomic types or sequences of atomic types and this results
> in the same normalization whichever signature you choose.

Actually, for different SequenceType <: xdt:anyAtomicType*,
[]_Convert(SequenceType) *does* result in different normalizations, since the
choice of SequenceType constrains the choice of PrototypicalValue. However, that
should now be a moot point.