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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
