XInclude works because an XInclude processor adds an xml:base attribute
to transcluded elements. Hence no broken links, no missing images and
this, without any link conversion.
See https://www.w3.org/TR/xinclude-11/#base
XXE does not add an xml:base attribute during its transclusion step
(which happens for example, after a document is opened or after pasting
a reference: Ctrl+Shift-C then Ctrl-V). It adds an XXE, non-serialized,
custom, property which is equivalent to xml:base.
By default, XXE does not save transcluded documents (that is, saved
documents contain <xi:include>). Therefore XXE does not need to add
xml:base attributes to saved elements.
On 3/13/24 02:36, Leif Halvard Silli wrote:
Two more things:
1. The spec:
I find it difficult to understand what – if anything – the Xinclude spec
directly says about converting links to something that works in the
merged document.
(It is also quite amazing, I think, that the spec does not give any
examples of how this fundamental issue should be solved. It has sectons
about how xml:base should affect the merge, but little, if anything,
about what should happen to links that are not affected by xml:base. Not
to mention the effect of <base href=foo> - on that it is completely
silent, of course {I guess}.)
That said, the Abstract section of the spec, says that the goal of the
merge is «a single composite infoset». And so, it would be quite
meaningless if links that work before the merge, should fail to work
after the merge. See <https://www.w3.org/TR/xinclude-11/#abstract>.
Another justification for why my justification is correct, is that
Xinclude is supposed to be able to include (content from) selfstanding
documents - that is: Documents that are useful on their own, before they
are included in a master document.
(Btw, what made me look into what the spec says, was when I discovered
that the xmllint CLI application does not seem to perform any link
conversion, as much as I can tell – often Xmllint is considered a very
accurate interpretation of the spec ... )
2. XXE:
But when working with XHTML master files which include elements via
Xinclude, the only way to create links that works inside XXE itself, is
by using relative URIs the way I demonstrated in the example files that
I attached in my previous message.
So let us say that we have 'master.xhtml', which includes
'include-1.xht' and 'include-2.xht'. If an anchor element inside the
file 'include-1.xht' links to #location inside 'include-2.xht', then the
<a href=""> must look like this: <a href="include-2.xht#location">
(provided the two files are located in the same directory).
If you follow that recipe, you can — within XMLmind XML editor — follow
(read: use) that link inside the compound 'master.xhtml' document. Or to
put it differently: Then the link will work inside XXE. You can,
basically, «click the links».
This also works in Prince XML (with --xinclude enabled). (For the most
part - there are some details in how Prince XML works which I do not
quite grok.)
What does **not** work, inside XXE, is to simply do href="#location".
Doing that, will cause XXE to open 'include-2.xht' in a separate Tab.
Oddly enough.
But as long as you use XXE, you do want that it works – inside XXE.
But outside XXE and PrinceXML, it is another world ... (And in this
"another world" I include XHTML->Preview and XHTML->Convert Document->to
PDF.)
In this other world, it is the "naked" fragment URLs that work. In other
words: href="#location". Which is understandable – even if it does not
make sense. It seems like an instance of "the clock is correct twice per
24 hours".
--
XMLmind XML Editor Support List
xmleditor-support@xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support
