Yikes. I must be dumb. I'm not exactly sure what you mean.

Can you break it into small, bite-sized pieces for me?

Sure, I need my schema to say the following:

1. Elements named "things" can contain a node with any name.
2. Elements that are children of an element named "things" must follow a specific set of rules.

Ah...now I get it.

I don't...think...you can do that. It kinda flies in the face of what Schema/DTD is about (iron-fisted and pedantic specification control). However, I'm not a schema guru. There may be a loophole in there somewhere. <xsl:all></xsl:all> will get you "any of these," but you want to be able to actually rename elements during the creation of the XML file, which probably shouldn't be allowed in XML.

It's a neat idea. If you find that I'm wrong, please post your findings here.

I quite prefer the older example. A sensible XML has predictable element names, with predictable attributes. It's the content and the attribute values that should be different/unpredictable. An XML schema with unpredictable element names isn't a schema at all, it's just a pile of random XML, and doesn't deserve to be validated.
</lecture>

Since your elements aren't restricted to a set, don't define them at all. Your Schema will look something like this:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="things">
</xs:element>
</xs:schema>

The sad answer to the second part is... schema can't validate any unknown element, nor an unknown child of a known element.

Cheers
hww

Well, what I had in mind was something like MXML, where node names correspond to class names in a different language. For example,

[pre]<Car>
 <wheels>
 <Wheel />
 <Wheel />
 <Wheel />
 <Wheel />
 </wheels>
</Car>[/pre]

Here, it wouldn't make sense for anything other than a Wheel to be in the "wheels" node. However, what if my application contains a subclass of Wheel named FancyWheel? The following XML:

[pre]<Car>
 <wheels>
 <FancyWheel />
 <FancyWheel />
 <FancyWheel />
 <FancyWheel />
 </wheels>
</Car>
[/pre]

would be much more readable than something like this:

[pre]<Car>
 <wheels>
 <Wheel class="FancyWheel" />
 <Wheel class="FancyWheel" />
 <Wheel class="FancyWheel" />
 <Wheel class="FancyWheel" />
 </wheels>
</Car>[/pre]

Of course, it's impossible to know how many subclasses of Wheel the application might contain, or what they're called. Therefore, the schema for the element Wheel should be defined in terms of context, not node name.

After reading the responses, it seems that the XML Schema is simply incapable of defining an element by anything other than a node name, unfortunately. But I don't think that makes the above XML "insensible," does it? I think it's more a limitation of XML Schema; the XML is certainly capable of being validated (i.e. not "just a pile of random XML") by a system, for example, that allows restrictions to be placed on nodesets formed by more complicated XPath Queries than //nodename (which is, it seems to me, what

<xs:element name="Wheel" type="wheelType" />

is doing).

<Car>  
 <wheels>  
 <Wheel class="FancyWheel" />  
 <Wheel class="FancyWheel" />  
 <Wheel class="FancyWheel" />  
 <Wheel class="FancyWheel" />  
 </wheels>  
</Car>

Looks quite readable to me. I think this is the best method to use.

Most dynamic structures use something like this. It also allows extensible data structures. I often use XML like this:

<Car>  
 <wheels>  
 <Wheel class="FancyWheel"> 
 <dataMember key="bling">Spinning Outer Rim</dataMember> 
 </Wheel> 
 </wheels>  
</Car>

To make it even more generic, you could do something like this:

<Car>  
 <wheels>  
  <Factory class="FancyWheel"> 
   <dataMember name="bling" type="string">Spinning Outer Rim</dataMember> 
  </Factory> 
 </wheels>  
</Car>

Where "Factory" is a FACTORY pattern [msdn2.microsoft.com] object generator.

I agree, it is a deficiency of Schema that it can't validate more complex relationships with undefined element names.

hey cmarshall, maybe we should write our own schema language that doesn't suck

hey cmarshall, maybe we should write our own schema language that doesn't suck

Ugh. That sounds like work. :(