While developing a schema for the usecase described below, I'm encountering xml schema limitations. I would appreciate input on how to best model the xml and the best method to validate it (if possible with schema or better done with relax NG). Questions are appended below.
Here is a xml snippet which is used to declare content using templates, lets say (namespaces removed):
<input xsi:type="input_text" name="title">Welcome</input>
<input xsi:type="input_longtext" name="body">Hello, welcome to the main page</input>
<input xsi:type="input_link name="picurl">http://.......</input>
<input xsi:type="input_longtext" name="body">This is a wonderful picture</input>
<input xsi:type="input_link" name="picurl">http://.......</input>
<input xsi:type="input_longtext" name="body">This is <b>another</b> picture</input>
<input xsi:type="input_radio" name="position">left</input> <!-- optional, only values allowed left, right, center -->
Now, I'd like to be able to validate the sections, i.e. to get an error in the 2nd section, where the radio input is missing. XML Schema allows me to use type derivation nicely to derive the types 'intro' and 'withpic' from the same type 'section'. Unfortunately I cannot declare that the section of type 'withpic' should contain exactly 3 input elements, with types 'link', 'longtext' and 'radio', respectively. It seems to be associated to the fact that I cannot declare multiple elements with the same name but a different type (similar to http://lists.xml.org/archives/xml-dev/200201/msg01946.html):
<!-- <xs:element name="input" type="input"/> is allowed -->
<xs:element name="input" type="input_link"/>
<xs:element name="input" type="input_longtext"/>
<xs:element name="input" type="input_radio"/> <!-- does not work, multiple elements with same name not allowed -->
Now, I am looking for alternatives to validate the xml:
1) Is there any way to validate the above xml using Schema, but using derived types (and not only the general type, as in the comment above?)
2) What does relax NG offer in the described case? Would it support the described xml (replacing 'xsi:type' with a regular type attribute)? Would I loose any advantage of Schema like type derivation?
3) I know that I could avoid the issue if I use different element names for the sections and inputs (section_intro, input_link, ...). As the xml is used to generate API calls, though it would be good to avoid that as iterating over all 'input' elements wouldn't be possible (or dirty, iterating over all elements starting with input_ ...).
Thx for any hints or suggestions!