Maybe an example will be clearer.
The instance document is, relative to some subtree of the file system, in
instances/articles/doc1.xml
There is a set of schemas that apply in
schemas/{a,b,c,d}.xsd
Suppose a.xsd imports b.xsd, and in addition, doc1.xml refers to
components from nsa, the namespace of a, and nsb, the namespace of b.
So there are schema locations of the form {nsa, ../../schemas/a.xsd
nsb ../../schemas/b.xsd, ... }
Now when the reference from doc1 -> nsb is found, the schema locations
can be used to find b.xsd. If the reference from a.xsd -> nsb is
found, the schema locations will not work, because the location is
incorrect relative to the location of a.xsd. You couldn't solve the
problem by changing the schema locations to look like {nsa,
../../schemas/a.xsd nsb ./b.xsd, ... } because the doc1 -> nsb
reference would fail. However, in the first case, if the parser is
caching grammars, and the reference from doc1 -> nsb has already been
processed, the a.xsd -> nsb reference might not be a validation error
-- the schema locations are only a hint to the parser, and if it has
located and parsed the right grammar already, it can use it.
These are the problems with using relative URLs for the schema
locations, except in certain special cases. For example, if the
instance doc is
instances/doc1.xml
and the schemas are in
schemas/{a,b,c,...}.xsd
Then these schema locations: {nsa ../schemas/a.xsd nsb
../schemas/b.xsd ...} will work successfully, but only because the
paths work whether the reference is from the instance doc or a schema
doc.
Jeff
On 10/8/07, Chris Bray <[EMAIL PROTECTED]> wrote:
> 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]
