I talked a bit with pippin on IRC and I'm hoping that we can have a real discussion (or at least shed a bit of light, for me) about how meta-op deserialization should look from a conceptual stand-point (i.e. not the specific XML format). The big thing is understanding the use-cases for XML meta-ops. I see two distinct directions XML meta-ops could go:

1) The graph structure along with pad and property proxies is defined in XML. Loading the XML returns a GeglNode with all this set up and that node can then be used in a larger composition graph. XML files can contain just a meta-op, or a composition which contains one or more regular operations and meta-ops.

2) The XML defines a single meta-op with property and pad data and is loaded into GEGL and registered via an API call so that new nodes can subsequently be created with the meta-op name as the operation. The meta-op transparently joins regular operations in GEGL's database.

In the first case, the meta-op XML definition would be a subset of the regular graph serialization/deserialization code. I'm starting to get the impression that the latter case is the desired one. Is the plan to move existing operations such as drop-shadow from C to an XML description? Should XML meta-ops be loaded by GEGL at startup along with compiled C operations (in shared object format) from GEGL_PATH? If this is the case, then I can see that the meta-op XML spec is distinct from the composition spec outside of the future-possibility of embedded anonymous meta-ops. Compositions may also reference XML meta-ops by filename so that they are loaded at the same time that the composition is loaded, but compositions and meta-ops have otherwise separete deserialization. How am I doing? What is the expectation as to how meta-op XML loading will look and work?