[webkit-dev] New XML format for .in files

Maciej Stachowiak mjs at apple.com
Wed Jun 11 12:55:40 PDT 2008


Here's what the new format looks like (WebCore/xlinkattrs.in):

<attrs namespace="XLink" cppNamespace="WebCore" namespaceURI="http://www.w3.org/1999/xlink 
">
<actuate/>
<arcrole/>
<href/>
<role/>
<show/>
<title/>
<type/>
</attrs>

I must admit I don't really like this. First, if we need to have this  
info in the file, I think it would be simpler to use a simple custom  
format with a few key-value entries to start and then the attributes:

namespace=XLink
cppNamespace=WebCore
namespaceURI=http://www.w3.org/1999/xlink
actuate
arcrole
href
role
show
title
type

This would still be easier to parse than XML and certainly easier to  
author.

Second, I think this is a poor use of XML - having a new XML tag name  
in this .in file for every attribute or element in a namespace means  
there's no real defined XML language here, the tag names are  
completely ad-hoc, which means this is effectively putting content in  
markup, which is not good. The more natural XML-style way would be to  
say <attr>actuate</attr> instead of <actuate/>, but of course that  
adds more syntactic noise. So again I think the plaintext format is  
better.

And finally, I am not sure I like defining all the parameters to the  
generator script inside the file. For example:

<attrs namespace="SVG" cppNamespace="WebCore" namespaceURI="http://www.w3.org/2000/svg 
" generateFactory="1" generate
WrapperFactory="1" guardFactoryWith="ENABLE(SVG)" nullNamespace="1">

This is defining what actual implementation files get generated, and  
what #ifdef guards to put into them, which seems like too much  
implementation detail to put into a file defining attributes. I think  
it does make sense to put the namespace URI in, but it doesn't seem  
right to include details about the generated files. The .in files  
should stick to holding the data, not the implementation details, in  
my opinion.

Comments?

Regards,
Maciej



More information about the webkit-dev mailing list