Last Comment Bug 201754 - XML Inclusions (XInclude)
: XML Inclusions (XInclude)
Status: VERIFIED WONTFIX
: helpwanted
Product: Core
Classification: Components
Component: XML (show other bugs)
: Trunk
: All All
: -- enhancement with 37 votes (vote)
: Future
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://www.w3.org/TR/xinclude/
Depends on: 32842 182323
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-11 22:26 PDT by Ernest Cline
Modified: 2014-04-26 03:22 PDT (History)
33 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
document.xml file for Basic Inclusion example in spec (183 bytes, text/xml)
2003-04-11 22:29 PDT, Ernest Cline
no flags Details
disclaimer.xml file for Basic Inclusion example in spec (212 bytes, text/xml)
2003-04-11 22:30 PDT, Ernest Cline
no flags Details
file that points directly to the disclaimer (274 bytes, text/xml)
2003-11-01 07:13 PST, Anne (:annevk)
no flags Details
file that points directly to the disclaimer.xml file (274 bytes, text/xml)
2003-11-01 07:17 PST, Anne (:annevk)
no flags Details
textual inclusion example (276 bytes, application/xhtml+xml)
2004-11-05 03:53 PST, Dominik
no flags Details
plain text to textual inclusion example (2 bytes, text/plain)
2004-11-05 03:56 PST, Dominik
no flags Details
textual inclusion example - how it should look like (234 bytes, application/xhtml+xml)
2004-11-05 03:59 PST, Dominik
no flags Details
v 0.0.1 (44.20 KB, patch)
2005-02-07 13:06 PST, Olli Pettay [:smaug]
no flags Details | Diff | Review
v 0.0.2 (51.24 KB, patch)
2005-02-12 06:40 PST, Olli Pettay [:smaug]
no flags Details | Diff | Review

Description Ernest Cline 2003-04-11 22:26:26 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3) Gecko/20030312

Mozilla currently has no support for XML Inclusions (XInclude) as far as I can
tell. SInce the necessary background parts (Including the XPointer stuff which
just recently got fixed) are in there already, it's not as if this looks at
first glance as if this would be too difficult to implement.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Comment 1 Ernest Cline 2003-04-11 22:29:33 PDT
Created attachment 120282 [details]
document.xml file for Basic Inclusion example in spec
Comment 2 Ernest Cline 2003-04-11 22:30:33 PDT
Created attachment 120284 [details]
disclaimer.xml file for Basic Inclusion example in spec
Comment 3 Ernest Cline 2003-04-11 22:38:51 PDT
Added the dependencies, even tho they are for features already added just in
case they should somehow become unfixed or implementing this enhancement
requires changes to them.
Comment 4 Anne (:annevk) 2003-11-01 07:13:51 PST
Created attachment 134605 [details]
file that points directly to the disclaimer

Added <?xml-stylesheet?> so we can see if it is included. And altered value of
the xi:href attribute.
Comment 5 Anne (:annevk) 2003-11-01 07:15:42 PST
Comment on attachment 134605 [details]
file that points directly to the disclaimer

<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet?>
<document xmlns:xi="http://www.w3.org/2001/XInclude">
  <p>120 Mz is adequate for an average home user.</p>
  <xi:include
href="http://bugzilla.mozilla.org/attachment.cgi?id=120284&amp;action=view"/>
</document>
Comment 6 Anne (:annevk) 2003-11-01 07:17:57 PST
Created attachment 134607 [details]
file that points directly to the disclaimer.xml file

Sorry for all the spam. Description is the same.
Comment 7 Dominik 2004-10-01 05:13:09 PDT
IMHO it's time to start implement XInclude.
Comment 8 Arthur Wiebe 2004-10-01 05:29:35 PDT
(In reply to comment #7)
> IMHO it's time to start implement XInclude.

I totally agree.
Comment 9 Dominik 2004-11-05 03:53:09 PST
Created attachment 164717 [details]
textual inclusion example
Comment 10 Dominik 2004-11-05 03:56:34 PST
Created attachment 164718 [details]
plain text to textual inclusion example
Comment 11 Dominik 2004-11-05 03:59:10 PST
Created attachment 164719 [details]
textual inclusion example - how it should look like
Comment 12 Dominik 2004-12-20 11:56:21 PST
Now XInclude is W3C Recommendation. http://www.w3.org/TR/2004/REC-xinclude-20041220/
Comment 13 Olli Pettay [:smaug] 2004-12-28 14:38:25 PST
This could perhaps be implemented using XTF.
Hmm, when should the 'load' event be dispatched,
after processing all xi:include elements? In that case
XTF itself may not be enough - but still useful.
Comment 14 Daniel Kraft 2005-01-24 03:31:12 PST
Personally, I'd prefer to see that implemented in pure C++ (as this is, of 
coure, faster and not that more difficult).
Look at NS_NewElement(...) in 
mozilla/content/base/src/nsNameSpaceManager.cpp#400 
(http://lxr.mozilla.org/seamonkey/source/content/base/src/nsNameSpaceManager.cpp
#400). When implementing a new namespace, you just need to insert a new if(...) 
there.
Comment 15 Olli Pettay [:smaug] 2005-01-24 05:06:48 PST
You can do XTF extensions using C++ or JavaScript.
And actually it may (or should) be possible to implement this as an Extension,
a bit like XForms.
Comment 16 Daniel Kraft 2005-01-24 05:48:43 PST
Oh yes, you can implement XTF extensions with C++ - but why not directly if
possible?
Comment 17 Daniel Kraft 2005-01-28 13:07:18 PST
I haven't yet read the specification exactly, but if every xi:include-element
could only include one root node with children, not some consecutive nodes, the
implementation shouldn't be that hard (insert a NS_NewXInclude() function into
the namespace manager, which doesn't return the include-element itself but the
tree to be included).
Comment 18 Daniel Kraft 2005-01-30 09:32:22 PST
OK, I don't think that would work... Once because inclusion of multiple nodes
with a single xi:include is possible, and also because a former processed
xi:include-element must be adressable by later ones. So we need some sort of
loop over the tree once it has finished loading. Is it possible to register an
event listener or something like that therefore? (onload doesn't seem to be good
for that, because once onload is fired, the tree should be finished (including
XInclude processing)...)
Comment 19 Olli Pettay [:smaug] 2005-02-05 06:38:15 PST
Taking this for now. Not promising anything yet.
Comment 20 Daniel Kraft 2005-02-05 07:23:30 PST
If you need help (maybe implementing some special features), ask me.
Comment 21 Olli Pettay [:smaug] 2005-02-07 13:06:26 PST
Created attachment 173672 [details] [diff] [review]
v 0.0.1

