This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Sorry for creating so many new bug entries on adaptive serialization... According to the spec, a "processor SHOULD attempt to recover by inserting an implementation-defined error indicator into the output [...]". Could an example be added to the spec how such an error indicator could look like? Here are two XQuery examples that may lead to an error: 1. Error triggered by the XML output method ('standalone' and 'omit-xml-declaration' conflict): declare namespace output = 'http://www.w3.org/2010/xslt-xquery-serialization'; declare option output:method 'adaptive'; declare option output:omit-xml-declaration 'yes'; declare option output:standalone 'yes'; <x/> 2. Error triggered by the output of a function name (character that cannot be represented by the chosen encoding): declare namespace output = 'http://www.w3.org/2010/xslt-xquery-serialization'; declare option output:method 'adaptive'; declare option output:encoding 'US-ASCII'; declare function local:日本() { '...' }; local:日本#0
An example in the spec will be taken as guidance, I guess, by at least some implementors. When we know what we want something to look like, an example is a good way to let people know. In this case, however, I for one don't know what such an error signal should look like, and I'm reluctant to create an example lest it give ill conceived guidance to implementors. If I had to improvise something, then for the kind of interactive result display I take the Adaptive method to be intended for, I'd be happy with [err:SEPM0009: It is an error if the omit-xml-declaration parameter has the value yes, and the standalone attribute has a value other than omit; or the version parameter has a value other than 1.0 and the doctype-system parameter is specified.] as the output for the first case, and [err:SERE0008 It is an error if a character that cannot be represented in the encoding that the serializer is using for output appears in a context where character references are not allowed (for example if the character occurs in the name of an element).] for the second. If an implementation chose to emit the error message and then also <x/> (ignoring the standalone parameter), <x/> preceded by a standalone declaration (ignoring the omit-xml-declaration parameter), or the function name (ignoring the encoding parameter), I would object neither as a user nor as a spec lawyer. In order to help the user distinguish these cases from the serialization of text nodes or strings that contain strings like "[err:SERE0008 ...]", I think an interactive user interface would be wise to report the errors out of band (in the alert area or in the query log, for example), as well as inserting error indicators "into the output" as described in the spec. I am beginning to wonder whether attempting to standardize an Adaptive method was a good idea, or whether we would have done better to leave the entire thing to implementations.
> I am beginning to wonder whether attempting to standardize an Adaptive method > was a good idea, or whether we would have done better to leave the entire thing > to implementations. Michael, thanks a lot for the elaborate feedback on my questions on the Adaptive method. Maybe it would be fine to leave details like this up to the implementation. If this output method will mostly be utilized by implementations, and not users, the examples I listed are most probably "Kopfgeburten" (purely theoretical?), and as "error indicator" did not help me to understand how the output could look like, the rule in question could be simplified to: If any value cannot be output because doing so would cause a serialization error, the behavior is implementation-defined. And a final thought... The complete method could be renamed to "trace" or "debug", because "adaptive" initially indicated to me, and could indicate to future users, that this method is a more flexible alternative to other serialization methods (but I know this suggestion comes very late, so I should better be quiet ;).
Having tried to think this through again, I think the change proposed in comment 2 is a good one and should be adopted. The names 'debug' or 'trace' would also have been better, but I think it's too late to change the name now, so I propose to decline the implicit proposal with a sigh, and close the issue.
This change has now been applied and committed.