Hi Christian,
After a few interruptions, I resume working on my database. And I discover that XInclude continues in fact to generate errors: if I manage now very well to import a file which contains an XInclude, I cannot manage in the database these files by preserving these tags.
If I take the example of the two files that I presented before:
music.xml:
<music xmlns:xi="http://www.w3.org/2001/XInclude"> <title>Smoke on the water</title> <artist>Deep Purple</artist> <xi:include href="label.xml"/> </music>
label.xml
<list><label xml:id="purple">Purple Records</label></list>
Resolving the include during import gives me the following file:
<music xmlns:xi="http://www.w3.org/2001/XInclude"> <title>Smoke on the water</title> <artist>Deep Purple</artist> <list xml:base="label.xml"><label xml:id="purple">Purple Records</label></list> </music>
But for my part, I will need the inclusion to be kept in the files in order to be able to modify the label.xml file, include it in several other files and be able to call in real time the entities of this file. So I tried to modify the file in the database to make it return to its initial form, and I again get the binarization error that I initially got: the files are indicated as being in "binary" format and cannot be manipulated like XML files.
I also tried to transfer everything from my database to eXist, and as I had begun to see it worked quite well: I can import, export and above all manipulate in real time files that contain XIncludes linking to other files. But I'm also facing a new bug that I can't understand when editing these files via WebDAV: some files containing an XInclude do not open completely and stop after a certain number of lines.
Unless there is a miraculous solution, I think the easiest thing for me is to simply do without XInclude. What ultimately interests me in this technique is to make the link between entities identified in texts and entities gathered in an index. Even though XInclude has some serious advantages for making this link, I can still verify the integrity of the link using schematron rules built into a TEI-ODD.
Thank you in any case for your help and I look forward to discussing with you if it can be useful for you to understand the bug I am facing.
Best regards,
Virgile Reignier
Virgile Reignier virgile.reignier@u-picardie.fr a écrit :
Hi Christian,
Thank you for your answer!
I took a look at the mail archives and read the suggestions to write the content of the xpointer attribute as xpointer="element(/1/nx1/nx2/.../nxn)". All this proposal manages to do for me is to generate an error in the validation of my file by Oxygen, without any effect on its import by BaseX.
I could also, as @Gerrit suggests, perform the inclusion from an xQuery formula. But it seems to me that this would be less convenient than learning to do without XPointer. Thanks anyway for your suggestion, I'll gladly take others if some of you still have ideas.
About the presence of non-ASCII characters, my two files music.xml and label.xml are currently in a "test_baseX" folder. If I change the folder name to " test_basèX", my import crashes. But this is something that is again related to XInclude, even if the folder name is not explicitly specified in the @href attribute: if I try to import label.xml, it works fine.
Thank you for your valuable help in any case,
Bests,
Virgile
Translated with www.DeepL.com/Translator (free version)
Christian Grün christian.gruen@gmail.com a écrit :
Hi Virgile,
Thanks for giving us an update.
2 - the use of the xpointer attribute in the xi:included tag, which systematically generates an error.
I see. Sorry for that. BaseX relies on the standard JDK library for parsing XML documents. Unfortunately, XPointer is only partially supported. It’s interesting to hear, though, that XPointer seems to be fully supported by eXist-db. I remember that other users reported problems with xpointer back to us in the past. You could check out the replies in the past threads [1].
Maybe someone else who’s reading this knows a solution to correctly resolve XPointer id references? Maybe it helps to embed a more current version of Apache Xerces in the classpath?
1 - The presence of special characters such as the French "è" in the file path. For some reason this does not bother Oxygen or eXist, only BaseX.
Using non-ASCII characters shouldn’t cause any problems (or at least we are not aware of any); we regularly such use file paths by our own. Could you possibly provide us with a reproducible example?
Cordialement, Christian
[1] https://www.mail-archive.com/search?l=basex-talk%40mailman.uni-konstanz.de&a...
Thank you very much for helping me to reach these conclusions, which has allowed me to make a lot of progress:
1 - The problem is easy to solve: I just need to remove all traces of unconventionality from my file names (simple but it was necessary to think about it) 2 - I can put the items I want to include in the root of my file and avoid using the xpointer attribute. The only disadvantage of this is that my file is no longer valid with respect to the TEI and I can no longer take advantage of this scheme to organise their metadata. This won't stop me from working, but I'd like to take this opportunity to ask you if you also have an error when you use xpointer in your files? Is it simply a feature that BaseX does not support?
If necessary, here are the two files I use as a test for this purpose:
music.xml :
<music xmlns:xi="http://www.w3.org/2001/XInclude"> <title>Smoke on the water</title> <artist>Deep Purple</artist> <xi:include href="label.xml" xpointer="purple"/> </music>
label.xml:
<list><label xml:id="purple">Purple Records</label></list>
Again, Oxygen tells me for its part that everything is valid, and the tests with eXist included the xpointer feature. And if I remove the xpointer attribute, I have no errors in sight.
If needed, I work with Java version 11, Windows 10 and BaseX 10.4
Thanks again for everything,
Regards,
Virgile Reignier