Re: [Sax-devel] SAX exception IDs (was: undeclared attribute types)
Brought to you by:
dmegginson
From: Rob L. <ro...@el...> - 2002-04-22 10:01:26
|
> > >Not that you can tell anything from that yet ... like which VC is involved, > > >which clause (anyone care?), which element, attribute, etc. > > > > I most certainly care about that. It would be *hugely* useful in > > debugging. I'm very interested to know how this would help debugging. > > The big effort is really in updating parsers to use those > codes ... :) Clearly can't happen in the absence of at > least a first whack at those codes ... and testing will > be interesting too. > > 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. 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. 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? 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. 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. If you base message translation on SAX error ids you are going to also have to consider adding replacement parameter information. e.g. "element {1} not expected here, expecting {2}" >"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. 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? Kind regards ~Rob -- Rob Lugt ElCel Technology http://www.elcel.com/ |