Support XML format using 'id' attributes to encode references (XStream.ID_REFERENCES)

[pfalcon]

This patchset implements supports for XML serialization format using 'id' attributes to encode references, as discussed in https://github.com/portfolio-performance/portfolio/issues/3417 . To summarize discussion in that ticket, the main motivation for supporting this format is enabling easy interoperability with 3rd-party tools.

What this patch implements is:

1. "Save as" -> "XML with id attributes" command in the "File" menu.
2. Detection of XPath vs id format when opening plain XML files. XStream library itself doesn''t do such autodetection. The detection works only for plain XML files, not zipped, not encrypted. That should be a fair compromise, given the aim is interoperability with external tools.
3. Format is preserved for saving. I.e., XML id files will be saved as such going forwards, while XPath file will be saved as such.
4. There're tweaks to avoid putting id attributes on elements which aren't referenceable with existing PP data/object model. The absolute minimum which requires such treatment is <price> element. But again, I went as far as diffing original XPath XML vs id XML produced from it, to make sure that diff doesn't have spurious id's on elements which can't really be referenced. Perhaps the only exception is <watchlist>. These don't have uuid in PP model, effectively name is an ID, but for external tools, it's useful to have some formal ID for them, so XML id attr is produced.

[pfalcon]

Example of the XML diff, based on the included kommer example:

@@ -553,23 +553,23 @@
                   <updatedAt>2024-02-16T07:17:00.710324Z</updatedAt>
                   <type>BUY</type>
                 </portfolio-transaction>
-                <portfolio-transaction>
+                <portfolio-transaction id="26">
                   <uuid>68448a62-ab45-4233-abc3-cae984c05f6a</uuid>
                   <date>2019-01-07T00:00</date>
                   <currencyCode>EUR</currencyCode>
                   <amount>133025</amount>
-                  <security reference="../../../../../../../../../securities/security[5]"/>
-                  <crossEntry class="buysell">
-                    <portfolio reference="../../../.."/>
-                    <portfolioTransaction reference="../.."/>
-                    <account reference="../../../../../../../.."/>
-                    <accountTransaction>
+                  <security reference="6"/>
+                  <crossEntry class="buysell" id="27">
+                    <portfolio reference="24"/>
+                    <portfolioTransaction reference="26"/>
+                    <account reference="20"/>
+                    <accountTransaction id="28">
                       <uuid>ff6462ad-dd45-4bd6-a8c2-3806ab449ed4</uuid>
                       <date>2019-01-07T00:00</date>
                       <currencyCode>EUR</currencyCode>
                       <amount>133025</amount>

[flywire]

@buchen Your comments in the issue and thumbs up seem to indicate you are supportive of this draft pr. What would the implementation process and indicative timeframe be?

I need more debugging proficiency and I'm really reluctant to go through the process of getting comfortable with relative addressing.

[buchen]

Your comments in the issue and thumbs up seem to indicate you are supportive of this draft pr. What would the implementation process and indicative timeframe be?

I "+1" the change because of the idea: allow for a simpler format while keeping backward compatibility (in terms of being able to read old files and in terms of being able to stay on the old file format because one has written code against it)

I haven't had the time to look deeper into the code to see that it actually meets those requirements. And it will not make it into today's release. July is super busy for me but I hope to carve out some time.

[pfalcon]

I haven't had the time to look deeper into the code to see that it actually meets those requirements. And it will not make it into today's release. July is super busy for me but I hope to carve out some time.

Yes, that's how it should work (does work for me), but surely please take your time to review and test it.

Something I also wanted to mention that I'm using Maven to build / simple editor to edit files, so any resource changes were done manually. E.g. Application.e4xmi, or "xml:id" attributes, I took an existing id from other element and suffixed with "1" to create another unique look-alike. Perhaps, it should be regenerated in Eclipse when you merge.

[pfalcon]

@buchen: Friendly ping.

[buchen]

Back from vacation. Merged.

[pfalcon]

Thanks!

[pfalcon]

I tried to read thru forum references in the commit message above to try to understand what was the underlying problem. https://www.wertpapier-forum.de/topic/38306-portfolio-performance-mein-neues-programm/?do=findComment&comment=1728580 gives example from an XML file:

<latest reference = "../../security[49]/latest" />

I.e. the same LatestSecurityPrice object is somehow shared between 2 securities. Couldn't easily anticipate that, but glad the issue was found and fixed quickly without need for more drastic reverts ;-).