v3.4.1 bugfix for XBRL-JSON

Fixes #88 regarding XBRL-JSON DocumentInfo

v3.4.0 better iXBRL support

Fix #87 by adding support for having multiple schemaRef.
To avoid a breaking change, there are now two properties for Xml.Report:

• SchemaReferences collection property that contains 0-n SchemaReferences

• SchemaReference singular property that works just like before

  Getting the singular SchemaReference property returns the first item in the SchemaReferences collection property
  Setting the singular SchemaReference property resets the SchemaReferences collection property to contain just that one value

  If you handle reports that can only have one schemaRef, you can use the old singular property just like before,
  OR use the collection property if you like, OR use both.
  If you handle reports with (even possibly) multiple schemaRefs, use the collection property

Also fixed handling of unit namespaces that were left out.

v3.3.0

Fix #86 by adding options for inclusion of metadata in output.

            report.OutputInstanceGenerator = false;
            report.OutputTaxonomyVersion = false;
            report.OutputXmlDeclaration = false;
            report.OutputComments = false;

v3.2.2

Fix #85 by checking for null Scenario during comparison

v3.2.1

Fix #84 by adding new overload for Report.FromXml, remove code related to ESEF validations, added empty XML documentation comments, conversions between flavors, etc.

Reorganization - Breaking changes!

After starting to add support for xBRL-JSON it became obvious that the code needed restructuring.
So 3.0.0 comes with breaking changes to the naming and organizing of code.
Different flavors are now in their namespaces Diwen.Xbrl.Xml, .Inline, .Csv, .Json,
Diwen.Xbrl.Instance is now Diwen.Xbrl.Xml.Report and so on.
Test code was also similarly shuffled.
Functionally everything is still the same, performance wasn't affected etc.
Please get in touch if you can't find something, or you if have questions or comments.

v2.0.0

• Target .NET 8
• Some refactorings to xBRL-CSV functionality

Add xBRL-CSV support

1. This release adds support for xBRL-CSV reading, writing and conversion to/from xBRL-XML. As I only had EBA 3.2 material available for testing, it very likely won't work with other reports. This can be helped if get other material to test with (should include both formats for comparison)

2. There is also a change to default functionality! By default, when loading an xBRL-XML instance, duplicate facts are removed! This can be changed with a parameter. Most important reason for this was that some of the test reports I use had duplicate facts, which made testing harder is they weren't removed. Also I figure the business case for wanting the duplicates is less common than needing them removed. I am open to discussion about this if needed.

3. I am very likely going to create a new 2.x branch which will be based on .NET 6/7+ (ie. drop support for .NET Standard and .NET Framework) The 1.x version won't get new features or optimizations etc. (like xBRL-JSON support which I'm planning to start on)
   This is because the .NET Framework application this library was initially created for is nearing the end of its lifecycle, and with it the only application that I actually know that uses this library. One of the points of this library is that it is "standalone", doesn't have any dependencies. As .NET Standard doesn't have support for eg. System.Text.Json, this looks to be very limiting going forward. This change will also make life easier with linux, vscodium, and other tooling. Again I am open to discussion.

Fix segment explicit member namespace

Bug with namespaces used in the value field of a segment explicit member #76

v1.2.0

Fixes and changes to handling of IXBRL. Possible breaking changes due to namespaces.