[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Can XML Schemas do this?


xml attributes alphabetical order
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


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.