Merge attribute suggestions based on relax-ng schema

[andershol]

If I have a relax-ng schema like this, where a "Items"-root element, can have "Item"-sub-elements, all having a "Type"-attribute, that determines if it is a Foo-Item or and Bar-Item, and that in turn determines their sub-elements (having the contents of an element be determined by an attribute is a reason for using relax-ng as xsd 1.1 is not yet supported):

<grammar xmlns="http://relaxng.org/ns/structure/1.0">
  <start>
    <element name="Items">
      <element name="Item">
        <choice>
          <group>
            <attribute name="Type"><value>Foo</value></attribute>
            <attribute name="FooAttr"/>
          </group>
          <group>
            <attribute name="Type"><value>Bar</value></attribute>
            <attribute name="BarAttr"/>
          </group>
        </choice>
      </element>
    </element>
  </start>
</grammar>

I can have a document like this:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="test.rng"?>
<Items>
  <Item ></Item>
</Items>

I get a warning that Item is missing a Type-attrubte, which is good and correct.

But if I place the cursor after "<Item " (i.e. a space after "Item") and press Ctrl+Space to get suggestions, I get a list containing "BarAttr", "FooAttr", "Type", and "Type" (i.e. "Type" appears twice). Choosing the first "Type", attribute is inserted with the value "Foo" and it appears to be the only allowed value, while choosing the second "Type" inserts the attribute with "Bar" as the only allowed value. I would have liked only one "Type" attributes in the list with the choice of either "Foo" or "Bar" as the value.

Also, what is probably just another symptom of the same problem is, that if I remove the Item-element and put the cursor inside the empty Items-element, and write "<I" and enter (to accept the suggestion of "Item") <Item Type="Foo" Type="Bar"></Item> is inserted which is invalid xml. I would have linked to see just an single Type-attribute with the choice of "Foo" and "Bar" as the value.

[angelozerr]

I have tried to manage completion by using some jing classes used for validation but it seems there is a bug.

Any contribution are welcome!

[andershol]

I'll probably not get to look at this myself. But it sounds like you have a guess as to where one could start looking. Would you mind giving a pointer?

[angelozerr]

I'll probably not get to look at this myself. But it sounds like you have a guess as to where one could start looking. Would you mind giving a pointer?

OK let me see if it is easy to fix and if I can find time I will try to fix it.

When you open completion inside Item I wonder if we should just show Type attribute, right?

And when yiu open completion after Type="Foo" you should see just FooAttr, is that?

[andershol]

Thanks for taking the time to consider it.

When you open completion inside Item I wonder if we should just show Type attribute, right?

In this sample case (and in my actual case) that would be nice, but I think it would be hard to detect in the general case which attribute, if any, that the user thinks is the one that selects the type. I guess it e.g. might be the absence of an attribute that select a group or all the groups might have a Name attribute that doesn't select anything. And note in this case, the user might also select a group by adding either FooAttr or BarAttr. So I think you unfortunately need to just naively show all distinct.

And when you open completion after Type="Foo" you should see just FooAttr, is that?

Yes, I think it would be good if only valid attributes would be suggested. One could argue, that if you add Type="Foo" FooAttr="x" and then decide you rather want Type="Bar", that you have locked yourself in, but you are not prevented from entering the illegal value, you just don't get help and could just remove FooAttr first.