293951 - Shouldn't be altering default namespace during submission

Status: RESOLVED FIXED

(Core Graveyard :: XForms, defect)

Description

[aaronr]

if we load an external instance and it has no default namespace, then we are
loading it in under the empty namespace xmlns="".  However, should we submit
this instance, the submission document seems to be inheriting the default
namespace from the containing document, i.e. XHTML namespace.  So you can see if
we load such a document, then save it and then load the saved version, we'll
have problems with our bindings since we expect the instance to be in the no
namespace and it comes in under the xhtml namespace.

Assigning to Doron since he did the original namespaces on submission work.

Comment 1

[aaronr]

Attachment: external instance data

the external instance data to be loaded, saved from local file

Comment 2

[aaronr]

Attachment: form for testcase

save both this form and the external instance data locally.  Load locally. 
Click on save trigger then load trigger.  You'll notice that the inputs and
labels no longer show up when the form is loaded after the save.

Comment 3

[Doron Rosenberg (IBM)]

Attachment: patch v1

Allan, I ask you to review because I wonder if you can find out how the novell
IE control does this.

With this patch, we do:

1) If the instance data was local (inline), we grab the namespaces on the
xforms document's root node

2) copy over namespaces on the model element

3) copy any namespaces found on the xforms:instance element

4) Add namespaces on the instance data's root node.

This seems to be what novell does from my limited testing as well.

Comment 4

[Leigh L. Klotz, Jr.]

A clarification, if it is needed:
If the host XHTML file contains
  <instance id="main" src="foo.xml" />
and foo.xml is
  <?xml version="1.0">
  <data><a/></data>
then the instance "main" must be in the empty namespace, regardless of any
namespace declarations in effect in the host document containing the <instance
src="foo.xml" /> element.  The serialized instance will contain additional
namespace nodes, but none of them should be redefining the default namespace.

Comment 5

[Doron Rosenberg (IBM)]

