Re: Must vs. fatal error

OK, I'm not sure I'd draw the line quite where you would, but my main 
point is that our specs shouldn't talk about things like "error messages" 
or "printing errors".  Defining a class of errors as "fatal" seems OK to 
me, though again it probably wouldn't be my first choice.  Talking about 
the environment in which particular processors run, e.g. whether they have 
consoles on which errors can be "printed" or whether they reflect there 
errors through APIs seems to me to be well beyond what we want to pin 
down.   That was my main point. 

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Daniel Veillard <veillard@redhat.com>
Sent by: public-xml-id-request@w3.org
05/18/2005 04:14 AM
Please respond to veillard

 
        To:     noah_mendelsohn@us.ibm.com
        cc:     Richard Tobin <richard@inf.ed.ac.uk>, Elliotte Harold 
<elharo@metalab.unc.edu>, public-xml-id@w3.org
        Subject:        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 15:43:05 UTC