This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I don't think we're taking into account when the base URI for relative URIs resolution is set in the <base href> element in XHTML. (I haven't had the time to create a test for it, but thought I would record now rather than forgetting it later) I know for sure that some of the XSLTs tests I edited didn't take it into account, but I suspect this actually affects also some pieces of the Java code.
I can provide Java hooks for handling this, but need to consult with Roland on how this is done in XSLT.
I can deal with the XSLT part - I don't think Roland can spend any time on this project for the time being. My concern was primarily for links resolutions that are done inside the Java code (e.g. for retrieving style sheets, images, etc)
(In reply to comment #2) > I can deal with the XSLT part - I don't think Roland can spend any time on this > project for the time being. My concern was primarily for links resolutions that > are done inside the Java code (e.g. for retrieving style sheets, images, etc) Should we convert the base href into an xml:base and let the Java code handle the xml base?
This is fixed unless there are remaining XSL changes still needed. The HTTPResource.parse() method now takes both a String *and a URI*, which is the base URI against which to resolve the String. It can be null.
Done for ImagesSpecifySizeTest.xsl and TablesLayout.xsl, but may need to be applied to ObjectsOrScript, includedResources.xsl depending on the way we implement the object processing (bug #5774). I also fixed a bug where the base URI wasn't correctly calculated after a redirect.
Given that the ImagesSpecifySizeTest.xsl stylesheet template that checks the image starts with: <xsl:template match="html:img"> <!-- Check the image exists on moki --> <xsl:if test="/moki/images/image[URI[text() = moki:resolve-uri(current()/@src,/moki/primaryDoc/retrieval/retrievedURI)]]"> ... which does not take into account the <base> element, and given that tests are only applied if this condition is met, it is not done in ImagesSpecifySizeTest.xsl At least, the checker fails to raise a FAIL for the following test: IMAGES_SPECIFY_SIZE 8
fixed for ImagesSpecifySize; I haven't checked whether this needs to apply to ObjectsOrScripts and co yet.
On my trip to fix the Object Processing rules, I also cleaned the part that resolves relative URIs against either the one of the primary document OR the one defined in a <base> element in the XSLT stylesheets. To do that, I defined a moki:get-retrieved-resource function in functions.xsl, that is now being called in all places that needed to get the resource that was retrieved in the moki from its URI (which typically happens when the HTML code is being parsed for objects and images). I think that closes the bug. Let me know if I missed something.