residual issues with pyang -f xsd ietf-netconf-state

[GoogleCodeExporter]

What steps will reproduce the problem?
1. take output from pyang -f xsd ietf-netconf-state.yang
2.run through xjc to create JAXB code bindings
3. parse issues appear

What is the expected output? What do you see instead?
expected output is the set of JAXB code binding classes

what is seen:
./run_xjc_netconf_monitoring.sh 
parsing a schema...
[ERROR] src-resolve: Cannot resolve the name 'identityref' to a(n) 'type
definition' component.
  line 334 of
file:/home/ellison/workspace-netconf/netconf/yang/netconf-monitoring-4.xsd

[ERROR] src-resolve: Cannot resolve the name 'identityref' to a(n) 'type
definition' component.
  line 401 of
file:/home/ellison/workspace-netconf/netconf/yang/netconf-monitoring-4.xsd

[ERROR] src-resolve: Cannot resolve the name 'identityref' to a(n) 'type
definition' component.
  line 559 of
file:/home/ellison/workspace-netconf/netconf/yang/netconf-monitoring-4.xsd

[ERROR] cos-nonambig: WC[##other:"urn:ietf:params:xml:ns:netconf:state"]
and WC[##other:"urn:ietf:params:xml:ns:netconf:state"] (or elements from
their substitution group) violate "Unique Particle Attribution". During
validation against this schema, ambiguity would be created for those two
particles.
  line 167 of
file:/home/ellison/workspace-netconf/netconf/yang/netconf-monitoring-4.xsd

[ERROR] cos-nonambig: WC[##other:"urn:ietf:params:xml:ns:netconf:state"]
and WC[##other:"urn:ietf:params:xml:ns:netconf:state"] (or elements from
their substitution group) violate "Unique Particle Attribution". During
validation against this schema, ambiguity would be created for those two
particles.
  line 207 of
file:/home/ellison/workspace-netconf/netconf/yang/netconf-monitoring-4.xsd

Failed to parse a schema.

What version of the product are you using? On what operating system?

latest from svn, fedora 11.

Please provide any additional information below.

For the 'identityref' name, I am wondering if xs:IDREF would be the correct
output.

for the non-ambiguous ## other issues, I am wondering if pyang is emitting
too many xs:any elements as commenting out some of these removes the parse
error.

Original issue reported on code.google.com by ellison....@gmail.com on 6 Oct 2009 at 4:59

[GoogleCodeExporter]

identityref is now mapped to QName.  This makes the XSD validate correct 
instance
documents.

Re. the cos-nonambig problem, libxml2 does not complain, but xjc complains even 
on
this simple construct which looks correct to me.

              <xs:choice>
                <xs:sequence>
                  <xs:element name="running" minOccurs="0"/>
                  <xs:any minOccurs="0" maxOccurs="unbounded"
                          namespace="##other" processContents="lax"/>
                </xs:sequence>
                <xs:sequence>
                  <xs:element name="candidate" minOccurs="0"/>
                  <xs:any minOccurs="0" maxOccurs="unbounded"
                          namespace="##other" processContents="lax"/>
                </xs:sequence>
              </xs:choice>

Original comment by mbj4...@gmail.com on 6 Oct 2009 at 9:36

• Changed state: Fixed

[GoogleCodeExporter]

While I am not an expert, I think the following is preferred:

              <xs:sequence>
                <xs:choice>
                  <xs:element name="running" minOccurs="0"/>
                  <xs:element name="candidate" minOccurs="0"/>
                </xs:choice>
                <xs:any minOccurs="0" maxOccurs="unbounded"
                          namespace="##other" processContents="lax"/>
               </xs:sequence>

I am basing this observation on the XSD produced by the OASIS WSDM working group
where the xs:any appeared at most once within an xs:ComplexType  for example:

        <xs:complexType name="MessageContentType">
                <xs:sequence>
                        <xs:element name="Size" 
                                type="mows:MessageContentSizeType" minOccurs="0"/>
                        <xs:choice>
                                <xs:element name="NotIncluded" 
                                        type="mows:MessageContentNotIncludedFlag"/>
                                <xs:element name="Text" type="xs:string"/>
                                <xs:element name="Binary" type="xs:base64Binary"/>
                                <xs:element name="Xml" 
                                        type="mows:AnyXmlContentsType"/>
                        </xs:choice>
                        <xs:any namespace="##other" processContents="lax" 
                                minOccurs="0" maxOccurs="unbounded"/>
                </xs:sequence>
                <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>

I think libxml2 will like the suggested alternative as well.

BTW, the output from pyang -f xsd ietf-netconf is not even close to what is in
Appendix B of RFC4741bis-01.

Original comment by ellison....@gmail.com on 7 Oct 2009 at 3:24