The author (i.e. Dennis Knochenwefel) of these tests is not a member of the WG. Do we want to refer the test back to the author?

Generally spoken, I believe what you say, Michael, but in this case maybe the spec needs to be clarified.

So, let me explain the way I interpreted the section cited:
-----------------------------------------------------------

1. The section uses the wording "report" instead of the usual "raise". "Reporting" an error in contrast to "raising" an error is implicitly defined in section "Identifying and Reporting Errors" as:

"The method by which an XQuery 3.0 processor *reports* error information to the external environment is implementation-defined."

This led me to conclusion (1) that the query processing is not disrupted by "reporting" (instead of raising) an error.

2. The spec doesn't give an explicit error code, which supported my conclusion (1), because for an informal "reporting" you wouldn't need an error code.

3. The spec says the processor should report a "serialization error". As the spec only defines "static errors", "dynamic errors", and "type errors" (cf. section "Kinds of Errors") I saw my conclusion (1) confirmed that no disruptive error should be raised. Accordingly, the spec defines (without mentioning "serialization errors"):

"The outcome of the static analysis phase is either success or one or more type errors, static errors, or statically-detected dynamic errors. The result of the dynamic evaluation phase is either a result value, a type error, or a dynamic error."

4. In section "Serialization" after the cited section the spec says:

"A processor that is not performing serialization may report errors if any serialization parameters are incorrect, or may ignore such parameters."

This implies that "reporting an error" is not mandatory in any case.

In Summary:
-----------

I'm wondering if the spec doesn't need to clarify whether it wants a dynamic error to be raised. If so, I believe it should also define the respective error code and type of error. If it just wants something to be reported (implementation-defined) without interrupting the processing (which was my impression) it would be very helpful if this could be made abundantly clear. 

I assume that it would make sense to fix the mentioned tests after this has been clarified?

I think this is the part the XQuery 3.0 Spec doesn't supply sufficiently:
-------------------------------------------------------------------------

From the serialization spec (section "Conformance"): "It is the responsibility of the host language to specify how serialization errors should be handled."

I'm converting this to a specification bug on XQuery as the host language in question.

I don't believe the distinction between "reporting" and "raising" an error was intended; or at any rate, saying that it's implementation-defined HOW an error is reported doesn't mean that reporting the error is optional.

The section that says the processor MAY report errors applies only to a processor that is not performing serialization; i.e. if you aren't serializing then you are not required to validate the serialization parameters (but you can if you want).

Your last statement enlightened me:

I now realized that in the given context I was misreading "performing" as "supporting" because:

1. to comply with the serialization parameters seems to be optional ("the processor may use these parameters to control the way in which the serialization takes place"). So, I was not expecting that the reporting of incorrect values is mandatory. Why is a processor given the freedom to ignore serialization parameters, but being burdened with checking the correctness of the parameters? Obviously, I might be wrong, but is "performing" really intented to be used here?

2. if "performing" does not mean "supporting" here, then I think that some points need to be rephrased, for example this sentence:

"If a processor is performing serialization, it is a static error [err:XQST0119] if [...]"

I am wondering, how a processor is supposed to know in the static analysis that it will perform serialization? This would be an oxymoron unless "performing" is supposed to mean "supporting", or am I completely mistaken?

------------------------

To add more to this discussion: there are two types of incidents that might occur and eventually be handled differently:

1. a particular serialization parameter value can be "not supported" by the processor
2. a serialization parameter value can be "invalid" in accordance to the serialization spec

I believe that the specification does not distinguish very precisely between those which could be improved as well. I am not sure if the first incident type is being taken care of at all (depending on what "incorrect" means)?

Thank you very much.

Well, firstly, "support" is a word with so many meanings that it should never be used in any kind of technical specification. 

I think the essence of the rules is (or should be):

(a) if a query is invoked in such a way that serialized output is requested and delivered, then any errors in the serialization parameters must be reported in the same way as other errors in the query

