[
Lists Home |
Date Index |
Thread 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:paul@prescod.net]
> 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"
argument
> > 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
necessarily
> > worrying which order they come in.
>
> I find that these are most often handled by attributes. Probably part
of
> 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
arguments.
> > It would certainly save people from having to write getopts.c, but
would
> > actually be an *impediment* to usability and user expectations.
>
> IMO, the usability problem with command lines is that sometimes
options
> 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
will
> 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
"order
> 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
where
> > the user *assumes* it will matter, but I think there are plenty of
other
> > cases where users would be unpleasantly surprised by finding that
order
> > 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
aren't
> 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
the
> 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
>
|
