Re: [Sax-devel] SAX exception IDs (was: undeclared attribute types)

[David B. <da...@pa...>]

> I'm very interested to know how this would help debugging.

FWIW I see applications benefitting a lot more from it,
though admittedly _any_ relevant information can help
someone debugging.

Today, without any such IDs, all you can tell given a specific
exception is "something broke" ... and depending on how
you get the exception (ErrorHandler vs catch), you might be
able to learn the severity (fatal, nonfatal, warning).

Given a usable scheme for such IDs, you can actually
know something about what's wrong.  That means at
least the possibility of doing something more intelligent
than applications doing the metaphorical equivalent of
throwing up their hands ("complain to some human").


> > Since this is on the list of RFEs, I'll put back an initial
> > version of the API and exception ID definitions, along
> > the lines of what has been discussed here in the past.
> 
> I fear that this feature may find its way into SAX 2.1 without adequate
> consideration. 

It got plenty of discussion later last year, and nobody flagged
any problems with it back than as I recall.  In fact someone
even filed an RFE on the topic.  I'm sorry, I won't have the
time to maintain "constant" consideration ... or even do much
to refresh it!  :)


>     So far I can't see a great deal of value in this, yet adding
> it implies a fair amount of work for all parsers that want to achieve
> compliance with SAX 2.1 when the time comes.

Trivial compliance:  don't provide the IDs.  As it says:

    Not all parsers will choose to provide all these IDs, but those
    that provide any must only use the exception IDs defined by SAX.

Useful compliance would be more work, true.


> I can see that these additions to the API would aid automated SAX
> conformance testing, but is this a good enough reason to justify the cost?

Whose costs are you concerned with?  I'm not clear why you'd
object to applications being able to more accurately identify
"WHAT broke".

I am clear that parser implementors might not be wholly keen on
any more work whatsoever.  That's part of why "trivial compliance"
is an option.


> Also, adding error ids will create a whole new class of conformance, taking
> away some of the (legitimate) choices about which error is the most
> meaningful for a SAX parser to report.

Not as written -- not at all.  As for "most meaningful" there's clearly
flexibility about how specific to be.  (Maybe even too much.)  While
as for "choices", surely the only legitimate errors to report are as
defined in the XML REC.


> From the documentation
> [http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/sax/sax2/src/org/xml/sax/pac
> kage.html]:
> 
> > "For example, [applications] can assemble (and translate)
> > catalogs of messages that make sense to their users."
> 
> I don't think this will be a realistic option.  Personally I would expect
> the SAX Parser to provide a translation based on the user's language
> preferences. 

Not all parsers can/will do that.  And in any case, the issue is that
applications need to distinguish errors ... there's already a user
targetted mechanism for that (exception messages).

You need to think about the error as distinct from its diagnostic.

Presenting a diagnostic is ONE way to handle errors, and not 
even a very good one:  it's a "punt all problems to the user" kind
of solution, which users don't want in all cases.


> >"In some cases they can write code that uses knowledge
> > of the errors to decide how to proceed most effectively.
> > For example, some validity errors might be of no concern,
> > while others might need to be treated as fatal."
> 
> I think the most interesting benefit here is that the application may decide
> how to proceed from a VC.  I don't think the application will have many
> useful choices following a well-formedness error.  It may help reduce the
> scope of this debate if we concentrate on creating IDs for validity
> constrains only.

I don't see any benefit to saying the IDs can _only_ apply to validity
errors.  Though I suspect you'd be right that providing them in those
cases will give the highest initial return (for applications and thus for
parser implementors).


> Finally, I have a concern about the practice of using the SAX source tree
> for exploring new API features in this way.  My concerns may be unfounded,
> but don't you think this practice is likely to create a "fait a complit"
> even though the changes haven't been fully ratified?

Well, I do think this feature and its need has gotten a fair amount of
discussion already.  Not in the last month, but later last year there
was some significant discussion on the topic.  (Check list archives.)

And also RFE [486006] (just closed), filed by someone who wasn't
an active participant in that debate, which had been hanging out
with this exact resolution (read it!) for about four months... it's not
as if this change hasn't been telegraphed in advance, to this list.

You seem to think that there should be even more "ratification", and
I'm at a loss to see why.  Could you elaborate?  For me, this was
just (finally) taking an item off a very publicly created and maintained
"TO DO" list, yet it seems you may feel otherwise.

- Dave