Once the rewrite prefix is selected, the result should be the concatenation of the prefix and the remaining part of the URI. What's happening to day is that the remaining part of the URI is resolved against the prefix. In many cases, that works just like concatenation. Given:
<rewriteURI uriStartString="http://www.example.org/path/to/" rewritePrefix="file:/path/to/"/>
Looking up http://www.example.com/path/to/thing returns file:/path/to/thing. But given:
<rewriteURI uriStartString="http://www.example.org/schema/location.xsd"
rewritePrefix="file:/my/schema/location.xsd"/>Looking put http://www.example.org/schema/location.xsd should return file:/my/schema/location.xsd. Today, the empty string is resolved against the prefix and the result is http://www.example.org/schema/ which is never going to be useful.
That strikes me as a slightly odd use of rewrite, but the spec is pretty clear that rewriting "removes the matching prefix from the supplied identifier and replaces it". That's concatenation not resolution.
Once the rewrite prefix is selected, the result should be the concatenation of the prefix and the remaining part of the URI. What's happening to day is that the remaining part of the URI is resolved against the prefix. In many cases, that works just like concatenation. Given:
Looking up
http://www.example.com/path/to/thingreturnsfile:/path/to/thing. But given:Looking put
http://www.example.org/schema/location.xsdshould returnfile:/my/schema/location.xsd. Today, the empty string is resolved against the prefix and the result ishttp://www.example.org/schema/which is never going to be useful.That strikes me as a slightly odd use of rewrite, but the spec is pretty clear that rewriting "removes the matching prefix from the supplied identifier and replaces it". That's concatenation not resolution.