Re: Must vs. fatal error

I have some concern with this whole line of discussion.  My strong feeling 
is that one wants to separate the specifications for what's a language and 
its interpretation from the specifications of particular software that 
checks or operates on instances of the language. 

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 
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 
certainly shouldn't tell you whether you're running in an environment in 
which it even makes sense to talk about "printing" error reports, as 
opposed to writing them on disk, reflecting them through an API, sending a 
message through a network, or just (I hope not) quietly rebooting.

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. 

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








Richard Tobin <richard@inf.ed.ac.uk>
Sent by: public-xml-id-request@w3.org
05/16/2005 08:33 AM

 
        To:     Elliotte Harold <elharo@metalab.unc.edu>, Richard Tobin 
<richard@inf.ed.ac.uk>
        cc:     public-xml-id@w3.org, (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Re: Must vs. fatal error



> > Does that help you?
> 
> Not really, no. A library such as XOM should not talk to the user in any 

> way. Specifically, it should not print anything on System.out or 
> System.err. (This is a longstanding complaint I have about Xerces. XOM 
> goes to some lengths to hide the warning Xerces prints.) XOM talks only 
> to the client application, and it's up to the client application to 
> decide what to show or not show the end-user. Indeed, in many cases 
> there may not be any end user or even a console where messages printed 
> on System.out and System.err can be seen.

In that case, I don't see how we can do much.  A system that can't
return non-fatal errors to the application and can't display them to
the user just has no way to signal non-fatal errors.  And I don't
think that this should result in standards only being able to require
errors to be reported if they are fatal.  So I think you will just
have to be non-conformant in this respect.

-- Richard

Received on Wednesday, 18 May 2005 02:53:15 UTC