This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Consider declare output:parameter-document "params.xml"; Is it intended that the parameter document is resolved relative to the static (compile-time) base URI, or the dynamic (deployment time) base URI? We don't say. There are different use cases here. If the idea is to allow the serialization parameters to be specified at run time, then the dynamic base URI should be used. This appears to be the intended scenario, otherwise why would a parameter in the file override one in the query? However, if the intended use case is to define a standard set of serialization parameters for all queries, which can be overridden perhaps temporarily by a query developer during debugging, then the requirements are different. In particular one would then expect the parameter value in the query to override the one in the parameter file. Also (editorial point), the text "The value of any other output declaration overrides any value that might have been specified for the same serialization parameter..." might be read as implying that the order of declarations is significant, which I don't think is the intent.
I like the functionality you want here - easy, declarative specification of serialization parameters at run time. If we say the file is used at query compile time, then a query could use fn:serialize() and load a parameter file. If we say the file is used when the query is started, then there's no way to declare character maps at compile time.
As Adam points out, using fn:serialize() requires the query to parameterize each call to fn:serialize(). It's often more convenient to specify serialization options for the query as a whole.
The serialization parameters file affects the static context. The errors that are raised are static errors, the relative URI is resolved against the static base URI. So in the status quo, this is all determined at query analysis time. We have decided to add a note saying that implementations may provide a way to override serialization parameters when a query is started, e.g. using a parameter file.