XSD 1.1: elements view works poorly with xs:alternative

Are you missing a feature? Request it's implementation here.
dnl
Posts: 6

XSD 1.1: elements view works poorly with xs:alternative

Mon Sep 03, 2018 5:00 pm

While content completion runs smoothly, element view feels broken in some context.

When there is an xs:alternative definition, the default behavior is:
if there is no other element declaration of the same name (anywhere) in the schema, elements view does not offer anything. The test alternative is not being evaluated for elements view.

On the other hand, if you do have some other element declaration of the same name (anywhere) in the schema, elements view suddenly tries to offer the elements that it identifies as belonging to all element declarations of same-named elements (= any element that is declared in the other declaration too). This can lead to somewhat obscure elements view:

* only elements are shown that are also declared in another element declaration of the same name (but with another content model)
* the user is irritated, because elements view shows less elements that it should (compare with content completion).
* only if there are no other element content models of the same name, it is somewhat clearer because simply nothing gets shown (it would be great when the alternative test condition would be evaluated, though).

Please find the schema attached. Only /root/child/child-meta-2 is offered in the elements view, although child-meta-invisible-in-elements-window should be shown as well. This is very irritating to the user.

XSD 1.1:

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema version="1.1" xmlns:xs="http://www.w3.org/2001/XMLSchema" >
 
  <xs:import namespace="http://www.w3.org/XML/1998/namespace"/>
  <xs:element name="meta-1">
    <xs:complexType>
      <xs:attribute name="name" use="required"/>
    </xs:complexType>
  </xs:element>
  <xs:element name="meta-2">
    <xs:complexType>
      <xs:attribute name="name" use="required"/>
    </xs:complexType>
  </xs:element>
  <xs:element name="root">
    <xs:alternative test="@type='1'">
      <xs:complexType>
        <xs:sequence>
          <xs:element name="child" type="meta-1.type"/>
        </xs:sequence>
        <xs:attribute name="type" type="xs:string"></xs:attribute>
      </xs:complexType>
    </xs:alternative>
    <xs:alternative>
      <xs:complexType>
        <xs:sequence>
          <xs:element name="child" type="meta-2.type"/>
        </xs:sequence>
        <xs:attribute name="type" type="xs:string"></xs:attribute>
      </xs:complexType>
    </xs:alternative>
  </xs:element>
  <xs:complexType name="meta-1.type">
    <xs:sequence>
      <xs:element name="child-meta-1"/>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="meta-2.type">
    <xs:all>
      <xs:element name="child-meta-2"/>
      <xs:element name="child-meta-invisible-in-element-window" type="xs:string"> </xs:element>
    </xs:all>
  </xs:complexType>
 
  <xs:element name="child">
    <xs:complexType>
      <xs:sequence>
        <!-- element declaration of child-meta-2 enables visibility in element window in xs:alternative -->
        <xs:element name="child-meta-2"/>
        <xs:element name="element-only-available-here"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
 
</xs:schema>



XML:

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="Oxygen-Bug.xsd" type="default-alternative">
<child>
  <child-meta-invisible-in-element-window></child-meta-invisible-in-element-window>
  <child-meta-2></child-meta-2>
</child>
</root>


Unfortunately it is imperative for this schema design to have different content models for elements with the same name in different contexts.
Thanks for any thoughts on this! Daniel
tavy
Posts: 153

Re: XSD 1.1: elements view works poorly with xs:alternative

Tue Sep 04, 2018 2:50 pm

Hello Daniel,

Thanks for your feedback.
Yes, it seems that in the Elements view does not present correctly the current elements from the context, if a type alternative is used. Normally the content completion and the Elements view should use the same information, but it seems that in this case it does not.
I added an issue on our issue tracker to correct this problem. We will update this thread when it will be implemented.

Best Regards,
Octavian
Octavian Nadolu
<oXygen/> XML Editor
http://www.oxygenxml.com

Return to “Feature Request”

Who is online

Users browsing this forum: No registered users and 1 guest