Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
XML Commons Resolver 1.1.0
-
None
-
None
-
Operating System: Windows XP
Platform: PC
-
26631
Description
I have problems with xml-resover package on win32. For relative uris in xml
catalogs located at file system (and likely in other cases where file URI is
returned), the URI is returned in form "file:c:/dir/file.txt", but apparently
this form of URIs is not recognized as hierachical URI. I have found a
workaround for this problem (it just adds "/" before letter+":" and after
"file:" if it is not there), but I would really like to have problem fixed. The
problem was encountered when using the following catalog file:
<catalog xmlns='urn:oasis:names:tc:entity:xmlns:xml:catalog' prefer="system">
<public publicId='-//XJ//XJ Standard 0.0' uri="./xj.grammar"/>
</catalog>
Below is an answer to my message about having problem with such URIs
returned by resolver in EMF (www.eclipse.org/emf).
As a fix, I suggest to add slash on win32 platform before path.
Constantine
-----------------------------------------
http://www.eclipse.org/newsportal/article.php?id=3220&group=eclipse.tools.emf
The password could be obtained at page: http://www.eclipse.org/newsgroups/index.html
Hi Constantine,
Here is the problem exactly: "file:C:/dir/file.txt" is a valid URI, and EMF
handles it, but it is not considered a hierarchical URI according to RFC 2396,
and hence, according to EMF. In order to be considered a hierarchical URI, the
scheme-specific part must begin with a slash, so for example, "file:/c:/tmp.txt"
is hierarchical.
Because your URI is not hierarchical, it has no segments, hence no last segment,
and no extension. So, EMF looks for a resource factory registered against the
null-string extension and finds none. That produces the execption you see.
Someone introduced a hack into EMF 1 that allowed URIs of that form to be
considered hierarchical, but that broke resolve(), so we decided to go back to
the proper definition from the RFC in EMF 2.0.
Cheers,
Dave