[fpc-devel] fpXMLXSDExport questions and possible bugs/issue(s)

[Michael Van Canneyt]

On Sat, 28 Jun 2014, Walter Prins wrote:

> Hello,
>
> As background: I'm a Delphi developer, though I've been aware of FPC
> and Lazarus for a long time.  Recently I ran into a situation where I
> needed to generate an XML format that could be ready by a third party
> application, and it turned out that the ADO.Net XML format might be
> suitable. After a bit of searching I located the FreePascal
> fpXMLXSDExport module, which contains a class that claimed it could
> write this format and which sounded perfect if it would work.
> I thus proceeded to convert the code to compile/run under Delphi (XE.)
> This process was surprisingly easy and the code needed only a couple
> of small adjustments to initially compile.
>
> I did run into a couple of issues/problems getting it running
> correctly, related to Delphi and types.  These I eventually fixed,
> they are relatively minor and the code should still work on FPC.  (not
> tested yet.)
>
> More problematic: I ran into issues with the format of XML produced by
> the class, which wasn't in fact compatible with ADO.NET for the data I
> tested -- When I initially tried to read a file output via an app
> (using Microsoft .Net mscorlib), it failed with "invalid string
> format" errors.
>
> I eventually managed to track down the source of this problem, which
> was basically that null values was being output with empty nodes into
> the XML file (e.g. <tag></tag>). This is apparently not avlid and
> instead one should just leave them out entirely.  I thus subsequently
> found the offending code in the FPC class and fixed it output XML that
> is correctly read by mscorlib

Good to know, I recently used the class in some production code.
The resulting code has not yet been released to clients, 
so I'm highly interested in your patch.


> So, consequently I have several questions:
>
> 1) Do you care about Delphi compatibility at all? (E.g. would you be
> interested in the tweaks I made to to the code to enable Delphi to
> compile it, providing it doesn't break FPC?)

No problem with that.

> 2) Do you care about the changes I made to ensure correctness when
> used with Delphi?  (Again obviously only if this doesn't cause any
> issues for FPC?)

This is not a problem, either.

One caveat:
If the code gets riddled with IFDEFs, it is another matter.
one or two places, this is OK, but not if every line needs a change.
The code then becomes unmaintainable.

>
> 3) Are you interested in the fixes for the ADO.NET exporter class in
> FPC library?  As it stands this class doesn't in fact generate ADONET
> compatible XML (meaning, at least on my PC the XML it outputs isn't
> readable by ADO.Net mscorlib) and is effectively therefore broken.

Definitely interested :)

>
> 4) Finally there's several other loose ends I noticed in the code --
> no way to set TableName, no way to set Dataset (collection) Name, no
> way to add more tables into the dataset.  (In my use case this would
> be useful.)  I might look into these enhancements and will submit
> patches if there's interest.

There is. 
I have this part already in a private copy, but was waiting to put this
back in the FPC source tree. I made the 'UseCurrentLocale' attribute also settable.

>
> I'm interested in submitting patches for some/all of the above points
> if there's any interest. If so, I'll try ensure I test the changes
> using FPC etc before submitting etc.
>
> Assuming there's interest, what would be the preferred way to proceed?

There is definitely interest.

Prepare a patch with all the changes, and upload to the bugtracker. 
You can assign them to me or Reinier.

It would be ideal if the patch is split in separate patches that address the various issues,
but I will not insist on that.

Michael.