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 #26718] Sun, 24 August 2003 08:37 Go to next message
Hayden Marchant is currently offline Hayden MarchantFriend
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
Re: A Search for a more gentle approach to error handling using Eclipse XSD [message #26799 is a reply to message #26718] Sun, 24 August 2003 13:03 Go to previous message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

--------------2D7A88BC6480983A11FC57BC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hayden,

Yeah, there are sure a lot of bad schemas out there aren't there!

All the error messages are in plugins/org.eclipse.xsd/plugin.properties. They
typically have names based on keys in the spec's html, e.g., the message:

cvc-complex-type.3 = The attribute ''{0}'' is not permitted

can be located like this:

http://www.w3.org/TR/xmlschema-1/#cvc-complex-type

Hayden Marchant wrote:

> 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

--------------2D7A88BC6480983A11FC57BC
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hayden,
<p>Yeah, there are sure a lot of bad schemas out there aren't there!
<p>All the error messages are in plugins/org.eclipse.xsd/plugin.properties.&nbsp;
They typically have names based on keys in the spec's html, e.g., the message:
<blockquote>cvc-complex-type.3 = The attribute ''{0}'' is not permitted</blockquote>
can be located like this:
<blockquote><A HREF="http://www.w3.org/TR/xmlschema-1/#cvc-complex-type">http://www.w3.org/TR/xmlschema-1/#cvc-complex-type</A></blockquote>

<p><br>Hayden Marchant wrote:
<blockquote TYPE=CITE>I am developing a Metadata repository tool, and as
part of this, we
<br>support parsing and understanding of XSD documents that are used in
the
<br>enterprise. We adopted XSD Eclipse very soon after it was released
and are
<br>very pleased with the decision.
<p>However, even in the enterprise there are lots of invalid XSDs out there.
<br>The problem is, is that most XSD editors and XML Validation tools do
not
<br>reject these schemas. However, Eclipse does. At first I was refusing
to
<br>accept XSDs that Eclipse did not like since we need to have semantically
<br>valid nodes in the schemas. After I realized that this was rather a
large
<br>chunk of the schemas in the enterprise, I took a different approach
of
<br>filtering out non-fatal Eclipse errors using regular expressions on
the
<br>error message. This only reduces this problem - every time a new schema
<br>comes along , there might be another non-fatal parse error.
<p>I would like change this approach and parse all schemas with their errors
<br>and decide how to limit the access to these bad constructs depending
on
<br>the severity of the error. I understand that XSDDiagnotics has a severity
<br>property with has several levels, but I'm finding that errors that
no-one
<br>complains about apart from Eclipse are either FATAL or ERROR. I would
like
<br>to have access to the whole list of possible errors that could occur
<br>whilst parsing so that I can decide how to deal with each error. Is
there
<br>any way that this can be exposed?
<p>Thanks,
<br>Hayden Marchant</blockquote>
</html>

--------------2D7A88BC6480983A11FC57BC--
Re: A Search for a more gentle approach to error handling using Eclipse XSD [message #576279 is a reply to message #26718] Sun, 24 August 2003 13:03 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 26285
Registered: July 2009
Senior Member
--------------2D7A88BC6480983A11FC57BC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hayden,

Yeah, there are sure a lot of bad schemas out there aren't there!

All the error messages are in plugins/org.eclipse.xsd/plugin.properties. They
typically have names based on keys in the spec's html, e.g., the message:

cvc-complex-type.3 = The attribute ''{0}'' is not permitted

can be located like this:

http://www.w3.org/TR/xmlschema-1/#cvc-complex-type

Hayden Marchant wrote:

> 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

--------------2D7A88BC6480983A11FC57BC
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hayden,
<p>Yeah, there are sure a lot of bad schemas out there aren't there!
<p>All the error messages are in plugins/org.eclipse.xsd/plugin.properties.&nbsp;
They typically have names based on keys in the spec's html, e.g., the message:
<blockquote>cvc-complex-type.3 = The attribute ''{0}'' is not permitted</blockquote>
can be located like this:
<blockquote><A HREF="http://www.w3.org/TR/xmlschema-1/#cvc-complex-type">http://www.w3.org/TR/xmlschema-1/#cvc-complex-type</A></blockquote>

<p><br>Hayden Marchant wrote:
<blockquote TYPE=CITE>I am developing a Metadata repository tool, and as
part of this, we
<br>support parsing and understanding of XSD documents that are used in
the
<br>enterprise. We adopted XSD Eclipse very soon after it was released
and are
<br>very pleased with the decision.
<p>However, even in the enterprise there are lots of invalid XSDs out there.
<br>The problem is, is that most XSD editors and XML Validation tools do
not
<br>reject these schemas. However, Eclipse does. At first I was refusing
to
<br>accept XSDs that Eclipse did not like since we need to have semantically
<br>valid nodes in the schemas. After I realized that this was rather a
large
<br>chunk of the schemas in the enterprise, I took a different approach
of
<br>filtering out non-fatal Eclipse errors using regular expressions on
the
<br>error message. This only reduces this problem - every time a new schema
<br>comes along , there might be another non-fatal parse error.
<p>I would like change this approach and parse all schemas with their errors
<br>and decide how to limit the access to these bad constructs depending
on
<br>the severity of the error. I understand that XSDDiagnotics has a severity
<br>property with has several levels, but I'm finding that errors that
no-one
<br>complains about apart from Eclipse are either FATAL or ERROR. I would
like
<br>to have access to the whole list of possible errors that could occur
<br>whilst parsing so that I can decide how to deal with each error. Is
there
<br>any way that this can be exposed?
<p>Thanks,
<br>Hayden Marchant</blockquote>
</html>

--------------2D7A88BC6480983A11FC57BC--
Previous Topic:Default values of attributes
Next Topic:best pratice on where to store property strings?
Goto Forum:
  


Current Time: Sun Dec 21 04:19:28 GMT 2014

Powered by FUDForum. Page generated in 0.01649 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software