(b) if a query is invoked in such a way that serialized output is not requested or delivered, then the serialization parameters have no effect, except that if they are invalid, it is at processor discretion whether the errors are reported.

The difference between "performing" and "supports" here is that the processor might well "support" serialization, in the sense that it allows serialization to be requested, but checking of serialization parameters is only required if serialization is actually requested on this particular execution of the query.

I agree this could do with some tightening up: "When the application requests serialization of the output, the processor may use these parameters to control the way in which the serialization takes place. Processors may also allow external mechanisms for specifying serialization parameters, which may or may not override serialization parameters specified in the query prolog."

I think better would be: When the application requests serialization of the output, the processor must use these parameters to control the way in which the serialization takes place, unless by means of some implementation-defined external mechanism the user has requested otherwise.

I'm moving this back to being a specification bug, as the last few comments are discussing a specification change; the disputed test revealed a lack of clarity in the specification.

(In reply to comment #2)

> 1. The section uses the wording "report" instead of the usual "raise".
> "Reporting" an error in contrast to "raising" an error is implicitly defined in
> section "Identifying and Reporting Errors" as:
> 
> "The method by which an XQuery 3.0 processor *reports* error information to the
> external environment is implementation-defined."
> 
> This led me to conclusion (1) that the query processing is not disrupted by
> "reporting" (instead of raising) an error.

I have changed the three instances of "report an error" in the spec to "raise an error", the usual terminology. This was an accident of different writing styles among editors.

What happens when serialization is performed and a specified parameter is not supported by the implementation**.  Please assume that the parameter is applicable to the output method and the value is valid.  

For example:

   declare option output:method "xml"
   declare option output:indent "yes";
   <a><b/></a>

If the implementation does not support indent, what happens when serialization is performed? 

I think this is what Dennis was referring to as "incident 1" in Comment 4.  


** 2.2.4: "If an XQuery implementation provides a serialization interface, it may support (and may expose to users) any of the serialization parameters listed ..."

Also, for most of these test cases, I don't think we can say if the value is valid or not. For example, here is Serialization-023:

   declare namespace output = "http://www.w3.org/2010/xslt-xquery-serialization";
   declare option output:use-character-maps "INVALID_VALUE";
   <result>ok</result>

Serialization defines use-character-maps as "A list of pairs, possibly empty, with each pair consisting of a single Unicode character and a string of Unicode characters."

But as far as I can tell, XQuery does not define how the StringLiteral in the option declaration should be mapped to a list of pairs.  And, since we don't know what mapping an implementation will use, we don't know if "INVALID_VALUE" maps to a valid value or not.  Am I missing something?

The XQuery specification (internal draft) now says errors that are not recognized should be silently ignored::

[XSLT and XQuery Serialization 3.0] defines a set of serialization parameters that govern the serialization process. If an XQuery implementation provides a serialization interface, it may support (and may expose to users) any of the serialization parameters listed (with default values) in C.1 Module Static Context. If an implementation does not support one of these parameters, it must ignore it without raising an error.

It also specifies the names and values:

[Definition: An output declaration is an option declaration in the namespace "http://www.w3.org/2010/xslt-xquery-serialization"; it is used to declare serialization parameters.] Except for parameter-document, each option corresponds to a serialization parameter element defined in Section B Schema for Serialization Parameters SER30. The name of each option is the same as the name of the corresponding serialization parameter element, and the values permitted for each option are the same as the values allowed in the serialization parameter element. There is no output declaration for use-character-maps, it can be set only by means of a parameter document.

> The name of each option is the same as the
> name of the corresponding serialization parameter element, and the values
> permitted for each option are the same as the values allowed in the
> serialization parameter element. 

It sounds good to me.  I assume that for parameters that accept QNames such as cdata-section-elements, the lexical QNames are expanded using the statically known namespaces and that QNames without a prefix are in the default element/type namespace?  I am not sure if this is already implied by the current text or not.