Community
Participate
Working Groups
Build Identifier: 20110301-1815 This is a bug spun-out from bug #196353. For XML Schema editing, different intepretations of relative paths are used by: -- code completion (code assist): assumes paths relative to Eclipse's platform filesystem (i.e. folder hierarchy as seen in Project Explorer) -- validation: assumes paths relative to the underlying file system location As bug #196353 comments suggest, the correct behaviour should be to use platform URIs in all cases; i.e., the validation resolution is wrong. Reproducible: Always Steps to Reproduce: 1. Create any project where the Eclipse (platform) file structure and filesystem structure are different (e.g. have one normal folder and one linked folder linked to a path outside the Eclipse workspace). 2. Have an XML schema file in the normal folder include one in the linked folder via a relative path. 3. Observe that code completion works when the relative path matches Eclipse's Project Explorer view, but schema validation fails. 4. Observe that the opposite is true if a relative path relative to the underlying file system is used. As a concrete example, I have the following project: Test_XML [In Eclipse workspace /home/user/Working/EclipseWorkspace] xml [Folder] test.xsd xmlBase [Linked folder to /home/user/Temp/xmlBase] test2.xsd test.xsd contains: <?xml version="1.0" encoding="UTF-8"?> <schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.example.org/test" xmlns:tns="http://www.example.org/test" elementFormDefault="qualified"> <complexType name="ComplexTest"> <sequence> <element name="a" type="string" /> <element name="b" type="string" /> </sequence> </complexType> </schema> test.xsd contains: <?xml version="1.0" encoding="UTF-8"?> <schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.example.org/test" xmlns:tns="http://www.example.org/test" elementFormDefault="qualified"> <!-- <include schemaLocation="../xmlBase/test2.xsd" /> --> <include schemaLocation="../../../../Temp/xmlBase/test2.xsd" /> <complexType name="RefTest"> <sequence> <element name="a" type="tns:ComplexTest" /> </sequence> </complexType> </schema> See the <include> entry in test.xsd. It is currently set to the filesystem relative path (commented out entry for the Eclipse relative path).
> > test.xsd contains: > > <?xml version="1.0" encoding="UTF-8"?> > <schema xmlns="http://www.w3.org/2001/XMLSchema" > targetNamespace="http://www.example.org/test" > xmlns:tns="http://www.example.org/test" elementFormDefault="qualified"> > > <complexType name="ComplexTest"> > <sequence> > <element name="a" type="string" /> > <element name="b" type="string" /> > </sequence> > </complexType> > </schema> > Oops: should be test2.xsd contains.
Note that the same filesystem relative paths are required for creating an XML file from a schema file. (I presume that, under the covers, this uses the same code as for schema validation but, if not, it also needs fixing here.) To reproduce that, change the main contents of test.xsd to : <element name="refTest"> <complexType> <sequence> <element name="a" type="tns:ComplexTest" /> </sequence> </complexType> </element> Then try to add a new XML file based on test.xsd as the schema. It requires the include entry to have the filesystem relative path, not the Eclipse platform one.
Has no-one yet assessed this bug / planned when to fix it? It persists in the latest Indigo SR1 release. The related bug 196353 has also not been touched since March 2011. I wanted to update this to show it's still a problem in Indigo SR1, but the Version field only goes up to 3.4. What's all that about?? Is this bug system somehow defunct?
(In reply to comment #3) > Has no-one yet assessed this bug / planned when to fix it? It persists in the > latest Indigo SR1 release. The related bug 196353 has also not been touched > since March 2011. > > I wanted to update this to show it's still a problem in Indigo SR1, but the > Version field only goes up to 3.4. What's all that about?? Is this bug system > somehow defunct? The Version field says which version in which the problem was found. 3.4 is the version still in development, so higher versions are currently of no use. Indigo SR1 contains 3.3.1.
