Thread: [Sax-devel] Re: SAX exception IDs
Brought to you by:
dmegginson
From: David B. <da...@pa...> - 2002-04-22 01:45:09
|
> 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. > (IDs are URIs, new SAXParseException methods). Done. Have a look at the javadoc on the website, the two new methods are at the end of SAXParseException and include a link to where IDs like http://xml.org/sax/exception/xml/rule-42 http://xml.org/sax/exception/xml/vc-one-id-per-el http://xml.org/sax/exception/xmlns/qname are defined. At some point I'm sure we'll end up needing something more like a catalog listing all those IDs. - Dave |
From: Jeff R. <jef...@de...> - 2002-04-22 02:09:32
|
> Done. Have a look at the javadoc on the website, the > two new methods are at the end of SAXParseException > and include a link to where IDs like > > http://xml.org/sax/exception/xml/rule-42 > http://xml.org/sax/exception/xml/vc-one-id-per-el > http://xml.org/sax/exception/xmlns/qname > > are defined. At some point I'm sure we'll end up needing > something more like a catalog listing all those IDs. I have two questions-- I am not sure if either will be useful but I will bring them up anyway. 1) Should these exceptions be prefixed with http://xml.org/sax/exception/xml/ ? Can we make a case for a URL that is more generic such as http://xml.org/exception/xml/ or is that beyond the scope of SAX to define. My thought is that these codes might be applicable (and therefore useful) in a non SAX setting where the cross-over might be good. 2) Within the Javadoc it mentioned that the parser should choose the most applicable error-- as some complex errors violate many constraints. I am wondering if it would be wise to offer java.lang.String[] getExceptionIds() where all applicable violations could be reported. I don't know how many parsers could expose this kind of information but it would be interesting... All the best, Jeff Rafter Defined Systems http://www.defined.net XML Development and Developer Web Hosting |
From: David B. <da...@pa...> - 2002-04-22 02:31:08
|
> I have two questions-- I am not sure if either will be useful but I will > bring them up anyway. Discussions are usually helpful! > 1) Should these exceptions be prefixed with > http://xml.org/sax/exception/xml/ ? Can we make a case for a URL that is > more generic such as http://xml.org/exception/xml/ or is that beyond the > scope of SAX to define. My thought is that these codes might be applicable > (and therefore useful) in a non SAX setting where the cross-over might be > good. They can be used in a non-SAX setting already, so long as that setting accomodates URIs as an ID scheme. The base URI ought never to be relevant except in terms of uniqueness. > 2) Within the Javadoc it mentioned that the parser should choose the most > applicable error-- as some complex errors violate many constraints. Overlapping constraints ... it an illegal character, or the fact that it was found where a name should be, or that the name was used for an attribute? (And so on.) Actually it said "most specific applicable rule", though I'm open to other ways to address such problems. > I am > wondering if it would be wise to offer java.lang.String[] getExceptionIds() > where all applicable violations could be reported. I don't know how many > parsers could expose this kind of information but it would be interesting... Wouldn't that be painful to work with, though? "Too much information". How would you test such a critter? When I've dealt with similar situations before, it's either been resolved strictly in terms of simplicity, or by having an error stack mechanism that more or less resembles the way a SAXException exposes a root cause (or JDK 1.4 now does for java.lang.Exception). - Dave |
From: Jeff R. <jef...@de...> - 2002-04-22 02:45:56
|
> They can be used in a non-SAX setting already, so long as that > setting accomodates URIs as an ID scheme. The base URI ought > never to be relevant except in terms of uniqueness. That is true enough-- but with the "/sax/" portion of the URI it seems to suggest that the error identifier has some specific SAX context. It does, in that it is being thrown assumably by a SAX parser. All the same if some day far in the future a reusable error interface were invented (XAE? XML API for Errors) then having a generic cross-API error ID might be useful. Another idea is to use the fragment identifiers within the actual XML specification as the error ID. Then someone could resolve the id to an actual description of the error. Of course that takes us down that long path that lead to the ambiguity we have seen wrt namespaces. Also, someone may not want to see the W3C version of the error documentation. > When I've dealt with similar situations before, it's either been resolved > strictly in terms of simplicity, or by having an error stack mechanism > that more or less resembles the way a SAXException exposes a root > cause (or JDK 1.4 now does for java.lang.Exception). Hmm... yeah I could see how that might work. Would there be a fatalError stack? I initially thought that it might be too much information-- (both for the implementer and the user) and SAX is supposed to be the "Simple API" so in that sense it might be bad. But if the docs were worded such that the getExternalIds() may return multiple ids or the "most specific applicable rule" only, then it could still be simple. Cheers, Jeff Rafter Defined Systems http://www.defined.net XML Development and Developer Web Hosting |
From: Rob L. <ro...@el...> - 2002-04-22 09:20:54
|
David Brownell wrote: > > Done. Have a look at the javadoc on the website, the > two new methods are at the end of SAXParseException > and include a link to where IDs like > > http://xml.org/sax/exception/xml/rule-42 > http://xml.org/sax/exception/xml/vc-one-id-per-el > http://xml.org/sax/exception/xmlns/qname > > are defined. At some point I'm sure we'll end up needing > something more like a catalog listing all those IDs. > Hi Dave I think there is an error in the implementation of setExceptionId(). In the implementation an exception is thrown if exceptionId already has a value, but this is not how you describe the behaviour in the javadoc comments. Regards ~Rob |
From: David B. <da...@pa...> - 2002-04-22 14:27:09
|
> I think there is an error in the implementation of setExceptionId(). In the > implementation an exception is thrown if exceptionId already has a value, > but this is not how you describe the behaviour in the javadoc comments. Right -- "!=" vs "==". Thanks, I'll put back a fix. - Dave |
From: David B. <da...@pa...> - 2002-04-22 15:47:38
|
> > They can be used in a non-SAX setting already, so long as that > > setting accomodates URIs as an ID scheme. The base URI ought > > never to be relevant except in terms of uniqueness. > > That is true enough-- but with the "/sax/" portion of the URI it seems to > suggest that the error identifier has some specific SAX context. It does, in > that it is being thrown assumably by a SAX parser. All the same if some day > far in the future a reusable error interface were invented (XAE? XML API for > Errors) then having a generic cross-API error ID might be useful. I think URIs are generic enough ... :) > > When I've dealt with similar situations before, it's either been resolved > > strictly in terms of simplicity, or by having an error stack mechanism > > that more or less resembles the way a SAXException exposes a root > > cause (or JDK 1.4 now does for java.lang.Exception). > > Hmm... yeah I could see how that might work. Would there be a fatalError > stack? I initially thought that it might be too much information-- (both for > the implementer and the user) and SAX is supposed to be the "Simple API" so > in that sense it might be bad. Both "error" and "stack" would be generic notions here. Exception objects always indicate some kind of "error" (or warning), and one way to implement "stack" is as a linked list (in this case through the root cause exception objects). Java doesn't need the kind of hairy infrastructure for such things that a C or C++ application would (or Delphi?), and so SAX doesn't need any changes whatsoever. It'd just be a policy for how to use existing environment mechanisms. > But if the docs were worded such that the > getExternalIds() may return multiple ids or the "most specific applicable > rule" only, then it could still be simple. In all honesty, I think that parsers returning more than one ID would be about as uncommon as applications bothering to use more than the first one. Most implementors really can't pay much attention to fault handling ... more's the pity, but it's actually hard enough to do a good job even with just a single good indicator of what went wrong. - Dave |