This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Hi, I'm very pleased with the adaptive serialization outputmethod( see related item: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27498). However the output for functions is very minimal (I'm using Basex however I don't think it's Basex-specific). When using closure-functions as internal datarecords (as I do) debugging XQuery-code is a real brain-teaser. Some more informationIt would be very wellcome. For example as Basex's map:serialization output for functions as mapvalue, see example below: xquery: ======= let $f := function( $a, $b){ function( $f){ $f( $a, $b)}} let $a := $f( 'a', 'b') return map:serialize( map { "D" : $a}) result: ======= { "D": function($f_9) as item()* { $f_9("a", "b") } }
XDM states that a function has the following properties: * name (xs:QName): An expanded QName, possibly absent. * parameter names (xs:QName*): A list of distinct names, one for each of the function's parameters. * signature (a FunctionTest of the form Annotation* TypedFunctionTest): The TypedFunctionTestXP31 has one SequenceTypeXP31 for each parameter, and one SequenceType for the function's result.... * implementation This enables the function, when it's called, to map instances of its parameter types into an instance of its result type. The implementation is either: a host language expression, which is always associated with a static context, or an implementation-dependent function implementation, which is optionally associated with both a static and a dynamic context. * nonlocal variable bindings (a mapping from xs:QName to item()*): This provides a value for each of the function's free variables (i.e., variables referenced by the function's implementation, other than locals and parameters). The problem is, (a) much of this isn't actually available using accessors on the function item, and (b) part of it doesn't have an obvious string representation. I'm not sure why the parameter names are in this list, because there is no need for an implementation to retain the names of the parameters. Perhaps it's needed for the formal modelling of the semantics. However, I don't think we should require implementations to retain the parameter names just for the sake of serialization. The implementation is an even bigger problem: I don't think we can require implementations to have a decompiler that reconstructs source code from compiled code. As for nonlocal variable bindings, an implementation might well inline variable references within the function body, replacing them by the values to which the variables are bound. We could possibly include the types of arguments and the result in the serialized form, but I don't think we can add much else. We could also possibly PERMIT implementations to include further information about functions, while leaving the detail implementation-defined.
I can see that serialization of functions, especially of function results, isn't something you should be willing to do and probably not even permit it for implementations. On the other hand, purely from a user-perspective, I strongly feel the need for serialization of my internal datarecords, which in my experience are best suited by closure-functions except, helas, in case of standard serialization. Probably we need another approach to get out of this split: f.e. the datarecord as a formal datatype with the same behaviour as closure-functions and the possibility to being serialized.
Many thanks for raising this and for the subsequent discussion. The Working Group considered this at the last teleconference and decided to close this as "won't fix" because this doesn't represent a use-case that we are trying to address in the 3.1 documents.