[
https://issues.apache.org/jira/browse/DAFFODIL-2550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17413236#comment-17413236
]
Steve Lawrence commented on DAFFODIL-2550:
------------------------------------------
I've tracked down the underlying issue, though not quite sure of the right fix.
Say we have a schema like this:
{code:xml}
<xs:schema ...>
<xs:element name="root1">
<xs:complexType>
<xs:sequence>
<xs:element name="elem1" ... />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="root2">
<xs:complexType>
<xs:sequence>
<xs:element name="elem2" ... />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
{code}
So we have two global element declarations , and they have some children. It's
difficult to create a simplified schema to recreate the issue (I think it needs
nested shared group references), but this is enough to show the core issue,
which is that calculating enclosingElements is sometimes broken.
For elem1, its enclosingElements results in an element reference to root1,
which is reasonable.
But for elem2, its enclosingElements results in nothing, which is definiteyl
wrong. And because elem2 thinks it doesn't have any enclosing elements, it
throws off the minimizedScope logic which inspects the scopes of parent
elements to figure out required namespace bindings. Through complex sharing of
global group defs, this can result in unnecessary namespace bindings.
The reason elem2 doesn't have any enclosing elements is that in order to find
enclosing elements, we find the nearest enclosing term that is an element. Keep
in mind that GlobalElementDecl's are not Terms.
So for the elem1 element, we traverse until we get to the GlobalElementDecl of
root1, which isn't a Term, so we look at its enclosing component. Because root1
is a root, we have a Root which is both an ElementRef and a Term. So we have
found a term that is an Element, and can return it.
But for elem2, we traverse until we get to the GlobalElementDecl of root2, but
because root2 isn't a root we have no Root or ElementReference to it. So we
don't have a Term representing root2 and so we end up with an empty list.
I'm not sure what the best fix is. Should we create ElementReferences for all
global elements so that we do have a Term that we can use? Maybe
enclosingElements shouldn't look at Terms, but instead should at enclosing
components until it finds a Element? Or maybe we should just resolve this as
Won't Fix, and prioritize DAFFODIL-2282, which should hopefully fix all
namespace issues, including this one?
> xmlns="" not minimized away in two CLI tests.
> ---------------------------------------------
>
> Key: DAFFODIL-2550
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2550
> Project: Daffodil
> Issue Type: Bug
> Components: Middle "End"
> Affects Versions: 3.2.0
> Reporter: Mike Beckerle
> Assignee: Steve Lawrence
> Priority: Major
>
> Changes in [https://github.com/apache/daffodil/pull/600] clean up things a
> lot, but there is one mystery change in behavior.
> Two CLI tests now add an xmlns="" to an inner locally-declared element which
> has a unqualified name.
> This seems like incorrect namespace binding minimization, possibly.
> Rather than hold up the merge of PR 600 (which is a big change set, so needs
> to be merged real soon now) this ticket is to investigate this issue of the
> two CLI tests and the xmlns="" that seems unnecessary.
> Note that we've suspected there could be bugs in namespace binding
> minimization for a while now.
> The two CLI tests are:
> * test_CLI_Debugger_InfoHidden_1
> * test_CLI_Debugger_InfoHidden_2
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
