[PATCH] XML validity of kcfg files

[Christian Mueller]

Am Samstag, 30. Oktober 2004 23:59 schrieb Zack Rusin:
> Question: why? What's the point of doing that? 

For example because validating the output of kcfgcreator can help you 
find bugs in the program?   I just tried the CVS HEAD version of 
kcfgcreator, and it doesn't seem to save the parameter's name attribute
I entered (which is required in the DTD and thus reported as 
an error by xmllint). The parameter section doesn't appear 
in the correct place either (according to the DTD).  
If that is to be considered a bug is still to be decided. 
It's invalid XML though. 



> How many people validate  
> Qt ui files? Instead of spending time on doing that, lets improve  
> kcfgcreator and get people to use that application to create xml files. 

I'm not an experienced Qt/KDE developer and have yet to see ui files 
first-hand so that may not count much, but my feeling is that they 
should be validated at some point in the tool chain, with informative 
error output.  



> Personally I never ever wanted to have developers learn another xml 
> format. I wanted to have an app to do all the tidious configuration 
> tasks for them. This is why I started writting kcfgcreator. Instead of 
> developing framework for validating files, lets finish means of 
> creating them. Fix the problem, not the result of it :)

Sure, kcfgcreator should be fixed before the old results are. 

But people *are* going to hand-edit those files. 
In the kcfg files that I've seen up to now there were 
missing type attributes, wrong type attributes and 
double appearances of <kcfgfile> tags.  This doesn't 
seem to produce errors in kconfig_compiler, but it 
may lead to strange behaviour (or confusion, if the developer 
happens to hand-edit the wrong one of those two <kcfgfile> tags
and his change is ignored.  I'm speculating here, of course...).  

What about 

- defining a real DTD or XSD that is for more than just documentation
  and that does not impose unnecessary restrictions on the order
  of elements (this may imply using XSD as Frans pointed out)
- fixing kcfgcreator to produce valid output (XML-wise)
- fixing the existing kcfg files
- adding XML validation to kconfig_compiler so that any 
  new errors (be it a bug in kcfgcreator or wrong manual changes)
  are reported right away and won't even make it into CVS
  because the developer would immediately fix his kcfg 
  or report a bug against kcfgcreator. 

in that order? 


The question is: 

- Do we make the DTD (or XSD) more than just documentation? 
  Then we should validate somewhere in the process of code 
  generation, that's even better than having a cron job 
  report the errors. 
- Or do we leave everything as it is and live with invalid XMLs
  which doesn't seem to be a problem (yet?).   

Anything in-between doesn't make much sense, IMHO. 
That decision is not up to me but I could offer some help 
correcting the existing kcfg files if we were going for XML validity 
and as soon as the DTD or XSD is final.  


Cheers, 
Christian. 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20041031/6dcda697/attachment.sig>