This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This is from a problem encountered in report #3782: Since the return type for fn:trace isn't inferred from the input it is tracing, one must in most cases insert a 'treat as' expression each time one inserts an fn:trace call. I would find this very cumbersome. For example, this query is a static typing error: trace("this Input is traced", "The trace message.") eq "a string" because the left operand to 'eq' has item()* as static type. I suggest that a section is added for fn:trace, and that its return type is inferred similarly to fn:reverse(). This is a large change, but the specification also has a large hole here, in my opinion. fn:trace() is very unpractical on a static typing implementation as it is now.
This is a good remark. I think that function never got the attention it deserved on the static typing front. However, this is really late in the process to change this, especially that it requires changes to two documents (F&O will have to point to static typing rules, the FS will have to invent new static typing rules). Personally, I think this issue could be dealt with by implementation using a static typing extension for that version. The static typing extension should provide enough flexibility to do this. - Jerome
I don't think there's that much to say. Here's a clear hole in the spec, but if the necessary changes can't be done, that's the end to the story. I have acceptance for closing as WONTFIX, although I would grumble as everyone else.
The XML Query and XSLT WGs have decided to reject the proposed change and leave the static semantics of fn:trace as is. This may be considered for a future version. Best, - Jerome, On Behalf of the WGs
(Note that this suggestion was raised against FS 1.1, and approved, in Bug 5786.)