Uploaded image for project: 'Daffodil'
  1. Daffodil
  2. DAFFODIL-2192

Incorrect warning: Neighboring QNames differ only by namespaces

VotersWatch issueWatchersLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Blocker
    • Resolution: Fixed
    • 2.5.0
    • 2.5.0
    • Back End, Front End
    • None

    Description

      There are some schemas where the following incorrect warning is displayed:

      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

      This original was noticed on the BMP schema, but it has been seen in other schemas. A minimal schema that reproduces the is:

      <?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>
      

      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:

      1. branch1/group[1]/dupElement
      2. 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.

      Attachments

        Activity

          This comment will be Viewable by All Users Viewable by All Users
          Cancel

          People

            mbeckerle Mike Beckerle
            slawrence Steve Lawrence
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Issue deployment