You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Keiron Liddle <ke...@aftexsw.com> on 2001/09/26 10:09:44 UTC
href link problem
Hi again,
As you might guess this problem is related to the previous broken link
problems.
It appears in line 469 in ParsedURL that if the specified url on the
element
eg:
<use xlink:href="file:ref.svg#FOP" transform="scale(1.5)" x="18"
y="40"/>
has a protocol then it ignores the base url and attempts to just use the
url. From the spec it appears that the xlink:href can have a URI-reference
which can be relative which of course is allowed to have a protocol.
So it should ignore the base url only if the href is an absolute url. The
presence of a protocol is not a relevant indicator.
Keiron.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: href link problem
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "KL" == Keiron Liddle <ke...@aftexsw.com> writes:
KL> I have got the setXMLParser working, although I am a bit wary of
KL> the use of a static name.
Glad to hear it's working.
Yah, I agree the static thing isn't great, I'll investigate adding
the concept of a UserAgent to the ImageTagRegistry so information can
properly propogate from the host application to the file readers, etc.
Just seems like such overkill...
KL> There still seems to be a problem.
KL> If I add the following line to bridge/URIResolver.java, line 103
KL> System.out.println("d:" + documentURI + " :" + uri + " :" +
KL> purl.toString());
KL> when I am running java in the same directory it prints out:
KL> d:file:multi.svg :file:ref.svg#FOP :file:/ref.svg#FOP
Ugg, where do you come up with these things :)
I've fixed this, added test cases and the commit will follow shortly.
KL> Thanks for helping with this.
Thanks, for so patiently pointing out the places that need fixing...
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: href link problem
Posted by Keiron Liddle <ke...@aftexsw.com>.
Hi again...
There still seems to be a problem.
If I add the following line to bridge/URIResolver.java, line 103
System.out.println("d:" + documentURI + " :" + uri + " :" +
purl.toString());
when I am running java in the same directory it prints out:
d:file:multi.svg :file:ref.svg#FOP :file:/ref.svg#FOP
in a different directory it prints out:
d:file:/home/keiron/xml/fop/xml-fop/docs/examples/svg/multi.svg
:file:ref.svg#FOP :file:/home/keiron/xml/fop/xml-fop/docs/examples/svg/ref.svg#FOP
In the first case it cannot find the file since it has changed it from
relative to absolute the second one works ok.
Thanks for helping with this.
I have got the setXMLParser working, although I am a bit wary of the use of
a static name.
Keiron.
ps. I am on the list so you don't have to cc me.
On Wed, 26 Sep 2001 16:17:21 Thomas E Deweese wrote:
> Thanks for the reference...
>
> It turns out I was parsing the relative URI correctly the first
> time, I'll leave the code in as I think as a practical matter it
> probably needs to be supported (and the spec gives me permission to
> do so).
>
> 3) If the scheme component is defined, indicating that the reference
> starts with a scheme name, then the reference is interpreted as an
> absolute URI and we are done. Otherwise, the reference URI's
> scheme is inherited from the base URI's scheme component.
>
> Due to a loophole in prior specifications [RFC1630], some parsers
> allow the scheme name to be present in a relative URI if it is the
> same as the base URI scheme. Unfortunately, this can conflict
> with the correct parsing of non-hierarchical URI. For backwards
> compatibility, an implementation may work around such references
> by removing the scheme if it matches that of the base URI and the
> scheme is known to always use the <hier_part> syntax.
>
> I don't currently handle the 'authority' component properly so I'll
> fix that though:
>
> Base URL - http://www.kodak.com/...
> Sub URL - //www.image.kodak.com/...
>
> Note no protocol (now why someone would really do that is a bit
> beyond me but what ever)
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: href link problem
Posted by Keiron Liddle <ke...@aftexsw.com>.
On Wed, 26 Sep 2001 14:47:33 Thomas E Deweese wrote:
> I implemented this, but I was unable to track down the definitive
> reference on relative URI's, does anyone know where that is?
>
> I am particularly interested in what should be done if protocols
> differ between parent and child URIs (this is the case that made me
> originally decide that a protocol spec ment it was absolute) but am
> also generally interested in what the true specification is to ensure
> I haven't missed any other corner cases.
This is the rfc for uri's
http://www.ietf.org/rfc/rfc2396.txt
it contains all the nitty gritty details plus more.
It's predecessor is
http://www.ietf.org/rfc/rfc1738.txt
all about url's but you probably don't need to look at this one.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
href link problem
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "KL" == Keiron Liddle <ke...@aftexsw.com> writes:
KL> Hi again, As you might guess this problem is related to the
KL> previous broken link problems.
KL> It appears in line 469 in ParsedURL that if the specified url on
KL> the element eg: <use xlink:href="file:ref.svg#FOP"
KL> transform="scale(1.5)" x="18" y="40"/>
KL> has a protocol then it ignores the base url and attempts to just
KL> use the url. From the spec it appears that the xlink:href can have
KL> a URI-reference which can be relative which of course is allowed
KL> to have a protocol. So it should ignore the base url only if the
KL> href is an absolute url. The presence of a protocol is not a
KL> relevant indicator.
I implemented this, but I was unable to track down the definitive
reference on relative URI's, does anyone know where that is?
I am particularly interested in what should be done if protocols
differ between parent and child URIs (this is the case that made me
originally decide that a protocol spec ment it was absolute) but am
also generally interested in what the true specification is to ensure
I haven't missed any other corner cases.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org