From the application perspective it seems kinda burdensome to have to know that for some particular input source that the parser isn't going to close the resources associated with it, but for most others it is. If you look at the javadoc for InputSource it says: "An InputSource object belongs to the application: the SAX parser shall never modify it in any way (it may modify a copy if necessary). However, standard processing of both byte and character streams is to close them on as part of end-of-parse cleanup, so applications should not attempt to re-use such streams after they have been handed to a parser."
I think even if Xerces isn't going to read from an inputsource it should call close on the byte/character streams in it, as that's what an application expects. An application can of course work around this via one means or another once they discover the problem, but its certainly unexpected behavior. I believe internal implementation details such has the way Xerces is handling the duplicate include shouldn't have unexpected side effects that the application has to handle. Micah On Jan 13, 2010, at 10:49 PM, Michael Glavassevich wrote: > There's nothing wrong with this schema. > > Xerces will determine that both includes for "c.xsd" point to the same URI > and only load and process the schema document once. The comparison of the > URIs is done after any redirection from an entity resolver which could choose > to map the two includes of "c.xsd" to different URIs. This is why the > resolver gets called twice. > > The InputSource returned by the entity resolver for the second include of > "c.xsd" is ignored if it has the same system ID (URI) as the one returned for > the first include of "c.xsd". An InputStream attached to the second > InputSource would never be accessed (i.e Xerces doesn't call any methods on > it including close()). If it's important that these streams (that are never > read) be closed the application is able to manage that itself. > > Thanks. > > Michael Glavassevich > XML Parser Development > IBM Toronto Lab > E-mail: mrgla...@ca.ibm.com > E-mail: mrgla...@apache.org > > Mukul Gandhi <muk...@apache.org> wrote on 01/13/2010 10:34:46 PM: > > > On Tue, Jan 12, 2010 at 4:03 AM, Micah Koch <mk...@motive.com> wrote: > > > So I have a few questions, and one way or another there seems to > > be a bug. I have a schema where > > > a.xsd includes b.xsd and c.xsd > > > b.xsd includes c.xsd > > > > > > 1) c.xsd gets included twice, is this allowed? > > > > I did a quick test of this with Xerces-J. Here are the details of my test: > > > > a.xsd > > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";> > > > > <xs:include schemaLocation="b.xsd" /> > > <xs:include schemaLocation="c.xsd" /> > > > > <xs:complexType name="A"> > > <xs:sequence> > > <xs:element name="z" type="xs:string" /> > > </xs:sequence> > > </xs:complexType> > > > > <xs:element name="x" type="A" /> > > > > </xs:schema> > > > > b.xsd > > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";> > > > > <xs:include schemaLocation="c.xsd" /> > > > > <xs:complexType name="B"> > > <xs:sequence> > > <xs:element name="y" type="xs:string" /> > > </xs:sequence> > > </xs:complexType> > > > > </xs:schema> > > > > c.xsd > > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";> > > > > <xs:complexType name="C"> > > <xs:sequence> > > <xs:element name="x" type="xs:string" /> > > </xs:sequence> > > </xs:complexType> > > > > </xs:schema> > > > > a.xml > > <x> > > <z>hello</z> > > </x> > > > > When I validated, a.xml with a.xsd, the validation passes and Xerces > > doesn't report an error. > > > > So the use case you pointed, seems to be allowed by Xerces-J (and I > > believe, also by XSD language). > > > > But as I wrote earlier, this kind of schema inclusions doesn't look a > > good design, as we are including a schema twice. Only once schema > > inclusion should be sufficient, to get the required schema components > > into the parent schema. > > > > > > > > -- > > Regards, > > Mukul Gandhi > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org > > For additional commands, e-mail: j-users-h...@xerces.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
