In addition to the problem below (in the quoted part), the parser
doesn't seem to be resolving URI references to (non-relative) URIs
before comparing them.
I tried handling the problem below by adding the URI of the originally
parsed document to the set of documents to skip. (When A is parsed,
A i
Hi, Daniel,
I have committed another patch to 0.4 and HEAD, which should fix the
problem below. The reason was, that the outer schemas system ID wasn't
remembered.
A unit test is available, see the method
ParserTest.testRecursiveXsInclude()
Jochen
Daniel Barclay wrote:
> Jochen Wiedmann wr
Hi, Daniel,
I am sorry, but the problem below is clearly beyond the scope of the
schema parser. The parser will never be able to know, that
"file://.../a.xsd"
and
"a.xsd"
are the same file. These things are exactly what an EntityResolver is
good for. Again, see the testRecursiveXsInclude
Daniel Barclay wrote:
> Jochen Wiedmann wrote:
>
>> Daniel, I totally agree with your points. However, do you think it
>> would require more time to create a patch than writing this mail? :-)
>
>
> Definitely. (Not everyone is already set up for editing and checking in
> JaxMeXS code, and fami
Jochen Wiedmann wrote:
...
You explain the authors the most with patches.
I don't see how that could be true.
A report that includes the problem text, suggested replacement text,
an explanation of why the problem text isn't right and why the
replacement text is right (and maybe reminder that many
On Wed, 2005-04-27 at 17:38 -0400, Daniel Barclay wrote:
> Jochen Wiedmann wrote:
>
> > ...
>
> > You explain the authors the most with patches.
>
> I don't see how that could be true.
>
> A report that includes the problem text, suggested replacement text,
> an explanation of why the problem
