Yet another reason to avoid XSD like the plague. XML development shouldn't require one to buy a thousand-dollar IDE to understand what you're doing.

"Avoid like the plague" is a bit much. I consider it a reason to discourage the use of XSD outside of the domains it was optimized for: XMLization of transaction-oriented data and/or data from relational databases. (This is a bit of a simplification, but only a bit.) I don't have much problem with

<xs:element name="quantity" type="xs:integer"/>

but when dealing with data more oriented toward publishable content, then, as Norm shows, XSD gets messier and messier.

I've been thinking for a while that a distinction between publishable content and transaction-oriented data is more useful than the traditional distinction in the XML world between "documents" and "data", since all well-formed XML is both.

I think it's definitely a question of choosing the right tool for the job, and that means known the strengths and limitations of your tools.

But your example strikes me as a little off-topic, Bob. It was never my intent to suggest it was bad to declare types. The tricky bit occurs when someone says:

<quantity xsi:type="byte">34</quantity>

in a document. And even then, it's probably harmless because byte is a restriction of integer. In fact, for simple types it may not matter very much (though I haven't thought through all the possibilities).

As a newbie I developed a lot of applications using xml as a command language. I am particulary fond of things like:

<cmd type="delete" item-id="2342"/> <cmd type="insert"/> <cmd type="edit" item-id="2342"/>

Is this a difficult structure to document using xsd?

I can not figure it out, but this article seemed to be close to the topic of elements with the same name but with a differrentating "type" attribute....

It's difficult as in impossible to have an XSD with different content models for the different 'cmd' elements based on the value of the type attribute.

DTDs can't do it either, but RELAX NG can.