OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Same element, different type


I have what I suspect is a simple question about element consistency in 
a schema.  I have recently run across a few scenarios that require me to 
define something like the following:

   <xs:element name="params">
         <xs:element minOccurs="1" maxOccurs="1" name="param">
             <xs:restriction base="xs:string">
               <xs:enumeration value="a"/>
               <xs:enumeration value="b"/>
               <xs:enumeration value="c"/>
         <xs:element minOccurs="1" maxOccurs="1" name="param" 

The definition above isn't ambiguous (which would break the unique 
particle attribution rule), but it is not *consistent* vis-a-vis the 
types.  The Xerces parser reports a "cos-element-consistent" error, 
which I understand, but which I am hoping to circumvent while 
maintaining strict parsing rules.

Is there a way to define two unambiguous elements with the same name but 
are of different types?  I believe the answer here is "it can't be 
done", but thought I'd throw this at the wolves to see if I'm right. :)

(Incidentally, the above example is a snippet from a schema that is 
attempting a representation of an XML-RPC message set, where the first 
parameter is always a constrained list of possible values, while the 
second parameter is any string).


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS