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.reign...@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.gr...@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&q=xpointer
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
