Re: optional, but at least one required

On 17/10/2007, Boris Kolpackov <boris@codesynthesis.com> wrote:
>
> noah_mendelsohn@us.ibm.com <noah_mendelsohn@us.ibm.com> writes:
>
> > BTW: don't infer from the length of the above lists that I'm against
> > UPA;  I've been in favor of it, and it's sufficiently important to
> > our database implementors among others that I remain in favor.
>
> I've also noticed that people who struggle with UPA are invariably
> trying to create vocabularies which, while may be more suitable for
> human consumption, are hard to handle in software due to overloading
> 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:

<foo type="a">
  <a/>

<foo type="b">
  <b/>

to:

<foo>
  <typea>
    <a/>

<foo>
  <typeb>
    <b/>

...makes it possible fully constrain <foo>.  The other benefit is that
if you would normally do some action at the </foo> 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, not the best example but the only one I can think of at the moment :)


-- 
Andrew Welch
http://andrewjwelch.com
Kernow: http://kernowforsaxon.sf.net/