GSoC 2013 proposal: Implement XPath from scratch

[Nikolay Sivov]

On 4/11/2013 05:52, John Chadwick wrote:
> Hello,
>
> I am a student of computer science interested in entering Wine 
> development via GSoC 2013.
>
> Upon looking at the various suggested proposals, the project of 
> reimplementing XPath without libxml2 looked particularly interesting. 
> I am familiar with the C language, W3C DOM and XPath, and I believe 
> this is something I could do.
>
> I have a few questions I'd be interested in seeing answered:
> * One of the 'important things to keep in mind' is that "changes 
> should be incremental, with a fallback to libxml2 until new processor 
> is fully functional." Does this mean at compile time, or at runtime, 
> when the evaluator recognizes unimplemented features in an expression, 
> or something else entirely?
Yes, what I meant is that a transition should be as smooth as possible, 
it should be a runtime check like you described - if processor doesn't 
support something that's needed to process given expression it shouldn't 
fail completely, but fallback to existing code.
> * Is only MSXML 3.0 supported? It appears to be the only version 
> implemented in the Wine source tree.
It's just a way it's done. All code is in msxml3 dir, and msxml4 and 
msxml6 just forward to it, wine's msxml3 is able to create coclass 
versions that normally would live in msxml4 or msxml6. That's how code 
duplication is resolved.
> * What should I aim at doing first? Because what I'd be working on is 
> a library, I would probably need some application to test features 
> with (test cases aside.) Should I be using an existing program, or 
> writing a new one?
You should be writing tests for XPath API, and it should be placed 
somewhere in msxml3/tests. Currently it lives in domdoc.c cause XPath is 
a part of DOM API, but it will be probably okay to create a separate 
file if amount of tests is expected to be large enough (and it is imho).

Speaking of tests, it should be easily extendible meaning that adding 
more tests should be mostly a matter of adding more test data and not 
that much of a code. Currently in existing XPath tests returned node set 
forms some string representation and we compare these strings with 
expected ones. I don't really like this way mostly cause it's hard to 
read and relate to original tree, but we could discuss that and make it 
better or find another way.

By the way, the main reason why I added this topic to GSoC page was that 
it seems to me that it's possible to implement it incrementally, this is 
a very important, and XPath implementation is a significant part of a 
long term plan to stop using libxml2 and have our own code (likely a lot 
of own code).

If anyone has anything to add here or is even opposed to such project 
for some reason, I'd really like to hear that.
>
> Thanks,
> John Chadwick
>
>
>