Just an initial patch. Doesn't support XPointer and lacks also loop detection
etc.
Comment 22 Olli Pettay [:smaug] 2005-02-12 06:40:06 PST
Created attachment 174149 [details] [diff] [review]
v 0.0.2

Slowly adding new features. This one supports XPointer with external files.
Also charset conversion etc.
Comment 23 Dominik 2005-02-13 10:10:37 PST
A lot of http://www.w3.org/XML/Test/XInclude/#releases XI examples. 
Comment 24 Jonas Sicking (:sicking) 2005-04-30 16:55:59 PDT
Did you read the last paragraph of
http://www.w3.org/TR/2004/REC-xinclude-20041220/#creating-result, right before
the example.

That seems really hard to implement :(. You'd basically have to clone the
document before any includes are processed
Comment 25 Kalin Kozhuharov 2005-12-01 00:52:03 PST
While trying to move to a on-the-spot conversion (XML + XSLT) --> HTML for Firefix, I hit this limitation... Till now I was using XInclude for manual processing, but I cannot do it inside the browser.

Are there any alternatives to XInclude?
Currently I might use SSI on the server side to include the necesarry file (it is a kind of glossary) in the document, but that is not a good solution anyway.

No progress since february, so I guess asking about a target to land in mainline is naive...
Comment 26 Jonas Sicking (:sicking) 2005-12-01 11:14:45 PST
In the context of XSLT you might be able to replace XInclude with either the <xsl:import> element or the document() XPath function.

However, that doesn't change the fact that this bug is IMHO something we want to fix.
Comment 27 Johan 2007-02-20 04:26:26 PST
I'm also looking for a way to include a XML file into another XML file.

<xsl:import> can only include a stylesheet into another stylesheet, not it's not what I'm looking for.

Are there any other alternatives? 
Comment 28 Daniel Kraft 2007-02-20 07:47:42 PST
As Jonas said, with XSLT you can use something like
<apply-templates select="document('abc.xml');" />

But of course this is not XInclude and does not affect that this bug should be fixed...
Comment 29 Matthijs Wensveen 2008-12-15 04:27:34 PST
(In reply to comment #24)
> Did you read the last paragraph of
> http://www.w3.org/TR/2004/REC-xinclude-20041220/#creating-result, right before
> the example.
> 
> That seems really hard to implement :(. You'd basically have to clone the
> document before any includes are processed
> 

IMO the xpointer feature is not that important. A partial XInclude implementation where this feature is omitted would satisfy me, at least.

Otherwise, maybe the xi:include elements could be not replaced but get the included content as their contents. This would result in invalid xml however. 

Cloning the source document might be the only option to do this right.
Comment 30 James Kerr 2010-03-13 06:50:09 PST
This seems like something that would be / could potentially be, widely used if implemented. Being able to include arbitrary XML documents in one another seems an awfully fundamental ability to have been left out for so long...
Comment 31 bansp 2010-03-13 17:47:10 PST
Note that often, you may be tempted to identify the target for inclusion by its ID -- see bug # 275196 , 6 years old... Without xml:id implemented, you're left with a subset of the element() scheme or including entire files (with just @href, no @xpointer). 

Still, you're right, even @href-based inclusion alone would be a *leap* forward.
Comment 32 doug0213 2010-10-03 13:25:40 PDT
Funny post from the now defunct CDF/WICD mailing list:
http://lists.w3.org/Archives/Public/public-cdf/2008Dec/0000.html

"I think that are too many different ways to build compound documents, either
by reference or by inclusion.
At the moment we have:

1) XHTML2 embedding attributes
2) XHTML2 / 5 object
3) XHTML5 embed
4) XInclude
5) XLink type="embed" / type="resource"
6) CSS content: uri(); property
7) DTD external entities
8) XBL or XSLT (which could transform markup across languages)
9) Direct inclusion (ie plain writing or server-side processing)

Plus we have media specific, like svg image, xhtml 2/5 img, smil media
object, css background-image / border-image;

I was wondering if any work was started to provide a unform way, instead of
relying on single language capabilities (which seems the current orientation
of CDRF and CDIF)

Giovanni"

And yet none of these are quite ideal (well I suppose the generalized object tags from XHTML 2 would have been pretty cool, but even that wouldn't have solved the problem on the lower level of XML.)

I'm unfortunately still resorting to SSI probably more than I should.
Comment 33 Olli Pettay [:smaug] 2013-11-28 08:26:51 PST
We don't want this.

Note You need to log in before you can comment on or make changes to this bug.