Right, this patch does jus(In reply to comment #4)
> A clarification, if it is needed:
> If the host XHTML file contains
>   <instance id="main" src="foo.xml" />
> and foo.xml is
>   <?xml version="1.0">
>   <data><a/></data>
> then the instance "main" must be in the empty namespace, regardless of any
> namespace declarations in effect in the host document containing the <instance
> src="foo.xml" /> element.  The serialized instance will contain additional
> namespace nodes, but none of them should be redefining the default namespace.
> 

So what about:
    <xf:model xmlns="http://www.w3.org/1999/xhtml">
      <xf:instance src="defaultns.xml" />

and the xml file were:
  <?xml version="1.0">
    <data><a/></data>

Would the submitted document have the null namespace or not?

Comment 6

[Leigh L. Klotz, Jr.]

> So what about:
>     <xf:model xmlns="http://www.w3.org/1999/xhtml">
>       <xf:instance src="defaultns.xml" />
> 
> and the xml file were:
>   <?xml version="1.0">
>     <data><a/></data>
> 
> Would the submitted document have the null namespace or not?

It would have the null namespace, because that is what is declared in the
defaultns.xml file.  The external instance is read into its own InfoSet.

The inline instance case inherits from the containing XHTML document because it
is lexically part of it.

For a similar situation in XSLT, consider

  <xsl:value-of select="document('defaultns.xml')/data/a"
xmlns="http://www.w3.org/1999/xhtml" />

The data and a elements of the external defaultns.xml file will be in the empty
namespace, because the InfoSet created by the document() function is read from
the file defaultns.xml.  

Yet if we were to do the following
  <xsl:template xmlns="http://www.w3.org/1999/xhtml">
    <data>
      </a>
     </data>
   </xsl:template>
the data and a elements will be in the XHTML namespace, because those elements
are lexically part of the containing XHTML docum,ent

Comment 7

[Doron Rosenberg (IBM)]

So if the instance is remote (different file), we should never append any
namespace declarations from the including XForms document?  That would make sense.

Comment 8

[Leigh L. Klotz, Jr.]

(In reply to comment #7)
> So if the instance is remote (different file), we should never append any
> namespace declarations from the including XForms document?  That would make sense.

There are cases in which namespace declarations can be introduced into
externally loaded instances:
1. If new namespaces are introduced into the instance through the use of xf:copy
from another instance, then those new namespaces will need to be declared somehow. 
2. Also xf:duplicate from XForms 1.1 (which I think ought to be included in this
product regardless of the version number) can introduce new namespace nodes as well.

In the inline case, the main reason for serialization of namespace nodes that
are not obviously used (i.e., are not used in element names or attribute names)
is that there are cases where qualified names are used as values of content or
of attribute values, and it's not possible, in general, to tell when those
namespace prefixes are being used, so in-scope declarations are serialized.  

I'd also suggest asking the XForms WG, at this point.

Comment 9

[Doron Rosenberg (IBM)]

Attachment: v2 - only copy namespaces from the main document if the instance is inline.

Comment 10

[aaronr]

Comment on attachment 185582 [details] [diff] [review]
v2 - only copy namespaces from the main document if the instance is inline.


>@@ -755,22 +755,37 @@
>   nsCOMPtr<nsIDOMElement> newDocElm;
>   newDoc->GetDocumentElement(getter_AddRefs(newDocElm));
> 
>-  // add namespaces from the main document to the submission document
>-  rv = AddNameSpaces(newDocElm, node);
>-  NS_ENSURE_SUCCESS(rv, rv);
>-
>-  // handle namespaces on the model
>+  nsCOMPtr<nsIDOMNode> instanceNode;
>   nsCOMPtr<nsIModelElementPrivate> model = GetModel();
>-  node = do_QueryInterface(model);
>-  NS_ENSURE_STATE(node);
>-  rv = AddNameSpaces(newDocElm, node);
>-  NS_ENSURE_SUCCESS(rv, rv);
>+  rv = nsXFormsUtils::GetInstanceNodeForData(data, model, getter_AddRefs(instanceNode));
> 
>-  // handle namespaces on the xforms:instance
>-  rv = nsXFormsUtils::GetInstanceNodeForData(data, model, getter_AddRefs(node));
>-  NS_ENSURE_SUCCESS(rv, rv);
>-  rv = AddNameSpaces(newDocElm, node);
>-  NS_ENSURE_SUCCESS(rv, rv);
>+  // add namespaces from the main document to the submission document, but only
>+  // if the instance data is local, not remote.
>+  PRBool hasSrc = PR_FALSE;
>+  nsCOMPtr<nsIDOMElement> instanceElement(do_QueryInterface(instanceNode));
>+  instanceElement->HasAttribute(NS_LITERAL_STRING("src"), &hasSrc);

You never check the return from GetInstanceNodeForData.  This could crash if
instanceElement is bad.


>+
>+  if (!hasSrc) {
>+    rv = AddNameSpaces(newDocElm, node);
>+    NS_ENSURE_SUCCESS(rv, rv);
>+
>+    // handle namespaces on the model
>+    node = do_QueryInterface(model);
>+    NS_ENSURE_STATE(node);
>+    rv = AddNameSpaces(newDocElm, node);
>+    NS_ENSURE_SUCCESS(rv, rv);
>+
>+    // handle namespaces on the xforms:instance
>+    rv = nsXFormsUtils::GetInstanceNodeForData(data, model, getter_AddRefs(node));
>+    NS_ENSURE_SUCCESS(rv, rv);
>+    rv = AddNameSpaces(newDocElm, node);
>+    NS_ENSURE_SUCCESS(rv, rv);
>+
>+    // handle namespaces on the root element of the instance document
>+    doc->GetDocumentElement(getter_AddRefs(docElm));
>+    rv = AddNameSpaces(newDocElm, docElm);
>+    NS_ENSURE_SUCCESS(rv, rv);
>+  }

actually don't you have to worry about serializing the namespaces from any
ancestor node (in the instance document) of the nodeset that is getting
submitted?  Not just the root, model, instance and instance root?

Comment 11

[Doron Rosenberg (IBM)]

Attachment: with aaron's comments

The serializer will add any namespaces we need that are missing.

It is still unclear if we should add all xmlns:foo=""'s from instance document
nodes that are not submitted, and can be added later (lets get 90% of it
correct first :)

Comment 12

[Doron Rosenberg (IBM)]

checked in.