Re: Must vs. fatal error

On Tue, May 17, 2005 at 10:49:44PM -0400, noah_mendelsohn@us.ibm.com wrote:
> I think that, in general, XML family Recommendations (such as xml id) 
> should talk about what's legal in XML documents, and what's not.  In the 
> case of errors, it's useful to provide names for the errors etc.   I don't 
> think such specifications should say anything at all about whether and how 
> a particular piece of software reflects that error to some other piece of 
> software or to a user, or even whether processing can continue.  The 

  Hi Noah,

  With due respect, I disagree with this. XML-1.0 specified on purpose
that fatal errors were fatal and should not be tried to be recovered from
to avoid the disaster we saw with HTML. It was successful as far as I
can tell, this forced divergent implementation to be fixed, as a result
XML-1.0 interop is very high and other specifications should aim at the same
level.

> language specification should merely say what information can or cannot be 
> safely inferred given a document that is in some way flawed.    The point 
> is:  don't talk about printing, errors, aborting or whatever.  For 
> comparison, the C language specification should tell you which strings 
> represent legal C programs and which don't.  It shouldn't tell you what a 
> particular piece of software (a pretty printer, for example?) will do when 
> faced with a string that is nearly but not quite a legal C program.   It 

  trivial, a pretty printer operates over a string not over a C program, 
it doesn't have the same constraints, actually most pretty printer take
any string and then try to infer the language and then render it. They
don't require C they require strings. But a pretty printer does not have
interoperability constraints, it does not requires strict conformance to
a spec for an useful output. Maybe one can come up with a better example,
but the example would have to require interoperability to be really worth
it, because if you don't require interop, you don't require a standard.

> In a language specification, I think it's better to say "the document is 
> not conformant if XXX" or "a document is partially conformant if it meets 
> the syntactic requirements of this specification, but if one or more of 
> its IDREFs fail to resolve;  it is possible to write software that 
> extracts useful reference information from those IDREFs that do resolve", 
> or something else in that spirit. 

  I am an implementor. I really prefer a spec which makes clear what is 
a fatal error (i.e. forbidding correct processing) and make clear potential
other errors and explains how to process them. We have unfortunately very
good examples of specs with so many grey area that they make interoperability
an nearly impossible goal, sometimes grey areas are unavoidable, but then
a generic suggested processing path is the best to try to achieve coherency
and sounds to me way better than just ignoring the issue.
  If processing was just a pure matter of syntax, that would be very very
nice, unfortunately there is usually a framework which impede on them (on
the web is a resource available or not, for example), and ignoring this
from a specification perspective means that implementations will diverges,
which in my opinion means the specification was a failure.

  To me the main goal of a standard is to garantee interoperability of
implementations of a technology which is to be widely deployed.

  And specifying handling of errors seems a required step to achieve that
goal in most cases.

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

Received on Wednesday, 18 May 2005 08:14:47 UTC