Just a sanity check... What version of Xerces-J are you using? Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: [EMAIL PROTECTED] E-mail: [EMAIL PROTECTED]
Chris Bray <[EMAIL PROTECTED]> wrote on 10/08/2007 12:25:43 PM: > Jeff. > > My comments inline. > > Chris > > Jeff Greif wrote: > > When a relative URL is used for the location of an imported schema, it > > is supposed to be relative to the URL of the importing document. So > > if your instance document directly references the namespaces of one or > > more schemas for validation, whose URLs are interpreted relative to > > the location of the instance document. Probably some of the schemas > > > So my instance document _should_ have relative paths to the individual > schemas in it's schemaLocation? > Does the fact that Xerces is "changing" the base path to that of the > first specified schema for each subsequent schema constitute a bug? > Should I log this somewhere more formal? > > contain <xsd:import> elements; those would require URLs relative to > > the schema importing them. > > > Each of those schemas then further includes others using <xsd:import> > and <xsd:include> (for example core.xsd actually includes about 30 or 40 > smaller schemas from ./Core/schemaname.xsd) and this works as I'd > expected it to. > > Some of the schemas might be referenced both in the instance document > > and in imports from other schemas referenced in the instance document. > > I'm not sure there's a specification of where they must be found if > > relative URLs are used. This may depend on the ordering of processing > > of those references by the parser/validator. > > > When that is the case I am 100% sure that both the instance document and > the "sub schemas" refer to the exact same document, so it shouldn't > matter which of the references Xerces is using, it will resolve to the > same schema anyway. > > There is a section in the XML Schema 1.0 spec addressing this issue. > > > > Jeff > > > > > > > > On 10/8/07, Chris Bray <[EMAIL PROTECTED]> wrote: > > > >> Parshant, > >> > >> Changing the working dir of the JVM doesn't seem to make any difference, > >> using dom.Counter from the Xerces-J samples the parser still seems to > >> change the working dir first to wherever the xml file is located, then > >> to wherever the first xsd file specified is located and need all > >> subsequent locations to be relative to that. > >> > >> Absolute paths work fine but I'm trying to include these files bundled > >> in with a set of schema as examples of how to use the format, hence I > >> don't know where my users will unzip the archives to (C:\Users\username, > >> c:\projects\projectname\, /usr/local/projects, /home etc) so I can't set > >> absolute paths in my distributed files. > >> > >> I was hoping to not need to actually write my own parsing program, just > >> use the output from dom.Counter and a schemaLocation hint (which fits my > >> needs perfectly) since I'm not really a Java developer. > >> > >> I saw that jEdit page but I'd rather make my schemas validate against a > >> standard Xerces installation than modify my jEdit installation to make > >> them work, I feel this would be more useful for my users. > >> > >> Chris > >> > >> > >> Prashant Reddy wrote: > >> > >>> I think the relative paths you have specified in the schemaLocation will > >>> be resolved against the "working dir". The working dir is usually the > >>> directory at the cmd prompt when you launched the JVM. > >>> > >>> Have you tried giving absolute path to the XSD files ? > >>> > >>> A more portable solution to finding schema files locally is to use > >>> EntityResolver[1]. > >>> > >>> If you are using JAXP 1.3/ JDK 1.5+ see : > >>> https://jaxp.dev.java.net/article/jaxp-1_3-article.html > >>> > >>> > >>> [1]:http://java.sun.com/j2se/1.5. > 0/docs/api/org/xml/sax/EntityResolver.html > >>> > >>> Hope this helps. > >>> -Prashant > >>> > >>> > >>> On Mon, 2007-10-08 at 13:17 +0100, Chris Bray wrote: > >>> > >>> > >>>> All. > >>>> > >>>> Please go easy on me as I'm a newbie here, if this is a really obvious > >>>> problem I'm really sorry! > >>>> I've been using Xerces to validate XML for a while now, and I've found a > >>>> troublesome scenario. > >>>> > >>>> In the top of my xml files I have a line specifying the location of the > >>>> external schemas required for this xml file like so: > >>>> > >>>> xsi:schemaLocation="http://www.diggsml.org/0.9.2 > >>>> ../Schemas/diggs/core.xsd http://www.diggsml.org/0.9.2/geotechnical > >>>> ../Schemas/diggs/geotechnical.xsd " > >>>> > >>>> In this case specifying two namespaces and their associated schema files > >>>> (files exist and paths are correct). > >>>> > >>>> However this doesn't work using Xerces. I am required to change my > >>>> schemaLocation attribute so that the first path points to its xsd, then > >>>> subsequent entries are relative to that first xsd, not to the current > >>>> file, like so: > >>>> > >>>> xsi:schemaLocation=" http://www.diggsml.org/0.9.2 > >>>> ../Schemas/diggs/core.xsd http://www.diggsml.org/0.9.2/geotechnical > >>>> ../geotechnical.xsd " > >>>> > >>>> Is there any way I can change this to work like the first example, as > >>>> other parsers (XMLSpy and Stylus Studio in particular) require the first > >>>> syntax, all paths relative to current doc, what I believe to be correct > >>>> behaviour. I don't know how to build Xerces-J from source to fix(?) this > >>>> myself but I'd be willing to try if anyone can help me get it building. > >>>> > >>>> Since my customers are all using XMLSpy etc I'm having to produce my > >>>> example files in the earlier syntax, stopping my from using Xerces to > >>>> validate them. > >>>> > >>>> As the biggest advocate of Free/OpenSource software in our group (jEdit > >>>> with Xerces plugin in particular) I really don't want to have to change > >>>> to use XMLSpy or Stylus Studio but this is quite awkward for me! > >>>> > >>>> That ended up being a longer mail than I'd expected! I hope you can > >>>> help, if there's any more information you need (or a small set of sample > >>>> files) let me know. > >>>> > >>>> > >>>> Chris Bray > >>>> Software Engineer (DIGGS Project) > >>>> Keynetix Ltd. > >>>> > > > --------------------------------------------------------------------- > 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]
