Empty XML elements are treated as nested elements

[daliboris]

If data contain empty elements, for example

<revisionDesc>
 <change xml:id="a.FA-CS.00001-c3" status="resolved" when="2024-04-19T15:59:00Z" who="#boris" />
 <change xml:id="a.FA-CS.00001-c2" status="pending" when="2024-04-19T13:59:00Z" who="#boris" />
  <change xml:id="a.FA-CS.00001-c1" status="created" when="2024-04-19T10:59:00Z" who="#host" />
</revisionDesc>

they are treated like nested elements and only the first one elment is processed in the <fx-repeat> element. This is how it looks in the ‘Fore Glass’:

The workaround is to use the close tag and empty content

<revisionDesc>
 <change xml:id="a.FA-CS.00001-c3" status="resolved" when="2024-04-19T15:59:00Z" who="#boris"></change>
 <change xml:id="a.FA-CS.00001-c2" status="pending" when="2024-04-19T13:59:00Z" who="#boris"></change>
  <change xml:id="a.FA-CS.00001-c1" status="created" when="2024-04-19T10:59:00Z" who="#host"></change>
</revisionDesc>

[DrRataplan]

Hey Boris, Let me guess, that's an instance inclined in HTML. HTML parsing rules apply there, so self closing elements are an issue. I'm up for a quick experiment if we can use innerText there and see if we can do our own parsing, but that is a bit of magic. Would fix issues though. I'll come back to that. Kind regards, Martin

…

On Sun, 5 May 2024, 19:56 Boris Lehečka, ***@***.***> wrote: If data contain empty elements, for example <revisionDesc> <change xml:id="a.FA-CS.00001-c3" status="resolved" when="2024-04-19T15:59:00Z" who="#boris" /> <change xml:id="a.FA-CS.00001-c2" status="pending" when="2024-04-19T13:59:00Z" who="#boris" /> <change xml:id="a.FA-CS.00001-c1" status="created" when="2024-04-19T10:59:00Z" who="#host" /> </revisionDesc> they are treated like nested elements and only the first one elment is processed in the <fx-repeat> element. This is how it looks in the ‘Fore Glass’: vivaldi_2024-05-05T19-39-31.png (view on web) <https://github.com/Jinntec/Fore/assets/8056045/4b254938-f8d8-43a0-aac5-b11a1609cda7> The workaround is to use the close tag and empty content <revisionDesc> <change xml:id="a.FA-CS.00001-c3" status="resolved" when="2024-04-19T15:59:00Z" who="#boris"></change> <change xml:id="a.FA-CS.00001-c2" status="pending" when="2024-04-19T13:59:00Z" who="#boris"></change> <change xml:id="a.FA-CS.00001-c1" status="created" when="2024-04-19T10:59:00Z" who="#host"></change> </revisionDesc> — Reply to this email directly, view it on GitHub <#256>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGKEJCJW4GCWWN2MIDHP23ZAZXGVAVCNFSM6AAAAABHH435ACVHI2DSMVQWIX3LMV43ASLTON2WKOZSGI3TSNRVGE3TKMI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[daliboris]

Hi Martin, you're right. Data in my example come from HTML page.

I'm just getting started with Fore and using HTML file from the file system is the best solution for me right now, albeit with some issues like the one mentioned above or XPath case-insensivity in the case of the content of the <data> element.

After proof-of-concept I'll switch to loading data from external sources (like TEI Publisher's REST API).

[JoernT]

@DrRataplan i'm not sure if 'fixing' the inline instance is sensible as it tries to mimic something that's not the case - being HTML versus XML. However we probably should make sure that this clear to the user.

Cause: it's not just the above issue but also case-insensitivity and of course you can't use namespaces in an inline instance. Other naming restrictions might also apply (not sure about that).

To be correct we maybe should even think about more explicitly support fx-instance type="html" and make clear in the docs that you're dealing with HTML - guess i have written it somewhere but might need a more prominent mention.

@daliboris you can also put a proper local xml file by the side and reference from the instance like so

<fx-instance src="my.xml">

This gives you a full-blown proper XML file instance.

@daliboris not sure if you already noticed but since TEI Publisher 9.0 Fore is also part of the distribution and we do a lot of interfacing API endpoints in our apps. Works beautifullly.

[daliboris]

Hello @JoernT , I know about the@src attribute, but loading fails if it's used within local file and not from a web server.

Access to fetch at 'file:///V:/Projekty/Github/Daliboris/lediir-data/tests/annotations/data/annotations.xml' from origin 'null' has been blocked by CORS policy: Cross origin requests are only supported for protocol schemes: http, data, isolated-app, chrome-extension, chrome, https, chrome-untrusted.

I know about API for the Fore in the latest TEI Publisher 9, I even implemented new entity form in its annotation tool.

But now I started testing my form for editing of TEI using files from my filesystem not from a web server.

[JoernT]

@daliboris yes - local filesystem is not supported

Hello @JoernT , I know about the@src attribute, but loading fails if it's used within local file and not from a web server.

Access to fetch at 'file:///V:/Projekty/Github/Daliboris/lediir-data/tests/annotations/data/annotations.xml' from origin 'null' has been blocked by CORS policy: Cross origin requests are only supported for protocol schemes: http, data, isolated-app, chrome-extension, chrome, https, chrome-untrusted.

I know about API for the Fore in the latest TEI Publisher 9, I even implemented new entity form in its annotation tool.

But now I started testing my form for editing of TEI using files from my filesystem not from a web server.
Are you aware of 'fore-project' repo? This gives you a simple node-based server you can easily run locally to edit files on your filesystem though they'll be accessed via http. It is meant to kickstart developing Fore pages and also have some E2E tests with Cypress optionally.

You could create a clone of that, put your files in some directory and run Fore via npm start- maybe that's an option?

A bit more context on why accessing local filesystem from browser is not recommended - https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/CORSRequestNotHttp?utm_source=devtools&utm_medium=firefox-cors-errors&utm_campaign=default

But thinking about it fore-project is still missing the part that would save the changed files for you. That should be doable however - will discuss that later with @DrRataplan

[JoernT]

Just to follow up - implementing a simple endpoint in web-devserver should be straightforward and would allow to edit local files with the price of having a nodejs install.

[JoernT]

Summary of discussion so far:

we'd rather not want to mimic XML directly inside of the HTML - the differences like case-sensitivity and treatment of empty elements will prevent a proper handling of the content.

Further it's also a highly questionable approach to break with these fundamental principles.

The only solution would be to have an additional <template> element that wraps an XML document like so:

<fx-instance type="xml">
  <template>
    <root xmlns="foo">
      ...
    </root>
  </template>
</fx-instance>

The template element makes sure that the content is not touched (inert) and we can parse it as XML ourselves.

The price is the additional wrapping element - similar might be possible with a <script> tag but that feels more hacky so my vote (if that's considered a worthful feature) would strongly pro 'template'.

Thoughts @DrRataplan @daliboris ?