Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


[xml-dev] Derivation of complex types, depending on attribute -

From: Nils Kaiser <NilsKaiser@---.--->
To: xml-dev@-----.---.---
Date: 11/25/2008 4:39:00 PM
Hi all,

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):

<page>
  <section xsi:type="section_intro">
     <input xsi:type="input_text" name="title">Welcome</input>
     <input xsi:type="input_longtext" name="body">Hello, welcome to the 
main page</input>
  </section>
  <section xsi:type="section_withpic">
     <input xsi:type="input_link name="picurl">http://.......</input>
     <input xsi:type="input_longtext" name="body">This is a wonderful 
picture</input>
  </section>
  <section xsi:type="section_withpic">
     <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 -->
  </section>
</page>

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:complexType name="section_withpic">
    <xs:complexContent>
        <xs:extension base="section">
            <xs:sequence>
<!--           <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 -->
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>

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!

Nils


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent