Validation, etc.

From: David Mertz <voting-project_at_gnosis_dot_cx>
Date: Sat Aug 09 2003 - 13:10:25 CDT

Couple addenda to my response to Matt, now that I looked at Anand's
note more closely.

|6. Expertise: Last but not the least, there are developers
| with wxPython/wxWindows experience in our group. I myself

I think this is an important thing. IMO, several other GUI libraries
would be fine also... but using what the current developers are
comfortable with is likely to produce the most reliable code the most
quickly. Libraries have learning curve, and quite a few of them are

|We also decided that the GUI layout should be based on XML data,
|which would make the layout extremely flexible. The application
|will read the XML upon starting up and layout the GUI elements.

The example I just posted only demonstrated the candiate/election
information in XML. But I agree that the layout should also be encoded
in a (separate) XML file. In both cases, I believe gnosis.xml.objectify
is a very easy way to get at the underlying data, and utilize it in a
natural way within Python code.

|XML parsers were mentioned in the discussion. I suggested PyXML
|and Matt suggested the gnosis.objectify module written by David.
|We need to arrive at a decision here looking at the nuances of each.
|It is clear that we need a validating parser

Basically, there aren't a lot of validating options in Python. I guess
there is xmlproc (pure Python, and not very maintained), and there is
PyRXP. For PyRXP, you need to build the underlying RXP library.
Neither PyXML's SAX/DOM nor gnosis.xml.objectify validates (mine
utilizes expat under the covers).

That said, I've been considering adding a PyRXP parser to
gnosis.xml.objectify. Currently you have a choice of using DOM or expat
internally (the latter much faster, but without fallback access to DOM
methods... which I find increasingly less important). If I were to add
a validating PyRXP parser to the mix, you would simply alter the call
to, e.g.:

    ballot = make_instance('ballot.xml',parser="RXP")

I would commit to creating that enhancement if Matt and Anand want to go
with gnosis.xml.objectify. During development, however, I expect there
will be a bit of flux in the DTD and ballot test cases. So my thought
is that you probably DO NOT want to validate from the very start anyway.
Or at the least, you want to be able to turn off validation for test

So I'd propose using gnosis.xml.objectify now, and utilizing an
independent validator during testing (i.e. it need not even be a Python
tool, just something to run at the command line). Before we deliver the
demo, we can make a one line change to enforce validation during the
actual on-screen ballot generation.

Yours, David...

Keeping medicines from the bloodstreams of the sick; food from the bellies
of the hungry; books from the hands of the uneducated; technology from the
underdeveloped; and putting advocates of freedom in prisons.  Intellectual
property is to the 21st century what the slave trade was to the 16th.
= The content of this message, with the exception of any external 
= quotations under fair use, are released to the Public Domain    
Received on Sun Aug 31 23:17:04 2003

This archive was generated by hypermail 2.1.8 : Sun Aug 31 2003 - 23:17:17 CDT