Problem validating an XSD file: The content type of a derived type and that of its base must both be mixed or both be element-only
I have following XML schema:
<?xml version="1.0" encoding="UTF-8"?>
<schema
xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"
targetNamespace="urn:ietf:params:xml:ns:netconf:base:1.0"
...
<complexType name="dataInlineType">
<xs:complexContent>
<xs:extension base="xs:anyType"/>
</xs:complexContent>
</complexType>
<complexType name="get-config_output_type__" >
<complexContent>
<extension base="netconf:dataInlineType">
<sequence>
<element name="data">
<complexType>
<sequence>
<element name="__.get-config.output.data.A__"
minOccurs="0" maxOccurs="unbounded"
/>
</sequence>
</complexType>
</element>
<element name="__.get-config.A__" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
And I getting the folling error:
cos-ct-extends.1.4.3.2.2.1.a: The content type of a derived type and that of its base must both be mixed or both be element-only. Type 'get-config_outpu开发者_运维技巧t_type__' is element only, but its base type is not.
If I put both elements mixed="true"
I get another error:
cos-nonambig: WC[##any] and "urn:ietf:params:xml:ns:netconf:base:1.0":data (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles.
I using the Eclipse to validate my schema, so what can I do?
This best describes your issue after your fix, but I think what you are doing is still a conflict in Schema 1.1: http://en.wikipedia.org/wiki/Unique_Particle_Attribution
First of all your definitions are not being prefixed with the xs: alias which might be causing confusion and redirecting validation rules to the netconf? So try adding that prefix to all your schema elements.
Even though this seems to validate cleanly in MSVS, I think you should likely get this error in most validaters with almost all definitions derived from the type "anyType" that adds additional elements. This is because your base type already includes every other combination possible and I don't think the wildcard matching will be weak in the derived class like what would normally happen. Instead you can define one root type that has an element of anyType in it and derive from that. If Eclipse is validating with schema 1.1 rules that should work fine due to the weak wildcard matching properties. If that fails define a root type that is simply mixed and just make one of those types is a type with the xs:any element and mixed="true". This leaves you the option with creating ant subtype that can limit the elements that are valid as well. In the rest of the schema that uses "dataInlineType" you can just use a substitution for it by declaring a substitutionGroup. I am guessing that might be a better solution in general for the intent your snippet of schema portrays.
精彩评论