Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » XML Schema Definition (XSD) » A Search for a more gentle approach to error handling using Eclipse XSD
A Search for a more gentle approach to error handling using Eclipse XSD [message #576161] Sun, 24 August 2003 04:37
Hayden Marchant is currently offline Hayden Marchant
Messages: 90
Registered: July 2009
Member
I am developing a Metadata repository tool, and as part of this, we
support parsing and understanding of XSD documents that are used in the
enterprise. We adopted XSD Eclipse very soon after it was released and are
very pleased with the decision.

However, even in the enterprise there are lots of invalid XSDs out there.
The problem is, is that most XSD editors and XML Validation tools do not
reject these schemas. However, Eclipse does. At first I was refusing to
accept XSDs that Eclipse did not like since we need to have semantically
valid nodes in the schemas. After I realized that this was rather a large
chunk of the schemas in the enterprise, I took a different approach of
filtering out non-fatal Eclipse errors using regular expressions on the
error message. This only reduces this problem - every time a new schema
comes along , there might be another non-fatal parse error.

I would like change this approach and parse all schemas with their errors
and decide how to limit the access to these bad constructs depending on
the severity of the error. I understand that XSDDiagnotics has a severity
property with has several levels, but I'm finding that errors that no-one
complains about apart from Eclipse are either FATAL or ERROR. I would like
to have access to the whole list of possible errors that could occur
whilst parsing so that I can decide how to deal with each error. Is there
any way that this can be exposed?

Thanks,
Hayden Marchant
Previous Topic:Default values of attributes
Next Topic:Default values of attributes
Goto Forum:
  


Current Time: Wed Jul 23 03:58:55 EDT 2014

Powered by FUDForum. Page generated in 0.05397 seconds