Hi Christian,

It works very well indeed and I thank you for it. Unfortunately it seems to me that it doesn't really allow me to use XInclude in all its power: to edit a file and include it in other files, thus allowing elements present in the including file and in the included file to cohabit in real time (which is for me the meaning I intend to give to my files and which works very well if I edit the files outside a database). With this query, it would have to be run regularly to update the items included in the including files. It's not impossible, but in my case it seems to me that using schematron to check indexed entities are present in the index file is a bit more flexible.

Thank you for your help,

Sincerely and with pleasure,

Virgile Reignier

Christian Grün <christian.gr...@gmail.com> a écrit :

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






Reply via email to