We've wanted to create an XML schema for our recipes for a long time
because it would enable us to validate a recipe before actually passing
it to our parser which also runs external actions while parsing. And
now when we finally have our recipe structure finalized with only small
changes being expected, I decided to create this XML schema.
I have a usable schema ready and I will be attaching it will be attached
to this email. However I first want to note that there are a few
problems with what the schemas can and can not do.
First of all our recipes are designed in a way that some attributes
influence the contents of the associated element, for e.g:
<interface type="eth" network="foo">
Not only does the 'type' attribute determine which elements are allowed as
subelements of the 'interface' element, but it also determines if the
attribute 'network' is required or forbidden. This is of course a valid
XML structure, however XML schemas are unable to describe this
situation. According to what I've found this should be done by removing
the element 'interface' and instead use multiple elements
'interface_eth', 'interface_bond', and so on.
The same problem can be also seen in the element 'command' where we have
attributes that are only allowed when 'type' is of a certain value.
And the same can be seen in elements that have either a 'value'
attribute or the value is the contents of the element. This however is
probably just a bad design decision because it introduces
nondeterminism, though I understand why we made it this way.
The next problem I found is that we wanted to define the types of certain
attributes. This could prove to be a little difficult due to our use of
template functions. For example we could have an attribute that expects
an integer and a function that returns that associated integer. However
the schema validation would see the string that calls the function and
not the integer. This could theoretically be solved by extending the
integer type to also accept strings matching a regular expression,
however then we would have different problems and I don't like this
solution in general.
The last problem is a small one- we wanted to make use of the schema to
somehow direct vim to help us with autocompletition when writing
recipes. I've found that this is not possible with XML schemas (unless
we ourselves write the vim script), but it is possible with DTDs, with a
catch. Vim versions 7+ have native ability to autocomplete XMLs by their
DTD, but we have to supply it with a xml-omni-datafile that can be
generated from the DTD. The file then has to be placed in a specific
directory. The full process is described here :
In case anyone wants to try the DTD I have created that as well and will
be attaching it. The DTD has a few more limitations compared to the
schema, mainly some elements have to be in a specific order so watch out
The problems that I've listed are the reason why I'm not sending the
files as patches. I think that we will have to rethink our usecases for
the XML schema and DTD before I finish them. Our main use case is
definitely recipe validation before it's parsing, which can be done in
* rewrite the parser to use a different XML library, from my point
preferably lxml - potentially a lot of work
* do the validation separately and therefore call two different xml
parsers - simple but not as nice looking
If anyone wants to try to validate their recipes the easiest way I found
is to use lxml in python using this tutorial . lxml library is not a
part of python distribution but I have it by default on both my Fedora
machines and my RHEL machines so it shouln't be a problem.
I apologize for the huge email but I wanted to share my thoughts on this
as my exams are coming up so I don't know how if I will be able to
Any feedback is appreciated.