cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: Missing feature in XIncludeTransformer
Date Mon, 30 Jul 2007 19:40:56 GMT
Andrew Cave pisze:
> I'm curious as to why this failed to generate responses. Maybe someone 
> could offer me some advice. Should I have just submitted my patch to 
> JIRA first, or is there something else I should have done?

Speaking about myself: I missed your mail because I was busy with lots of other things. Kind
pinging our list (like you do so) does not hurt.

I comment your proposal below.

> Andrew Cave wrote:
>> Hello,
>> I noticed that Cocoon's XIncludeTransformer seems to be missing the 
>> base URI fixup support specified in the W3C's XInclude spec [1] 
>> (Careful, this is distinct from supporting xml:base to resolve 
>> relative xi:include hrefs against).
>> In short, it says that the base URIs of documents do not change when 
>> passed through an XInclude parser. This means that xml:base attributes 
>> with the value of the current base URI should be added to the top 
>> level included elements. To see an example, the xmllint parser (part 
>> of libxml2) will perform this attribute insertion when you enable 
>> XInclude processing.
>> I think this feature is important because otherwise, relative URIs 
>> (i.e. links) in an included document will break if the included 
>> document is not located in the same directory. Adding the xml:base 
>> attribute to the result gives later content handlers the ability to 
>> resolve relative URIs against the base. (In particular, I'm thinking 
>> of using XPath 2.0's resolve-uri function).
>> Any thoughts? Is this a feature we need to see?
>> I think this is the cleanest and most general solution for resolving 
>> relative URIs in included documents -- not to mention it's required by 
>> the XInclude spec. Pending discussion here, I've created a patch that 
>> adds this support that I can submit to JIRA.

I have taken a quick look at specification and everything what you said makes sense. Please
submit a patch, preferably for both 2.1.x and 
trunk and I'll be happy to submit it. Submitting a test case for functionality you have implemented
would be awesome.

Grzegorz Kossakowski

View raw message