Re: [Vala] Announce: Acme.Xml 0.1.0, wrapper for libxml2's xmlTextReader/xmlTextWriter API

[Richard Schwarting <aquarichy gmail com>]

Hi Simon,

Daniel's right that we'd love to have XmlTextReader and XmlTextWriter wrapped in GXml; it's on the list of things to do, along with XPath and SAX.  If you'd like to merge your work eventually, feel free to use a branch in the gxml repo. :)  I like your idea for XmlReader as a proxy class.

Importantly, some classes are changing their names to comply with the W3C DOM Level 1 Core spec, and the error handling methodology is changing to comply with GError's intended usage (that is, we're switching to g_error): the work there is mostly done in the branch gsoc2013 and will be merged soon.

There's the general desire to at some point replace the libxml2 implementation behind GXml with a native GObject one, but I'm not in any hurry to do it because that's just more to maintain, and new bugs to fix.  Daniel, I previously discussed rewriting it in Vala, but at GUADEC there was a strong concensus in favour of replacing it with native C, due to issues with libraries written in Vala, particularly from the experience of the libfolks developers (the most notable GNOME library written in Vala); again, I'm in no hurry.

libvala's library name is itself versioned (e.g. instead of checking that libvala >= 0.18, it's actually libvala-0.18 >= 0.18, which I'm sure is wrong).  I intend on copying what libfolks does to handle that.  Regarding NodeType, hehe, the stringification of enums was awesome when I discovered it; I wrote that todo when I started this during GSOC 2011 and was relatively new to Vala. :)

Cheerio,
  Richard

On Thu, Aug 15, 2013 at 7:18 AM, Simon Kågedal Reimer <skagedal gmail com> wrote:

On Tue, Aug 13, 2013 at 5:58 PM, Daniel Espinosa <esodan gmail com> wrote:
>
> Don't worry all here are volunteers. I would like to see your work in a
> branch of GXml, it almost compile in master (if not please tell me and can
> fix it for you).

Ok, I hope to have a go at this during the weekend. It does make
sense, as you say, to do this earlier rather than later. There is only
really one overlapping type, the enum GXml.NodeType [1] vs.
Acme.XmlNodeType [2].

A note on a comment in [1]:

   // TODO: want a method to convert NodeType to a string

Vala provides this automatically! For example,
GXml.NodeType.ATTRIBUTE.to_string () will give "ATTRIBUTE". If one
wants a nicer representation, perhaps "Attribute" instead, one can
manually override to_string(); see this blog post: [3]

I've also used this technique in Acme.XmlNodeType for a method that
checks if a node of type X can be a parent of a node of type Y, useful
for sanity assertions. I assume that the same rules apply in the DOM
as when reading?!

I think that the values for this enum should be explicitly given, as
they have to correspond with the same values in libxml2. This also
makes the Vala bug mentioned in a comment in [1] not relevant.

[3] http://blog.yorba.org/jim/2011/05/a-few-of-my-favorite-vala-things-enums.html

>> I've also considered not using libxml2 for at least some parts. The
>> XmlWriter would not be too difficult to rewrite in Vala. This would
>> make things a little more manageable. I've also peeked in the Mono
>> sources, they have an implementation of this that one could try
>> porting from C# to Vala.
>>
>
> This is a great idea! Just we need to check license issues.

The license shouldn't be a problem, the Mono classes are released
under the MIT license. What could conceivably be a problem is the
scare of Microsoft patents. The core XmlReader/XmlWriter stuff is part
of the ECMA-335 [4] standard, so that isn't a problem, but Mono also
implements additions from Microsofts .NET classes. I don't think this
is a problem either, but others might disagree.

> Richard have the idea to rewrite libxml in Vala any way, may be most of your
> work will be reused by DOM.
>
> I think use Xml.TextReader behind is really good to parse XML documents.

Yes, I agree it makes sense to have Xml.TextReader as the core parsing
module. This is also what Mono/.NET does. libxml2 is kind of the other
way around, the TextReader built on top of SAX and DOM. For efficiency
it could be beneficial to reimplement/port TextReader as a straight
forward-only non-caching pull parser. However, it would be unwise to
prematurely throw out libxml2 since it provides lots of useful
features, DTD validation, XML Schema validation, RELAX-NG
validation.... etc. There's an impressive effort behind it, even if
the API and documentation is a bit messy.

One idea would be to have XmlReader as a proxy class that uses
different implementation classes under the hood. If no validation or
other other features are requested, we could use our own parser. If
needed, we use libxml2 (but hide it's complexity, i.e. we don't let
the user specify all kinds of parser options that libxml2 exposes).
(We wouldn't use our own parser unless/until it provably has benefits,
such as performance or features that might be hard to implement using
libxml2 such as an async TextReader.) But this is just thoughts on
possible directions in the future.

Of great importance here is of course conformance testing. I've begun
work on testing Acme.XmlReader/XmlWriter with W3C's XML Test Suite
[5].

> Just Richard have created. These are the firsts messages.
>
> And need to suscribe I think.

Ah, I had subscribed, just missed the "confirmation needed" mail. :)
Now I'm properly subscribed.

Regards, Simon

[1] https://git.gnome.org/browse/gxml/tree/gxml/NodeType.vala
[2] https://gitorious.org/fido/acme-xml/blobs/master/acme-xml/acme-xmlnodetype.vala
[3] http://blog.yorba.org/jim/2011/05/a-few-of-my-favorite-vala-things-enums.html
[4] http://www.ecma-international.org/publications/standards/Ecma-335.htm
[5] http://www.w3.org/XML/Test/