caustin / schemavore Goto Github PK

The current implementation doesn't take into account ns or imports for rendering xml_nodes. This will be needed when implementing XSD and xml instance documents.

Complete implement length, maxLength and, minLength restrictions on schema node.

Currently if the data input does not match what is specified by lxml then some ugly errors are propagated up. Try to catch those and suggest a solution to the end-user.

Stand alone XSDs should be composed of simple/primitive elements. These should be able to construct themselves by interrogating the elements they contain. Also, rendering should respect the order the elements were declared in. A possible api could be something like the following:

class SimpleDocument(Document):
    first_name = String("firstName")
    last_name = String("LastName")

sd = MySimpleDocument()
sd.first_name = "Joe"
sd.last_name = "Smith"

xml = sd.xml_document
xsd = sd.xsd_document

The other implication of this is that value needs to yanked out of the constructor of the document....and that the setter method must properly validate the data at the model level before it hits the renders.

Get the setup.py cleaned up and working properly. Implement a test runner/suite to run all tests with python setup.py test.

Rework or consider an additional abstraction to support element type declarations in a XSD.
The goal, when declaring a type in a XSD is to produce the equivalent of the following.

    <xs:element name="car" type="carType"/>

    <xs:simpleType name="carType">
      <xs:restriction base="xs:string">
        <xs:enumeration value="Audi"/>
        <xs:enumeration value="Golf"/>
        <xs:enumeration value="BMW"/>
      </xs:restriction>
    </xs:simpleType>

The current implementation produces only the following.

<xs:element name="car">
   <xs:simpleType>
    <xs:restriction base="xs:string">
      <xs:enumeration value="Audi"/>
      <xs:enumeration value="Golf"/>
      <xs:enumeration value="BMW"/>
    </xs:restriction>
  </xs:simpleType>
</xs:element> 

Currently in simple elements where there are restriction the node is rendered thus:

    <xs:element name="s2" type="xs:string">
        <xs:simpleType>
             <xs:restriction base="xs:string">
                 <xs:minLength value="4"/>
                 <xs:maxLength value="6"/>
             </xs:restriction>
         </xs:simpleType>
     </xs:element>

The type="..." in the element name node is not required since it is present in the restriction node. So, it can be simplified as:

    <xs:element name="s2">
            <xs:simpleType>
                 <xs:restriction base="xs:string">
                     <xs:minLength value="4"/>
                     <xs:maxLength value="6"/>
                 </xs:restriction>
          </xs:simpleType>
     </xs:element>

Get the API documented. And write a readme.

Annotations will need to be added to the models

schemavore needs to support xml/xsd attributes. Implementing them should be relativity simple. Also, the XML primitive types must support wrapping and rendering the attributes correctly.

Consider making the element name parameter optional....

This works with a container document in mid...so

class MyDocument(DocumentBase):
    a = String()
    b = String().name = "aname"
    # or 
    c = String(name="aname")

So the xsd should render something like the following

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <xs:element name="a" type="xs:string"/>
    <xs:element name="aname" type="xs:string"/>

The problem becomes rendering this properly using schma_node descriptor as it exists today.....It need to have a way of determining the name.

Currently the XSD document is not rendering elements in the order that they are declared in the Document. This is not really an issue with a document composed of only simple elements but.........when I get to complex types in a sequence it will be necessary to respect sequence ordering. So, start now and not deal with the pain of adding it later