On 17/10/2007, Boris Kolpackov &lt; boris@codesynthesis.com &gt; wrote: &gt; &gt; noah_mendelsohn@us.ibm.com &lt; noah_mendelsohn@us.ibm.com &gt; writes: &gt; &gt; &gt; BTW: don't infer from the length of the above lists that I'm against &gt; &gt; UPA; I've been in favor of it, and it's sufficiently important to &gt; &gt; our database implementors among others that I remain in favor. &gt; &gt; I've also noticed that people who struggle with UPA are invariably &gt; trying to create vocabularies which, while may be more suitable for &gt; human consumption, are hard to handle in software due to overloading &gt; of the same markup for multiple purposes. I'd agree with that - it seems XML designed to be easy to validate using XML Schema can also be easier to parse and process. It may sometimes look like it could be more compact (and perhaps it's wrong to be thinking about XML Schema when designing your XML) but it works. There aren't many guidelines for designing XML (are the any at all?) but perhaps that's a reasonable guide to follow. For example, re-writing a co-occurance constraint: &lt;foo type="a"&gt; &lt;a/&gt; &lt;foo type="b"&gt; &lt;b/&gt; to: &lt;foo&gt; &lt;typea&gt; &lt;a/&gt; &lt;foo&gt; &lt;typeb&gt; &lt;b/&gt; ...makes it possible fully constrain &lt;foo&gt;. The other benefit is that if you would normally do some action at the &lt;/foo&gt; end element that depends on the type attribute you have to keep track of it yourself (in a SAX based model), using the latter approach you can do the action in the appropriate end element. Hmm,