Re: How to check links in compound documents?

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
[email protected]
http://www.xmlmind.com/mailman/listinfo/xmleditor-support