Thanks, Virgilie, that’s interesting. It seems that eXist-db includes the files only if files are output (serialized). I’ll be happy to get this confirmed by eXist-db users out there… As indicated, this can also be done with XQuery; see e.g. [1] or the following example:
Preparation: • turn xinclude off • create a database 'test' from a directory that contains music.xml and label.xml • run the following script: declare namespace xi = 'http://www.w3.org/2001/XInclude'; declare function xi:enrich($node) { $node update { for $inc in .//xi:include let $href := $inc/@href let $included-doc := db:get(db:name($node), $href) update { insert node attribute xml:base { $href } into /* } return replace node $inc with $included-doc } }; xi:enrich(db:get('test', 'music.xml')) Hope this helps, Christian [1] https://www.mail-archive.com/basex-talk@mailman.uni-konstanz.de/msg13388.html On Fri, Mar 31, 2023 at 11:38 AM Virgile Reignier <virgile.reign...@u-picardie.fr> wrote: > > 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 > > >
