<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
There have been three responses on wtp-dev about my xml schema
question. They seem to indicate the problem is with the xml spec
in general and the different behaviors in various libraries like
xerces.<br>
<br>
Either way, this thread seems to indicate Jesper and Keith Chong are
the guys to ping when we have further questions. <br>
<br>
- Rob <br>
<div class="moz-forward-container"><br>
<br>
-------- Forwarded Message --------
<table class="moz-email-headers-table" border="0" cellpadding="0"
cellspacing="0">
<tbody>
<tr>
<th nowrap="nowrap" valign="BASELINE" align="RIGHT">Subject:
</th>
<td>Re: [wtp-dev] Question on XML Validation and oracle xsds</td>
</tr>
<tr>
<th nowrap="nowrap" valign="BASELINE" align="RIGHT">Date: </th>
<td>Thu, 25 Feb 2016 23:43:07 +0100</td>
</tr>
<tr>
<th nowrap="nowrap" valign="BASELINE" align="RIGHT">From: </th>
<td>Jesper Steen Møller <a class="moz-txt-link-rfc2396E" href="mailto:jesper@selskabet.org"><jesper@selskabet.org></a></td>
</tr>
<tr>
<th nowrap="nowrap" valign="BASELINE" align="RIGHT">Reply-To:
</th>
<td>General discussion of project-wide or architectural
issues. <a class="moz-txt-link-rfc2396E" href="mailto:wtp-dev@eclipse.org"><wtp-dev@eclipse.org></a></td>
</tr>
<tr>
<th nowrap="nowrap" valign="BASELINE" align="RIGHT">To: </th>
<td>General discussion of project-wide or architectural
issues. <a class="moz-txt-link-rfc2396E" href="mailto:wtp-dev@eclipse.org"><wtp-dev@eclipse.org></a></td>
</tr>
</tbody>
</table>
<br>
<br>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="">Hi Keith and Rob</div>
<div class="">(You probably know all this already, but Iâll just
add what I know)</div>
<div class=""><br class="">
</div>
<div class="">I touched some of the validator code a few years
back: The number of URI resolver interfaces is horrible - one
from Platform, one from Xerces and one from WTP as I recall),
each introducing a slight impedance mismatch.</div>
<div class=""><br class="">
</div>
<div class="">Really, the XML Schema spec is at fault, by being so
vague on the semantics of namespaces and schema locations, so
Xerces can get away with their import policies (first import per
namespace wins). So, the order of imports matter, and this
affects the effective scope of each import:</div>
<div class=""><br class="">
</div>
<div class="">Imagine this scenario where you have to
âend-userâ schemas A.xsd and B.xsd. A relies on namespace C
and D, B only on C.</div>
<div class="">A.xsd imports A_C.xsd, which in turn also imports
A_D.xsd (say, they were meant to be used together), and all is
great, you can validate A.xsd by itself â no errors.</div>
<div class="">B.xsd import a different file B_C.xsd, which
doesnât contain an import for namespace D, but and doesnât
need to. B.xsd also validates by itself.</div>
<div class="">Now we make E.xsd which import A.xsd and B.xsd and
uses namespaces A,B,C, and D. This should be just fine, and
E.xsd can validate on its own. The import of B_C.xsd from B.xsd
is ignored.</div>
<div class="">Now flip the imports of A.xsd and B.xsd. This will
cause the namespace for C to be imported from B_C.xsd, and E.xsd
will no longer validate, since it never sees the import of
A_D.xsd from A_C.xsd. Wonderful, isnât it?</div>
<div class="">Now, some short-sighted people even practice
splitting namespace contents up into separate files, for greater
âcomposabilityâ, but the major stacks donât support that.</div>
<div class=""><br class="">
</div>
<div class="">In Eclipse, the XML Catalog support was supposed to
be able to alleviate this, by allowing the end users manage the
schemas themselves (Iâd rather not have my IDE be dependent on
some external server, even if we cache the result). Also, there
is an extension point available for providing schemas (based on
namespace OR schema location IIRC) along with plug-ins.</div>
<div class=""><br class="">
</div>
<div class="">We might be able to improve the error handling and
logging side of things, but only by tying deeper into the Xerces
code.</div>
<div class=""><br class="">
</div>
<div class="">-Jesper<br class="">
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 25. feb. 2016, at 19.01, Keith Chong <<a
moz-do-not-send="true" href="mailto:kchong@ca.ibm.com"
class=""><a class="moz-txt-link-abbreviated" href="mailto:kchong@ca.ibm.com">kchong@ca.ibm.com</a></a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">
<p class="">Hi Rob<br class="">
<br class="">
The XML Schema validator is based on the Xerces
validator (parser), so I had a discussion with one
of the developers. I'll try to answer your
questions:<br class="">
<br class="">
1) The validator resolves components via imports so
if the import is missing, the schema is invalid.
See: <a moz-do-not-send="true"
href="https://www.w3.org/TR/xmlschema-1/#src-resolve"
class="">https://www.w3.org/TR/xmlschema-1/#src-resolve</a><br
class="">
<br class="">
2) This is a good question. I suspect that this
client schema on its own is 'invalid' and is never
intended to be used that way. (There are no global
elements too so you can't create an instance
document from it). The EE 5 schema includes this
schema, so it is valid as part of 'the whole'. eg.
If you remove the include directive from the EE5
schema, then the EE5 schema is invalid.<br class="">
<br class="">
3,4,5) are somewhat related. I'm looking into this.
<br class="">
<br class="">
Regards,<br class="">
Keith Chong<br class="">
WTP Web Services<br class="">
<br class="">
<br class="">
<span
id="cid:1__=8FBBF5F7DFCB55128f9e8a93df938690918c8FB@"><graycol.gif></span><font
class="" color="#424282">Rob Stryker ---02/16/2016
12:58:33 PM---Hi All: So after running into
validation issues for our users' xml files using</font><br
class="">
<br class="">
<font class="" color="#5F5F5F" size="2">From: </font><font
class="" size="2">Rob Stryker <<a
moz-do-not-send="true"
href="mailto:rob.stryker@redhat.com" class=""><a class="moz-txt-link-abbreviated" href="mailto:rob.stryker@redhat.com">rob.stryker@redhat.com</a></a>></font><br
class="">
<font class="" color="#5F5F5F" size="2">To: </font><font
class="" size="2">"General discussion of
project-wide or architectural issues." <<a
moz-do-not-send="true"
href="mailto:wtp-dev@eclipse.org" class=""><a class="moz-txt-link-abbreviated" href="mailto:wtp-dev@eclipse.org">wtp-dev@eclipse.org</a></a>></font><br
class="">
<font class="" color="#5F5F5F" size="2">Date: </font><font
class="" size="2">02/16/2016 12:58 PM</font><br
class="">
<font class="" color="#5F5F5F" size="2">Subject: </font><font
class="" size="2">[wtp-dev] Question on XML
Validation and oracle xsds</font><br class="">
<font class="" color="#5F5F5F" size="2">Sent by: </font><font
class="" size="2"><a moz-do-not-send="true"
href="mailto:wtp-dev-bounces@eclipse.org"
class="">wtp-dev-bounces@eclipse.org</a></font><br
class="">
</p>
<hr style="color:#8091A5; " class="" size="2"
noshade="noshade" width="100%" align="left"><br
class="">
<br class="">
<br class="">
<tt class="">Hi All:<br class="">
<br class="">
So after running into validation issues for our
users' xml files using <br class="">
our schema for week after week, I finally decided to
dig in a little and <br class="">
see how the JEE distribution handles validation of
schema without so <br class="">
many upstream dependencies. It's clear that if a
parent or referenced <br class="">
schema is invalid, the user will experience obscure
validation errors <br class="">
when developing their own webapps etc.<br class="">
<br class="">
With that in mind I opened <br class="">
</tt><tt class=""><a moz-do-not-send="true"
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=487851"
class="">https://bugs.eclipse.org/bugs/show_bug.cgi?id=487851</a></tt><tt
class=""><br class="">
<br class="">
The usecase is that I simply took oracle's <br
class="">
javaee_web_services_client_1_2.xsd from <br
class="">
</tt><tt class=""><a moz-do-not-send="true"
href="http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/javaee_web_services_client_1_2.xsd"
class="">http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/javaee_web_services_client_1_2.xsd</a></tt><tt
class=""> <br class="">
and tried to put it in a dynamic web project and let
the validator work <br class="">
its magic.<br class="">
<br class="">
I wouldn't be posting here if it succeeded ;)<br
class="">
<br class="">
The questions are basically:<br class="">
<br class="">
1) Why are oracle's xsd's failing to validate?
Are they really all <br class="">
invalid?<br class="">
<br class="">
2) Why has nobody in the world asked Oracle to
fix them?<br class="">
<br class="">
3) How do we/you, as consumers / extenders of
wtp, prevent errors in <br class="">
oracle's (or other upstream) xsd's from cascading
down to our respective <br class="">
jee / appserver-specific schema when our schema
import, extend, or <br class="">
reference upstream failing xsds?<br class="">
<br class="">
4) Is this an error in source-editing plugins for
not mapping <br class="">
directly to the most commonly used jee namespaces?
Would that even fix <br class="">
the issue? (It didn't when I tried it but maybe I
was doing it wrong).<br class="">
<br class="">
5) If oracle won't fix their incomplete xsd's, is
it reasonable for <br class="">
source-editing to do it, to make sure each and every
one validate <br class="">
correctly, and that, by extension, all other schema
that reference, <br class="">
import, or otherwise make use of oracles' schema
won't be hit by a <br class="">
series of cascading validation errors?<br class="">
<br class="">
I suppose it's possible our product is simply "doing
it wrong", but the <br class="">
fact that simply placing an official javaee oracle
xsd into a clean JEE <br class="">
Mars eclipse environment fails validation is
indicative to me that <br class="">
something bigger is going on here.<br class="">
<br class="">
- Rob Stryker<br class="">
JBoss Tools And Other Cool Stuff<br class="">
_______________________________________________<br
class="">
wtp-dev mailing list<br class="">
<a moz-do-not-send="true"
href="mailto:wtp-dev@eclipse.org" class="">wtp-dev@eclipse.org</a><br
class="">
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit<br
class="">
</tt><tt class=""><a moz-do-not-send="true"
href="https://dev.eclipse.org/mailman/listinfo/wtp-dev"
class="">https://dev.eclipse.org/mailman/listinfo/wtp-dev</a></tt><tt
class=""><br class="">
<br class="">
</tt><br class="">
<br class="">
</div>
_______________________________________________<br
class="">
wtp-dev mailing list<br class="">
<a moz-do-not-send="true"
href="mailto:wtp-dev@eclipse.org" class="">wtp-dev@eclipse.org</a><br
class="">
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit<br class="">
<a class="moz-txt-link-freetext" href="https://dev.eclipse.org/mailman/listinfo/wtp-dev">https://dev.eclipse.org/mailman/listinfo/wtp-dev</a></div>
</blockquote>
</div>
<br class="">
</div>
</div>
<br>
</div>
<br>
</body>
</html>