[
Lists Home |
Date Index |
Thread Index
]
On Tue, 2003-01-21 at 20:58, Paul Prescod wrote:
> 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.
I have no aversion to attributes, but have become much more restrictive
about when to use them in the last few months for the same kind of
reasons (ie extensibility) which made me advise prefering using Relax NG
"interleave" when possible.
When you are using an attribute in a schema you are pretty much stuck
with it and can't really extend it if needed: you can't duplicate it,
you can't add structured content in it and you can't further qualify it
with attributes.
I have thus become encline to use it as I think they have been designed
(to hold metadata) and be even more restrictive and say "to add metadata
which you have good reasons to think that it will not be extended".
> > ... 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.
No, I don't agree. XML says that the relative order between elements
needs to be reported to the applications, not that applications must pay
attention to it and still less that schema languages should enforce an
order!
In other words, it's giving us the possibility to pay attention to the
order but doesn't require us to do so and still less ask our
applications to blow up when someone provides a description before a
title.
> 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."
Whether you drink tea or coffee for your breakfast doesn't really
matter, therefore I'll force you to drink tea :-) ...
We seem to have different views on the personality of our users!
> 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.
But I don't want to use a decent XML editor: 1) I am very happy with vim
and 2) there is no decent editor available for my work station.
> > 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.
No, I don't think so. There are 2 issues here which would need to be
kept separated:
1) Should a schema enforce a relative order (when there is no reason to
do so).
2) Is the order meaningful.
When a schema doesn't enforce any order, this order may carry
information and be meaningful for the application.
An very simple example is:
<name>
<first>Eric</first>
<last>van der Vlist</last>
</name>
can indicate the fact that I prefer to be called with my first name
before my last name, while
<name>
<last>van der Vlist</last>
<first>Eric</first>
</name>
can indicate the contrary.
With attributes you would loose this information.
Entropy may carry information!
> 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.
You mean where better means possible to implement with WXS?
Eric
> Paul Prescod
--
Curious about Relax NG? My book in progress is waiting for your review!
http://books.xmlschemata.org/relaxng/
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------
|
