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() method for an example, how the EntityResolver can be used. Sorry, Jochen Daniel Barclay wrote: > 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 includes B, and where B includes A, the parser should see that A has > already been read and should be skipped.) > > However, the URI reference used to find A.xsd originally was different > from the URI reference used to try to include A.xsd from B.xsd. The > first URI reference was the (non-relative) URI "file:///.../A.xsd"; the > second URI reference was the relative reference "A.xsd". Since those URI > references were not the same, the parser didn't recognize that the document > had already been read. > > It seems that when checking an include directive, the parser should > resolve the given URI reference (a URI or a relative reference) against > the appropriate base URL, so that if the given URI reference is a relative > reference, it will be resolved into a full (non-relative) URI. > > Daniel > >> Jochen Wiedmann wrote: >> >>>> It seems JaxMeXS can't handle schema files that recursively include >>>> each other (e.g., A.xsd includes B.xsd, B.xsd includes A.xsd). >>> >>> >>> >>> >>> You are right. The check was implemented for xs:import, but not for >>> xs:include. Fixed in the 0.4 branch and in HEAD. >> >> >> >> Does the fix just prevent the endless recursion, or does it also handle >> inclusion correctly? >> >> I tried manually back-porting the changes to 0.3.1. When I ran my >> original test case, it did prevent endless recursion. >> >> However, when I add a declaration to _one_ of the schema files, I get >> an error about duplicate definitions. >> >> Specifically, when I add a declaration to file at which parsing >> starts, I get the error. When I add the declaration to a file >> that is reached only by inclusion, I don't get the error. >> >> - A.xsd includes B.xsd >> - B.xsd includes A.xsd >> - A.xsd defines an element E >> - starting parsing at A.xsd yields an error about E being a duplicate >> - starting parsing at B.xsd does not yield such an error >> >> Assuming I didn't back-port the change wrong, it seems that the >> parser forgets to include the starting file in the set of files >> for which it should skip includes (because they have already been >> read). >> >> >> >> Here is a pair of test files: >> >> ----------------------------------------------------------------------- >> RecursiveIndirectly1.xsd_ >> ---------- >> <xsd:schema >> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; >> > >> <xsd:include schemaLocation="RecursiveIndirectly2.xsd" /> >> <xsd:element name="In1"/> >> >> </xsd:schema> >> ----------------------------------------------------------------------- >> RecursiveIndirectly2.xsd: >> ---------- >> <xsd:schema >> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; >> > >> <xsd:include schemaLocation="RecursiveIndirectly1.xsd" /> >> >> <!--xsd:element name="In2"/--> >> >> </xsd:schema> >> -------------------------------------------------------------------- >> >> >> Daniel >> >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
