XML Schema for OS API 1.1 does not load

Bug #752929 reported by justinsb
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Invalid
Undecided
Unassigned

Bug Description

The schema for the OpenStack API v1.1 does not load in lxml; the error I'm getting is this:

(nova.api.openstack): TRACE: XMLSchemaParseError: complex type 'Metadata': The content model is not determinist., line 38

I'm trying to use it like this:

def _load_schema_cloudservers_v11():
    filename = os.path.join(os.path.dirname(__file__),
                            'schemas/v1.1/api.xsd')

    schema_tree = etree.parse(filename)
    schema = etree.XMLSchema(etree=schema_tree)
    return schema

This is the schema as available here:
http://bazaar.launchpad.net/~annegentle/openstack-manuals/trunk/files/head:/doc/source/docbkx/openstack-compute-api/

Revision history for this message
Brian Lamar (blamar) wrote :

I'm not sure if it helps, but a quick look at the schema shows that the issues lie in the following lines:

xmllint --schema server.xsd "<ignoreme/>"
common.xsd:38: element complexType: Schemas parser error : complex type 'Metadata': The content model is not determinist.
server.xsd:427: element complexType: Schemas parser error : complex type 'Servers': The content model is not determinist.
server.xsd:518: element complexType: Schemas parser error : complex type 'Addresses': The content model is not determinist.
server.xsd:527: element complexType: Schemas parser error : complex type 'AddressList': The content model is not determinist.
WXS schema server.xsd failed to compile

Removing those 4 lines makes the schema validate, but since I've never used an xml schema, those lines are probably important? :)

Revision history for this message
Jorge L. Williams (jorgew) wrote :

The schemas are described in XSD version 1.1 with support for backward compatibility with XSD 1.0. Looks like lxml doesn't support 1.1 schema or the backward compatible attributes (min/maxVersion).

As a work around, I've written an XSLT that allows converting the XSDs to version 1.0. I'm attaching this. My recommendation would be that we process the XSDs with the XSL before we have lxml consume them.

Going XSD 1.0 means that while we can validate core attributes and elements, we won't be able to find errors with the extensions. Not a big deal since there are no extensions defined right now anyway.

I realize that there are only a few 1.1 implementations but things seem to be moving in this direction and we have good work arounds for the time being.

You can run the XSL with xsltproc, you should be able to automate this in the code

 xsltproc .s1.0p.xsl server.xsd

Revision history for this message
Brian Waldon (bcwaldon) wrote :

Thierry: I think this is probably a non-issue now

Thierry Carrez (ttx)
Changed in nova:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.