<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">I really didn't see anything in their
replies that indicated a workaround. The closest he came was
indicating that if we removed some part of the ee5 schema, it'd be
invalid.... but that doesn't sound like a workaround. It sounds
like another way to make something invalid. <br>
<br>
On 03/03/2016 06:26 PM, Max Rydahl Andersen wrote:<br>
</div>
<blockquote
cite="mid:E2E46187-AFC3-4C83-885A-8E6E640B3D84@redhat.com"
type="cite">
<div class="markdown">
<p dir="auto">On 2 Mar 2016, at 3:13, Rob Stryker wrote:</p>
<blockquote>
<p dir="auto">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.</p>
</blockquote>
<p dir="auto">cool - getting the conversation started is great!</p>
<blockquote>
<p dir="auto">Either way, this thread seems to indicate Jesper
and Keith Chong are the guys to ping when we have further
questions.</p>
</blockquote>
<p dir="auto">Did you try what Keith suggested to see if that
gave a workaround ? </p>
<p dir="auto">/max</p>
<blockquote>
<ul>
<li>Rob</li>
</ul>
<p dir="auto">-------- Forwarded Message --------<br>
Subject: Re: [wtp-dev] Question on XML Validation and oracle
xsds<br>
Date: Thu, 25 Feb 2016 23:43:07 +0100<br>
From: Jesper Steen Møller <a moz-do-not-send="true"
href="mailto:jesper@selskabet.org">jesper@selskabet.org</a><br>
Reply-To: General discussion of project-wide or
architectural issues. <a moz-do-not-send="true"
href="mailto:wtp-dev@eclipse.org">wtp-dev@eclipse.org</a><br>
To: General discussion of project-wide or architectural
issues. <a moz-do-not-send="true"
href="mailto:wtp-dev@eclipse.org">wtp-dev@eclipse.org</a></p>
<p dir="auto">Hi Keith and Rob<br>
(You probably know all this already, but Iâll just add
what I know)</p>
<p dir="auto">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.</p>
<p dir="auto">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:</p>
<p dir="auto">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.<br>
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.<br>
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.<br>
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.<br>
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?<br>
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.</p>
<p dir="auto">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.</p>
<p dir="auto">We might be able to improve the error handling
and logging side of things, but only by tying deeper into
the Xerces code.</p>
<p dir="auto">-Jesper</p>
<blockquote>
<p dir="auto">On 25. feb. 2016, at 19.01, Keith Chong
<<a class="moz-txt-link-abbreviated" href="mailto:kchong@ca.ibm.com">kchong@ca.ibm.com</a> <a class="moz-txt-link-rfc2396E" href="mailto:kchong@ca.ibm.com"><mailto:kchong@ca.ibm.com></a>>
wrote:</p>
<p dir="auto">Hi Rob</p>
<p dir="auto">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:</p>
<p dir="auto">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">https://www.w3.org/TR/xmlschema-1/#src-resolve</a></p>
<p dir="auto">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.</p>
<p dir="auto">3,4,5) are somewhat related. I'm looking into
this.</p>
<p dir="auto">Regards,<br>
Keith Chong<br>
WTP Web Services</p>
<p dir="auto"><graycol.gif>Rob Stryker ---02/16/2016
12:58:33 PM---Hi All: So after running into validation
issues for our users' xml files using</p>
<p dir="auto">From: Rob Stryker <<a class="moz-txt-link-abbreviated" href="mailto:rob.stryker@redhat.com">rob.stryker@redhat.com</a>
<a class="moz-txt-link-rfc2396E" href="mailto:rob.stryker@redhat.com"><mailto:rob.stryker@redhat.com></a>><br>
To: "General discussion of project-wide or architectural
issues." <<a class="moz-txt-link-abbreviated" href="mailto:wtp-dev@eclipse.org">wtp-dev@eclipse.org</a>
<a class="moz-txt-link-rfc2396E" href="mailto:wtp-dev@eclipse.org"><mailto:wtp-dev@eclipse.org></a>><br>
Date: 02/16/2016 12:58 PM<br>
Subject: [wtp-dev] Question on XML Validation and oracle
xsds<br>
Sent by: <a moz-do-not-send="true"
href="mailto:wtp-dev-bounces@eclipse.org">wtp-dev-bounces@eclipse.org</a>
<a moz-do-not-send="true"
href="mailto:wtp-dev-bounces@eclipse.org">wtp-dev-bounces@eclipse.org</a></p>
<hr>
<p dir="auto">Hi All:</p>
<p dir="auto">So after running into validation issues for
our users' xml files using<br>
our schema for week after week, I finally decided to dig
in a little and<br>
see how the JEE distribution handles validation of schema
without so<br>
many upstream dependencies. It's clear that if a parent or
referenced<br>
schema is invalid, the user will experience obscure
validation errors<br>
when developing their own webapps etc.</p>
<p dir="auto">With that in mind I opened<br>
<a moz-do-not-send="true"
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=487851">https://bugs.eclipse.org/bugs/show_bug.cgi?id=487851</a></p>
<p dir="auto">The usecase is that I simply took oracle's<br>
javaee_web_services_client_1_2.xsd from<br>
<a moz-do-not-send="true"
href="http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/javaee_web_services_client_1_2.xsd">http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/javaee_web_services_client_1_2.xsd</a><br>
and tried to put it in a dynamic web project and let the
validator work<br>
its magic.</p>
<p dir="auto">I wouldn't be posting here if it succeeded ;)</p>
<p dir="auto">The questions are basically:</p>
<p dir="auto">1) Why are oracle's xsd's failing to validate?
Are they really all<br>
invalid?</p>
<p dir="auto">2) Why has nobody in the world asked Oracle to
fix them?</p>
<p dir="auto">3) How do we/you, as consumers / extenders of
wtp, prevent errors in<br>
oracle's (or other upstream) xsd's from cascading down to
our respective<br>
jee / appserver-specific schema when our schema import,
extend, or<br>
reference upstream failing xsds?</p>
<p dir="auto">4) Is this an error in source-editing plugins
for not mapping<br>
directly to the most commonly used jee namespaces? Would
that even fix<br>
the issue? (It didn't when I tried it but maybe I was
doing it wrong).</p>
<p dir="auto">5) If oracle won't fix their incomplete xsd's,
is it reasonable for<br>
source-editing to do it, to make sure each and every one
validate<br>
correctly, and that, by extension, all other schema that
reference,<br>
import, or otherwise make use of oracles' schema won't be
hit by a<br>
series of cascading validation errors?</p>
<p dir="auto">I suppose it's possible our product is simply
"doing it wrong", but the<br>
fact that simply placing an official javaee oracle xsd
into a clean JEE<br>
Mars eclipse environment fails validation is indicative to
me that<br>
something bigger is going on here.</p>
<ul>
<li>Rob Stryker
JBoss Tools And Other Cool Stuff
_______________________________________________
wtp-dev mailing list
<a moz-do-not-send="true"
href="mailto:wtp-dev@eclipse.org">wtp-dev@eclipse.org</a>
<a moz-do-not-send="true"
href="mailto:wtp-dev@eclipse.org">wtp-dev@eclipse.org</a>
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
<a moz-do-not-send="true"
href="https://dev.eclipse.org/mailman/listinfo/wtp-dev">https://dev.eclipse.org/mailman/listinfo/wtp-dev</a></li>
</ul>
<hr>
<p dir="auto">wtp-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:wtp-dev@eclipse.org">wtp-dev@eclipse.org</a>
<a moz-do-not-send="true"
href="mailto:wtp-dev@eclipse.org">wtp-dev@eclipse.org</a><br>
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit<br>
<a moz-do-not-send="true"
href="https://dev.eclipse.org/mailman/listinfo/wtp-dev">https://dev.eclipse.org/mailman/listinfo/wtp-dev</a></p>
</blockquote>
<hr>
<p dir="auto">jbosstools-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:jbosstools-dev@lists.jboss.org">jbosstools-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/jbosstools-dev">https://lists.jboss.org/mailman/listinfo/jbosstools-dev</a></p>
</blockquote>
<p dir="auto">/max<br>
<a moz-do-not-send="true" href="http://about.me/maxandersen">http://about.me/maxandersen</a></p>
</div>
</blockquote>
<br>
</body>
</html>