[Bug 29296] [SER31] Adaptive Method, Error Recovery

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29296

--- Comment #1 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 17 November 2015 03:19:31 UTC