From dev-return-95766-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Fri Jul 20 18:14:51 2007 Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 67994 invoked from network); 20 Jul 2007 18:14:47 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 20 Jul 2007 18:14:46 -0000 Received: (qmail 3278 invoked by uid 500); 20 Jul 2007 18:14:47 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 3203 invoked by uid 500); 20 Jul 2007 18:14:46 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 3190 invoked by uid 99); 20 Jul 2007 18:14:46 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Jul 2007 11:14:46 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [129.128.5.19] (HELO pilsener.srv.ualberta.ca) (129.128.5.19) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Jul 2007 11:14:42 -0700 Received: from [192.168.0.103] (S0106001346196329.ed.shawcable.net [70.74.4.175]) (authenticated bits=0) by pilsener.srv.ualberta.ca (8.13.7/8.13.7) with ESMTP id l6KIEGdM004898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 20 Jul 2007 12:14:21 -0600 (MDT) Message-ID: <46A0FC3B.6030708@ualberta.ca> Date: Fri, 20 Jul 2007 12:17:31 -0600 From: Andrew Cave User-Agent: Thunderbird 2.0.0.0 (X11/20070501) MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Missing feature in XIncludeTransformer Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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. -- Andrew Cave [1] http://www.w3.org/TR/xinclude/#base - The Base URI Fixup section of the W3C's XInclude specification