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

[Maciej Stachowiak]

On Jun 11, 2008, at 1:41 PM, Eric Seidel wrote:

> Julien and I discussed some of these during the patches.  I'm sure
> he's open to further suggestions.
>
> 1.  The idea has been that "long term" xml is easier than a custom
> parser (He's been slowly moving more of the custom-hacks in the perl
> script into .in file data).  I agree, the current solution is
> less-than-ideal to author, and I certainly agree things like

In my experience, that's not really true, if your file format is very  
imple.

> (2.)
> <tag>href</tag> are even worse.
> 3.  Julien and I discussed this as well.  I decided it was less than
> ideal, but not worth worrying about.  Dealing with maintaining the
> right command line flags in each of the 8 build systems people use
> seemed more of a pain than this data/logic violation.

The only place that should need to know about the flags is  
DerivedSources.make. And it has to know what files are getting  
generated anyway, to get the dependencies right. Furthermore, the  
different build systems do have to be changed to add the right files,  
which is probably going to be more confusing if what files are  
generated is implicit in the contents of the .in file.

> I would encourage you to discuss this at greater length with Julien  
> over IRC.

I sent email on purpose because I'd like us to start discussing more  
technical issues like this on the mailing list. Mailing list  
discussion makes it easier for people who aren't on IRC all the time  
or not in the right time zone to follow the technical discussions of  
the project. But I am happy to discuss on IRC as well.

Regards,
Maciej

>
>
> -eric
>
> On Wed, Jun 11, 2008 at 12:55 PM, Maciej Stachowiak <mjs at apple.com>  
> wrote:
>>
>> 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 at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>