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".
Leif Halvard Silli
On 12.03.2024 00:23 by Leif Halvard Silli:
I include a simple test case in this message - see the 3 attached
file. The 'master' file embeds/includes the other two files. If you
preview the master file via XHTML Preview, you should experience the
error that I described.
Leif Halvard Silli
Den 12.03.2024 00:00, skreiv Leif Halvard Silli:
I explain at the bottom of this email – let me hear if you also need
demo documents.
On 26.02.2024 10:40 Hussein Shafie:
2) As for the last variant, namely to flatten the ebook to a single
file: Why can't you instead fix the XHTML preview command?
Because we don't understand what is the problem with the XHTML
Preview command.
Here we use the XHTML Preview command all the time and it works
great for us. Not to check links but to see how the page would look
in the browser with our "corporate" CSS stylesheet. (Hence the name
"Preview") See "Preview Settings",
https://www.xmlmind.com/xmleditor/_distrib/doc/xhtml/menu.html#previewSettings
Please send us a sample HTML page containing links, xincluding
sub-documents and referencing external images and please explain
what you expect the XHTML Preview command to do.
We have nothing against improving the XHTML Preview command but if
you use case is too specific or if your RFE is best implemented
using other means (e.g. implement an actual link checker orthogonal
to the XHTML Preview command), we will not implement your RFE.
As I described initially, in our case XHTML preview fails to create
a working single document, the problem being that many URLs fails
to be converted to URLs that function in the flattened document.
This goes for links at least (but right now aI forgot if it also
goes for image URLs).
Sorry but we don't understand this.
The XHTML Preview function has two «modes»:
First mode: For documents without (X)includes, it simply directs the
file to the Web browser. For mode 1 previews, there are no problems
that I am aware of, and of course it is a great way to preview a file
with your "corporate" CSS files on an external Web server.
Second mode: For documents with (X)includes, the process is more
complicated: the document plus all its includes are glued together
into a single file. However, this process takes place inside
<file:///private/var/foo> – that is: not inside the folder where the
main document file is located. And this «move» into /private
directory, has — in itself — several consequences. (There would be
less trouble if the preview file had been created inside the folder
where the working file is stored.)
Our issues (and thus, the problems I describe below) are only related
to the second mode:
1) One of the consequences is that external CSS becomes unavailable
to the preview if — as we do — one embeds CSS via <style>@import
"url/to/file.css"</style>. Why? Simply because the XHTML Preview
command does not update "url/to/file.css" to something that works
when the previewed files is located inside the "/private" directory.
(Workaround: Use <link rel="stylesheet" href="url/to/file.css">
instead — I just discovered that the XHTML Preview command **does**
convert href="url/to/file.css" to href="absolute/url/to/file.css".)
2) Another consequence is for ordinary links – that is @href inside
<a>. Are such link URLs converted to absolute URLs? Unfortunately not.
Consider the following compound document:
*: motherDocument.xht
*.*: contents.xht (xincluded into mother document)
*.*: chapt1.xht. (xincluded into mother document)
*.*: chapt2.xht. (xincluded into mother document)
Inside the 'contents.xhtml' file, there is a table of contents, with
links to locations in the various chapter files etc.
Thus, in the 'contents.xht' file, we find for instance this:
<a href="chapt1.xht#location-1">Chapter 1</a>
<a href="chapt2.xht#location-2">Chapter 2</a>
Because XHTML Preview is supposed to "flatten" the document into a
single document, one would expect that the above two links, would
become converted into the following:
<a href="#location-1">Chapter 1</a>
<a href="#location-2">Chapter 2</a>
If this had happened, then I would have been able to use the link
validation tool to check for broken links.
But this does not happen. In fact, nothing happens. The URLs are left
unchanged. Hence, ordinary links in the preview document points to
locations outside the document ...
I hope this was better explained. And that you can solve this issue
pretty easily.
Leif Halvard Silli
--
XMLmind XML Editor Support List
xmleditor-support@xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support
--
XMLmind XML Editor Support List
xmleditor-support@xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support
