Re: Error handling in XML

[Peter Murray Rust]
><AXIOM NEGOTIABILITY="epsilon">
>My basic tenet is that an XML document is either WF or it isn't.  If there is
>one error, then the result is a null document.  If that isn't true then I think
>we lose a large number of people who see XML as a robust and reliable way of
>passing information.  
></AXIOM>

I do not think this is so. I think it is hugely important to say "this is
not well formed"
but overly spartan to then say "so fix it and try again!".

>In this respect it's like a computer program.  If you get one error, you don't
>get a *.exe (of if you do it ought not to run).  It interests me that sgmls
>will output an ESIS stream if there are errors in the document (e.g. missing
>IDs).
I use nsgmls's ability to fore on in the face of adversity almost daily in
app. development.
 
Ever program in PL/1? You could throw pretty much anything at a PL/1 compiler
and it would just plough through it making assumptions were necessary and
generate an EXE. There are times when this is fine. The original 
K&R C was somewhat similar in that the core compiler generated an EXE if it
could and tools like LINT were provided for checking the assumptions the
compiler
would have made. Perhaps the classic example is

if (a=b) { do this stuff}

My point is that there are times when getting a result even with
errors/warnings present 
is useful - as long as you are told about the errors/warnings. For example in 
prototyping a style-sheet you  could be working with slightly iffy XML docs
but not
be concerned at that point. Equally there will be XML aware tools such as 
greppers, word counters etc.  that can function in the presence of error.


Sean Mc Grath
digitome@iol.ie

Received on Saturday, 19 April 1997 06:13:00 UTC