I will look at this shortly; thanks for the patch!

And by shortly, I meant to do it before going to GUADEC, and I didn't manage to, and it's been mayhem since, so I'm looking at it now.

That looks really awesome.

So, there's some API changes happening for the Google Summer of Code 2013, and they're currently in a branch, gsoc2013.  The most notable ones are changing of class names GXmlDomNode -> GXmlNode, and replacing GError usage with g_error calls.  I'm going to be merging the changes next week.  If you don't want to adapt your patch, I can do that for you. :) 

You should feel free to include your name in the copyright header for the files you created. :)  I noticed you copy and pasted the header so my name is now appearing on files I've never touched. :D

Overall, it looks awesome, and there shouldn't be any problem getting it committed.  Do you mind if I take a week to play with it?  (It won't be three weeks this time!  No GUADEC or dead computer expected :D)  If you have access, feel free to create an xpath branch in the gxml repo.

Thanks for the awesome work!

I don't mind at all :) I wan't be able to work on it till next weekend anyway.

I was not aware of your GSoC work (branch was not on git.gnome.org back then), actually it's pretty hard to find any information about GXml. Unless I'm very mistaken there's no project page on wiki.gnome.org, no documentation on valadoc.org. I only found out about it's existence when I was looking for how to use vala with autotools (-> https://wiki.gnome.org/Vala/Tutorial#Using_Autotools). What i'm just trying to say is that you'll probably get more contributions if more people knew about GXml :)

I don't have write access to git.gnome.org -- I'm just learning Vala for fun :)

One more thing that came to my mind lately is that my implementation of namespace resolver is somewhat broken. I thought of it as pure constant element, something like:

namespace MyApp {
  const GXml.XPath.NSResolver MY_NS_RESOLVER = new GXml.XPath.NSResolver(
    "ns1", "uri://location-1",
    "ns2", "uri://location-2"
  );
}

Obviously this is not possible in Vala (not even in class context). I thought maybe you would have better idea how to make it more convenient to use... As I said, I'm pretty new to Vala, there may be many things I don't now yet ;)

Anyway, I'm very happy that you find my patch useful. I'm looking forward to more comments from you!

There used to be http://live.gnome.org/GXml, but because it was part of my GSOC, someone renamed it to a GSOC-templated URL.  I've recreated a simple one for now.  And we have a mailing list since a couple of days ago.  Whee.  Most promotion has occurred on Planet GNOME.

The gsoc2013 branch has been merged with master now.  Whee.

I'm sorry I haven't had more time to integrate your patch yet; I think I won't really have an opportunity until the GSOC is over.  (If you get time beforehand to rebase it, I'll try to commit it.)

Hello :)

My first attempt to rebase my patch against current master failed, but fear not! I only have some questions...

I see that DomError is now replaced by enum DomException and GXml.warning method. I don't quite understand reasoning behind this change. W3 docs call it exception -- like exception shall it behave. Especially when that's exactly Vala's native method of error handling. (Other question, not much related to this report: how user will know something went wrong in constructor? or in method that doesn't return anything? It looks like they must set last_error to NONE before the call)

My monday-grumpy-comments aside ;) I'm not sure how to replace XPath.Error in this context. I can create XPath.Exception enum along with XPath.warning, but it doesn't sound particurarly appealing. Or can I add those two XPath error codes to DomException?

Still no idea about NSResolver, guess I'll leave it that way for now. Maybe someone else will improve it in the future.

Hi Adam.

Sorry for the late reply.  I'm going to look at the patch again and then provide advice for XPath error handling!

=Short version=
Exceptions went away because they're explicitly not GError's intended usage (which is recoverable errors, not programming ones, which most of those are) but I agree that we should have GErrors on constructors! :D

=Long version=

Yeah, let's add exceptions to the constructors. :)

So the reason for the switch to GXml.warning is because of the intended usage of GError, which is for recoverable runtime errors that you can't reasonably expect, as opposed to programming errors, which can be determined in advance.  For references, 

1. https://developer.gnome.org/glib/2.34/glib-Error-Reporting.html
2. https://wiki.gnome.org/Vala/Manual/Errors
3. https://wiki.gnome.org/Vala/Tutorial#Error_Handling
(Relevant excerpts are below)

I originally handled it as exceptions because the DOM uses that style, but problems with that were:
a) it violates the intended usage of GError (and Vala's exception handling) since most of the errors are programming errors rather than recoverable run-time exceptions.
b) it added tediousness to programming, since we don't have a quiet RuntimeException class as in Java, and in C, almost every function call ends up with either an extra NULL parametre, in which case you won't notice your errors, or get error-handling, even though in most cases the DomExceptions are avoidable.

Initially I liked using the Exceptions because I was only using the library from Vala, but I was persuaded by other GNOME developers to change to GLib.warning. 

Regarding the interpretation for a) that we violate GError's intended usage, there's a blog post here looking at each DOMException:
http://blog.kosmokaryote.org/2013/06/technology-domexception-its-nature-and.html
Basically all of those are things that shouldn't be unexpected.  You might note that a couple exceptions were considered as run-time there, like whether the implementation supports a function, but the solution to that is to add support. :D

----

"First and foremost: GError should only be used to report recoverable runtime errors, never to report programming errors. If the programmer has screwed up, then you should use g_warning(), g_return_if_fail(), g_assert(), g_error(), or some similar facility. (Incidentally, remember that the g_error() function should only be used for programming errors, it should not be used to print any error reportable via GError.)
  Examples of recoverable runtime errors are "file not found" or "failed to parse input." Examples of programming errors are "NULL passed to strcmp()" or "attempted to free the same pointer twice." These two kinds of errors are fundamentally different: runtime errors should be handled or reported to the user, programming errors should be eliminated by fixing the bug in the program. This is why most functions in GLib and GTK+ do not use the GError facility." [1]

"Vala Error handling is just for recoverable runtime errors, anything that can be reasonably foreseen should not be handled with errors, e.g. passing the wrong args to a method. In that example, a better action is to state that the method's result is undefined on illegal input, and use method contracts or assertions to catch potential problems during development: See Methods/Contract programming. A more suitable use for errors would be reporting missing files, which of course cannot be detected until the program is running." [2]

"GLib has a system for managing runtime exceptions called GError. Vala translates this into a form familiar to modern programming languages, but its implementation means it is not quite the same as in Java or C#. It is important to consider when to use this type of error handling - GError is very specifically designed to deal with recoverable runtime errors, i.e. factors that are not known until the program is run on a live system, and that are not fatal to the execution. You should not use GError for problems that can be foreseen, such as reporting that an invalid value has been passed to a method. If a method, for example, requires a number greater than 0 as a parameter, it should fail on negative values using contract programming techniques such as preconditions or assertions described in the previous section." [3]

There's now a 'xpath' branch in git with your code.

I'm rethinking how attributes are handled.  The one test fails because GXml.Document.lookup_node doesn't support xmlAttr->GXml.Attr, which was intentional because strictly speaking xmlAttr != xmlNode, but from what I've learned since, the xmlAttr's struct is structured to be compatible with xmlNode in a lot of cases, so we're probably going to just simplify attributes by treating them as xmlNodes, which will result in their being lookupable too!  That's happening in the branch 'newattr', but I probably won't have time to finish that this week. 

;_;

Please consider to port your code to new API interfaces in GXml 0.8 and above, I would like this feature back for 0.12 release.

With bug #772102 we have added basic XPath support. Any bug related to it please file it agains XPath component of GXml.