XOM API for Processing XML with Java

[Johan Strandberg <johan AT acm.org>]

On Fri, 2003-09-05 at 13:46, John Cowan wrote:

> True, enough, but three paragraphs down appears the following sentence
> (the first line of which was added by official erratum 23):
> 
>       Unless an encoding is determined by a higher-level protocol,
>       it is also a fatal error if an XML entity contains no encoding
>       declaration and its content is not legal UTF-8 or UTF-16.
> 
> I will attempt to get the Core WG to resolve the conflict in time for
> the pending 3rd Edition.


Good point. It is not like this is easy to disambiguate. There is also a
passage in Appendix-F (although that is non-normative -- thanks a lot,
you get some info that you can work with and the you realize that
anything it says may have to be ignored [sigh])


        Because each XML entity not accompanied by external encoding
        information and not in UTF-8 or UTF-16 encoding must begin with
        an XML encoding declaration, in which the first characters must
        be '<?xml', any conforming processor can detect, after two to
        four octets of input, which of the following cases apply.
        

The magic word here is "must" because according to the standard:


        must -- Conforming documents and XML processors are required to
        behave as described; otherwise they are in error.


I assume that it is significant that a violation of "must" is only an
"error" and not a "fatal error". 

<soapbox size="small">
The more I look at the difference between error and fatal error, I get
the feeling that the standards use of "error" corresponds to what I
think most people think of as a really stern warning.

--

An analogy might help.  You are driving down the highway.  An incident
occurs.


        (A) Nobody actually gets hurt, but the officer gives you a
        ticket. You continue on to work.
        
        (B) Metal gets bent, you get a ticket, but you continue on to
        work.
        
        (C) Metal and people gets bent. You do not get to work that day.
        
        (D) You don't make it.
        

In my interpretation, the standard uses (A="may" and sometimes "error"),
(B="must" and "error"), (C and D="fatal error")

But many software systems use (A=WARNING), (B and C=ERROR), (D=FATAL
ERROR)

---

Analogies are only that. But at least for me it helped me think through
the differences. Obviously nobody is going to change the way "may",
"must", "error", or "fatal error" are used in the standard, or even
where they are used.

At best, the few places where there are internal conflicts and/or
inconsistencies in usage can get cleared up.

What I did find, looking at the analogy above, is that the standard is
implementation centric. I.e., if I as a parser developer find that a
condition is an error, I can easily implement a simple "return an
error-code and stop", or I can report the error and then do that little
extra to recover and go on. It is my choice.

As a user of the parser however, I will sometimes get an error from the
parser for cases I could care less about 99% of the time, but I still
can't assume the parser will pull itself together and move on. 

A good example would be the encoding problems above. As a application
developer, I want the parser to make best effort to parse.  If it
detects UTF-16 and parses the stream as UTF-16 without problems. then I
frankly don't care that the user fumbled and typed "UTF16" instead of
"UTF-16".

There is exactly one usage of '_' in a string in a normative context,
and that is the string "Shift_JIS" as an encoding name (4.3.3), but if
the user doesn't remember to use '-' for "EUC-JP" and '_' for
"Shift_JIS", then the parser "must" report an "error", even if it can
figure out right away it was a typo and move on.

So, that's why I call it parser centric. As an application developer I
want to be able to give my users a tad more slack in such a situation.
</soapbox>


--j