Month: January 2017

With lot of work to do on XSD, but certainly happy to see GXml.Gom* classes taking shape, fixed lot of bugs since last 0.13.2 and starting to port some projects to this new version, I hope to soon release 0.14, just after most translation are in place.

This new version, will provide a better supported XML GObject wrapped, using DOM4 API and initials of other technologies like XPath and XSD.

Hope some one takes some time to implement XPath recent W3C specification and complete XSD support implementation. May be this will be a good projects for Google Summer of Code 2017.

On the process, I’ll try to implement W3C SVG API using GXml.Gom* classes, to provide a fully supported XML/SVG API using GObject libraries, and all other languages supported by GObject Introspection.

Future GXml versions, can include:

• Cleanup more interfaces/classes no useful any more, like TNode derived classes and other non DOM4 compliant interfaces. This will reduce number of classes to choose from, while recommend way will be on GNode and GomNode derived classes.
• Improve XSD support
• Explore how to manage large XML files
• Improve XPath support
• Explore XQuery

May be other ideas, from GXml users.

I love GInterface definitions, more in Vala, because they are clean an easy to describe API. Interfaces are the way W3C defines their specifications, like SVG and DOM4.

Vala interfaces definition are realy close to be a copy and paste from W3C’s specification definitions. With some, well a bit, work, you can transform them in usable GObject Interfaces definitions.

GXml take DOM4 interfaces and implement them, using a set of instantiable classes.

GXml provides a GObject to XML and back serialization framework, allowing you to define your own classes and how you want your data is represented in XML.

In order to read back your information, GXml needs to create, on-the-fly, instances of your classes, this means you need GObject ones no GInterface.

Starting to implement XSD support in GXml, I’ve created a set of interfaces to interpret W3C specification, this is really helpful, but unusable when you need to instantiate an object it is declared as a Interface. For example, if you have an interface A and it has a property of type B, but at the same time B is a GInterface, you can’t implement A and have an instantiable object from B: I mean, using g_object_new().

Because GXml engine, requires instantiable objects, to create new element nodes when found, using a GObject type to parse attributes to properties, for example, I ended creating a set of interfaces, to help me design an clean API, makes room for other implementations engines, but creating a new classes that will implement XSD interfaces having its own “mirror” properties.

This is, while GXml.XsdSchema have a GXml.XsdListSimpleTypes property to access to all simple type definitions, GXml.GomXsdSchema will have two properties with same purpose: a GXml.GomXsdListSimpleTypes property AND a property of type GXml.XsdListSimpleTypes to fully implement GXml.XsdSchema. Second one, will mirror the first. These is more work to implement an interface but keeps your classes’ properties instantiable, and your users can choose to use just GXml.XsdSchema interfaces API to access your class implementation, keeping open to use different implementations.

Best of all, with GXml implementation of XML to GObject, more clearly using GXml.Gom* classes, you will have access to *all* nodes, attributes and child ones found in an XML file, without loose them in the process of de-serializing back to your class instance.

While on the road to release GXml 0.14, I started to port some of my projects to new GXml.Gom* objects, in order to take advantage on speed and reduced memory footprint.

In the process, my library requires to define a large set of strings to select on for an element’s attribute. This is, PostalCode number. They are defined as XSD enumeration in a SimpleType.

At the begining, I started to define an array to add to GXml.GomArrayString[1], but found they are too many to maintain and error prone.

Then I desired to take a look at W3C Schema Specification and started to define a new GXml.Xsd* interfaces and a new GXml.GomXsd* classes to implement them. The result is: GXml.GomXsdArrayString [1], a new class taking an XSD file, to search a SimpleType definition and parse all enumerations, add them to an array of strings you can choose or validate your property value from.

These are the first steps in the way to get XSD support in GXml. While, GXml.Xsd* interfaces are unstable, and will continue this way after 0.14 release, will open new opportunities to any one consuming XSD definitions.

May be in the future, some one can use this API to create an XSD to Vala (or C) code GObject classes.

May other wants to help adding more object definitions from XSD specification in order to get patterns and other restriction from schema definitions, and improve data handling and validation.

[1] GXml.GomCollections definitions

[2] GXml.Schema definitions and GXml.GomXsd implementations