- From: olivier Thereaux <ot@w3.org>
- Date: Fri, 7 Sep 2007 11:00:08 +0900
- To: Brian Wilson <bloo@blooberry.com>
- Cc: www-validator@w3.org
On Aug 30, 2007, at 15:14 , Brian Wilson wrote: >>> I'm currently doing string matches against the <env:Reason>/ >>> <env:Text> >>> content when a <env:Fault>/m:exception is encountered, and that >>> solution >>> doesn't seem very elegant. [...] > I'd like to store a very short unique identifier for every error > class reported and that would go for fatal errors too. I could > intercept > those messages and create my own codes, but it would be easier (and > maybe > for others) if they were already there. OK, done in CVS http://dev.w3.org/cvsweb/validator/share/templates/en_US/ soap_fault.tmpl.diff?r1=1.4&r2=1.5&f=h That was the easy part. Now comes the really tricky issue, for which I wonder if anyone has ideas. Our main parser (for validation against DTDs), opensp, has the wonderful feature, that with each error, it gives a little code that says "by the way, this is error 128". Other parsers certainly have that way of giving an id for each error, but they're not sharing it with the client. This is a problem for the validator, which now uses XML::LibXML for XML well-formedness checking, and probably in the future, for checks against XML schema, schematron, relaxng... No identifier for each single error means no way to have (like we have for DTD validation) a library of explanations and suggestions for fixes. My two ideas to resolve this are: * extract a list of all errors from libxml and assign an id to each, match with regexp each time one is thrown * suggest to Daniel and the libxml team to "expose" the error ids, if they exist. The former is not extremely performant but feasible, the latter is probably not feasible, but worth asking anyway. Thoughts? -- olivier
Received on Friday, 7 September 2007 02:00:17 UTC