Lists Home |
Date Index |
That makes sense. Attributes are unsuitable for some scenarios, but for
most cases I agree. Personally, I would like to see schemas that allow
attribute ordering as well, so that streaming processors could take
advantage of that too :-)
> -----Original Message-----
> From: Paul Prescod [mailto:firstname.lastname@example.org]
> Sent: Tuesday, January 21, 2003 11:59 AM
> To: Joshua Allen
> Cc: Eric van der Vlist; Jeff Lowery; Bryce K. Nielsen; xml-dev
> Joshua Allen wrote:
> > ...
> > That's an interesting point. I think the "user perspective"
> > becomes more difficult to back up when you have element content that
> > involves lots of optional children -- in those cases the user often
> > wants to be able to insert whichever elements matter without
> > worrying which order they come in.
> I find that these are most often handled by attributes. Probably part
> the tension in this discussion comes from people who have a natural
> aversion to attributes trying to use elements as attributes.
> > ... Imagine for example if command-line
> > apps were written to expect a certain order to command-line
> > It would certainly save people from having to write getopts.c, but
> > actually be an *impediment* to usability and user expectations.
> IMO, the usability problem with command lines is that sometimes
> are order sensitive and sometimes they are not. XML makes a clear
> distinction: attributes are not order sensitive. Elements are. Except
> when they aren't. Eric and others in this thread are arguing for the
> "except when they aren't" becoming more common.
> Another argument in favour of enforced ordering: decent XML editors
> insert the required elements in for you in the right order. But they
> can't if order isn't enforced, because they don't know what order the
> author wants. That's the irony of this discussion...we're saying
> doesn't matter therefore force the user to choose it."
> If you spend a little time in a decent XML editor you'll probably find
> that enforcing an order does the user a favour by letting their tool
> help them better. On the other hand, attributes are usually ideal for
> the cases where order REALLY DOESN'T matter and the XML editor will
> convey this by presenting the attributes in alphabetical order.
> > There are some scenarios where order naturally matters, and others
> > the user *assumes* it will matter, but I think there are plenty of
> > cases where users would be unpleasantly surprised by finding that
> > matters.
> Most of these can be handled with attributes. In a few cases the
> limitations of attributes are really a problem but more often people
> avoid them out of a minimalist distaste for an "extra feature." If XML
> had structured attributes this whole discussion would go away.
> Anyhow, the nature of the original question makes me nervous. We
> talking about a content model of the form:
> <!ELEMENT x (a? & b? & c? & d? & e?)>
> As I understood it, he wants more complex content model particles in
> options (that's why xsd:all isn't good enough). In my opinion, the
> resulting content model is going to be quite confusing. XSD's
> limitations may be arbitrary but IMO, they are (accidentally) pointing
> him towards better content model design.
> Paul Prescod