268285 - Support includenamespaceprefixes attribute on xforms <submission> element.

Status: RESOLVED FIXED

(Core Graveyard :: XForms, enhancement)

Description

[Darin Fisher]

Support includenamespaceprefixes attribute on xforms <submission> element.

Comment 1

[Doron Rosenberg (IBM)]

taking

Comment 2

[Doron Rosenberg (IBM)]

The way to do this would probably be:

during the serialization process, where we walk the instance document and clone
nodes, we should create a hash table (assuming the attribute is set) and add all
used namespaces to it.

Probably a good intro bug.

Comment 3

[aaronr]

Shouldn't be too tough.  See me or Doron if you have any questions about the
namespace serialization stuff.

Comment 4

[aaronr]

please also determine what our behavior should be if we have namespace prefixes
in the instance document that are NOT mentioned as a value in the
includenamespaceprefixes attribute.

Comment 5

[aaronr]

Also, what does "in addition to those visibly utilized" mean?  As mentioned
under includenamespaceprefixes at:
http://www.w3.org/TR/xforms/index-all.html#structure-model-submission

Comment 6

[jhp (no longer active)]

Attachment: patch

The term "visibly utilized" is defined here:
http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/#sec-Terminology.  From
discussions with Doron, it seems that the |nsIDOMSerializer| automatically adds
the namespace declaration if it finds the namespace prefix used, taking care of
that requirement in the spec.

In this patch, I just created a hash set as suggested by Doron to hold the
namespace prefixes, then check for them in |AddNameSpaces()|.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 187543 [details] [diff] [review]
patch


> 
>+nsStringHashSet*
>+nsXFormsSubmissionElement::GetIncludeNSPrefixesAttr()
>+{
>+  nsStringHashSet* prefixHash = new nsStringHashSet();

Handle OOM.

>+  prefixHash->Init(5);
>+
>+  nsAutoString prefixes;
>+  mElement->GetAttribute(kIncludeNamespacePrefixes, prefixes);
>+
>+  // Cycle through space-delimited list and populate hash set
>+  if (!prefixes.IsEmpty()) {
>+    PRInt32 start = 0, end;
>+
>+    do {
>+      end = prefixes.FindChar(' ', start);

Shouldn't we support also other whitespace characters?

Comment 8

[jhp (no longer active)]

Attachment: patch v1.1

This patch adds some error handling, and properly handles multiple consecutive
spaces.

+ Shouldn't we support also other whitespace characters?
Doesn't look like we need to.  I added tabs, newlines, and carriage returns to
my test case, but each time |GetAttribute()| returned a string that only
contained spaces for the whitespace.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #8)
> Doesn't look like we need to.  I added tabs, newlines, and carriage returns to
> my test case, but each time |GetAttribute()| returned a string that only
> contained spaces for the whitespace.

Are you really sure about this. What happens if a script does something like
submissionElement.setAttribute('includenamespaceprefixes', 'foo \t\t\t\n bar');

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 187711 [details] [diff] [review]
patch v1.1

Though, adding tabs and
newlines using scripts doesn't sound too likely and I'm not sure if we really
have to handle that case.
r=me

Comment 11

[jhp (no longer active)]

> Are you really sure about this. What happens if a script does something like
> submissionElement.setAttribute('includenamespaceprefixes', 'foo \t\t\t\n bar');

Yes, you are correct.  With a script like that, I see those other whitespace
chars in the string returned from |GetAttribute()|.  So, just to be safe, I'll
change that line to |FindCharInSet(" \t\r\n", start)| when checking in.

Comment 12

[jhp (no longer active)]

Checked in.