[jira] [Created] (DAFFODIL-2192) Incorrect warning: Neighboring QNames differ only by namespaces

["Steve Lawrence (Jira)" <ji...@apache.org>]

Steve Lawrence created DAFFODIL-2192:
----------------------------------------

             Summary: Incorrect warning: Neighboring QNames differ only by namespaces
                 Key: DAFFODIL-2192
                 URL: https://issues.apache.org/jira/browse/DAFFODIL-2192
             Project: Daffodil
          Issue Type: Bug
          Components: Back End, Front End
    Affects Versions: 2.5.0
            Reporter: Steve Lawrence
             Fix For: 2.5.0


There are some schemas where the following incorrect warning is displayed:
{quote}
Schema Definition Warning: Neighboring QNames differ only by namespaces. Infoset representations that do not support namespacess cannot differentiate between these elements and may fail to unparse. QNames are: {}DupElement, {}DupElement
{quote}
This original was noticed on the BMP schema, but it has been seen in other schemas. A minimal schema that reproduces the is:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:dfdl="http://www.ogf.org/dfdl/dfdl-1.0/" elementFormDefault="qualified">

  <xs:include schemaLocation="org/apache/daffodil/xsd/DFDLGeneralFormat.dfdl.xsd"/>

  <xs:annotation>
    <xs:appinfo source="http://www.ogf.org/dfdl/">
      <dfdl:format ref="GeneralFormat" representation="binary"/>
    </xs:appinfo>
  </xs:annotation>

  <xs:element name="root">
    <xs:complexType>
      <xs:sequence>
        <xs:choice>
          <xs:element ref="branch1"/>
          <xs:element ref="branch2"/>
          <xs:element ref="branch3"/>
        </xs:choice>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name="branch1">
    <xs:complexType>
      <xs:sequence>
        <xs:group ref="group1"/>
        <xs:element name="otherElement" type="xs:int"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name="branch2">
    <xs:complexType>
      <xs:sequence>
        <xs:group ref="group1"/>
        <xs:group ref="group2"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name="branch3">
    <xs:complexType>
      <xs:sequence>
        <xs:group ref="group1"/>
        <xs:group ref="group2"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:group name="group1">
    <xs:sequence>
      <xs:element name="elementOfInterest" type="xs:int"/>
    </xs:sequence>
  </xs:group>

  <xs:group name="group2">
    <xs:sequence>
      <xs:element name="dupElement" type="xs:int"/>
    </xs:sequence>
  </xs:group>

</xs:schema>
{code}

From what I can tell, the issue has to do when determining the elements that could possibly appear after {{elementOfInterest}}. It's not clear to me why {{branch1}} needs to exist to trigger this, but is is. However, the generic {{elementOfInterest}} could potentially be followed by two two elements:
# {{branch1/group[1]/dupElement}}
# {{branch2/group[1]/dupElement}}.

It is true that both these elements have the same namespace and have the same name, so the arning sortof makes sense. But there is actually no way for any confusion to occur when unparsing, since {{dupElement}} always appears after {{elementOfInterest}} in separate branches ({{branch1}} vs {{branch2}}). So this error is just confusing.

Furthermore, there may actually be a real problem here when unparsing. In this case, it looks like the two {{dupElement}}s have completely different instances with different ERDS. This means that during unparsing, when trying to determine which ERD is next after unparsing {{elementOfInterest}}, it will be ambiguous which ERD to unparse, and this could potentially cause unparse errors, or even the inability to unparse in certain branches.

This may have implications with how DAFFODIL-1444 is implemented, since the same element could have different {{potentialNextElements}} based on which branch the element is referenced. And potentialNextElements is used during unparsing, so it almost seems this needs to be branch aware...

This bug looks to be added in commit ae3fba0a08cb: Incremental progress on schema compilation space/speed issue.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)