> That's a good start. You're missing one requirement that I think needs to > be explicit. Presumably you're requiring that the XML be well-formed. This > refers to things like matching <xxx> and </xxx> nodes, and proper use of > quotes and escaping within strings. Most DOM parsers won't even give you a > tree if the file isn't well-formed.
I actually hadn't been checking for well-formedness on the assumption that ElementTree's parse method did that behind the scenes. Is that not correct? (I didn't see any specifics on that subject in the docs: http://docs.python.org/library/xml.etree.elementtree.html) > But most importantly, you can divide the rules where you say "if the data > looks like XXXX" the file is rejected. Versus "if the data looks like > YYYY, we'll pretend it's actually ZZZZ, and keep going. An example of that > last might be what to do if somebody specifies March 35. You might just > pretend March 31, and keep going. Ok, so if I'm understanding -- I should convert invalid data to sensible defaults where possible (like setting blank fields to 0); otherwise if the data is clearly invalid and the default is unknowable, I should flag the field for editing, deletion or some other type of handling. _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
