Hi Neil, Thanks for the reply. Just one question about this. The schema in question includes tens of other schema files using relative URIs (they all exist in a large directory structure). So by what you write
"that system identifier fields are always set to the same value" presumably you mean that any SystemId will have the same exact URI and that the test for similarity is to first resolve the absolute path name for an InputSource? But how would you do this if a schema is retrieved over the web and it includes other schemas files with relative paths? Thanks, Elisha > -----Original Message----- > From: Neil Graham [mailto:[EMAIL PROTECTED] > Sent: Monday, October 31, 2005 11:08 AM > To: [email protected] > Subject: Re: Xerces issues handling recursive schema includes > > Hi Elisha, > > Recursive, or circular, includes are supposed to be handled properly by a > schema parser. While I'm not really active anymore on the code base, this > question does come up periodically, usually in the context of a set of > schemas that get loaded purely via schemaLocation hints, or via a user's > EntityResolver which doesn't set system identifiers on the InputSources it > returns to the parser. The usual way to get around this is to register a > custom EntityResolver instance, and take good care that system identifier > fields are always set to the same value when an InputSource is returned. > It's best if this is absolute, but I think a relative URI should work too. > The reason this is important is that the parser uses system identifiers > internally to figure out whether it's processed a schema document before. > > Cheers, > Neil > Neil Graham > Manager, C++ Compiler Front-End and Runtime Development > IBM Toronto Lab > Phone: 905-413-3519, T/L 969-3519 > E-mail: [EMAIL PROTECTED] > > > > > > "Elisha Berns" <[EMAIL PROTECTED]> > 10/30/2005 10:30 PM > Please respond to > c-dev > > > To > "Xerces C++ Development" <[email protected]> > cc > > Subject > Xerces issues handling recursive schema includes > > > > > > > Hi, > > I'm trying to determine both what Xerces does when it encounters > recursive schema includes and what to do about it because it causes some > problems. > > It appears that the XercesC schema parser creates multiple XSxxx type > objects for the same type if the schema files are included recursively. > In addition it would appear that the load time for a schema is much, > much slower in the presence of recursive includes. > > I get one 'proper' globally defined type object but multiple duplicates > when the type appears as a contained type (in a complexType definition). > The only way I know this now is because I get different pointer values > for the XSxxx object when this situation arises, even though they end up > pointing to the same type. > > Does anybody know firsthand whether there is any internal mechanism to > prevent this from happening (apparently not), and what can be done, at > present, to prevent this duplication from occuring. > > It has occurred to me that it might be a good idea to create a new type > of parser warning specifically regarding the issue of 'recursive > includes'. This of course only makes sense if there is a strong > consensus that this is a classic anti-pattern of XML Schema development > and should be avoided at all costs. I can see more or less how to > implement it outside of Xerces by constructing a dependency graph of the > schema files and testing for back-edges. So my question about this side > of things is whether there is any desire to make this test a built in > part of the parser to make the parser smarter about these things? > > Thanks for some feedback here. > > Elisha Berns > [EMAIL PROTECTED] > tel. (310) 556 - 8332 > fax (310) 556 - 2839 > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
