[fpc-pascal] XML-XSD export: importer & how to test

Ludo Brands ludo.brands at free.fr
Thu Jul 28 18:02:21 CEST 2011



> -----Message d'origine-----
> De : fpc-pascal-bounces at lists.freepascal.org 
> [mailto:fpc-pascal-bounces at lists.freepascal.org] De la part 
> de Reinier Olislagers
> Envoyé : jeudi 28 juillet 2011 16:29
> À : FPC Mailing list
> Objet : [fpc-pascal] XML-XSD export: importer & how to test
> 
> 
> On 28-7-2011 15:13, Reinier Olislagers wrote:
> > On 28-7-2011 14:36, Ludo Brands wrote:
> > 
> > I'll get to the issues some time after the test framework 
> > improvements.
> > 
> > If you prefer to, please feel free to directly enter the issues: 
> > https://bitbucket.org/reiniero/fpc_laz_patch_playground/issues/new
> > 
> > In addition, I could also give you write access to the bitbucket 
> > mercurial repository...
> > 
> > Regards,
> > Reinier
> 3. Regarding the tests: I thought about better ways of 
> testing the exports. The only fairly easy way I see is 
> testing with more databases (such as mysql which you were 
> doing), maybe by adapting the existing fcl-db test framework. 
> Haven't ever run that though, but I can learn ;)
> 
I used mysql because I have some testtables in mysql that contain almost all
mysql types which I used in another project. Downside is that you test as
well the sqldb mysql implementation as the export. IMHO building testcases
with MemDataset using the different built-in datatypes and border-line
values (limit values for integers, special characters in strings, etc.) is
going to be a cleaner solution. Will make regression testion also easier.

> Another solution would be to verify the xml output, but then 
> you're basically writing an importer for the export format ;) 
> Could be worthwile in the case of Delphi Clientdataset though...
> 
A different export output doesn't mean that the importing application
imports something different. The final test is importing in a foreign
application. 

> Any thoughts on how to improve the tests?
> 
> 4. Would it actually make sense to start an importer project 
> that imports e.g. clientdataset, csv, into a dataset? Is 
> there already something like that?
> 
> 5. I briefly thought about including OpenOffice Calc (ODT) 
> format exporting but that seems a bit overkill as there 
> already is a CSV export format. Any thoughts on new formats - 
> apart from Atom ;) ?
> 

IMHO making additional specific exporters for calc / excel type of
applications isn't very usefull. Spreadsheets don't have real typed data and
can infer quite well a "schema" for xml data that don't contain one. The XML
data these apps export contain more presentation type of info than data type
related info. As you wrote, csv is good enough for these apps and has far
less overhead.

Ludo

> Thanks,
> Reinier
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org 
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
> 




More information about the fpc-pascal mailing list