331897 - support for validating xsd:double schema type

Status: RESOLVED FIXED

(Core Graveyard :: XForms, defect)

Description

[aaronr]

Be nice if we could validate xsd:double schema type.

This actually fails testcase 8.1.7.f in the testsuite.

Comment 1

[aaronr]

Attachment: testcase

Comment 2

[Steve Speicher]

Attachment: patch

patch + updated test cases.  Verified against attached test case and W3C test suite.

JST review complains about a few things that I think it's just confused about the & operand and String arg types.

Comment 3

[Doron Rosenberg (IBM)]

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

Patch looks good, but the spec says for the lexical space:

http://www.w3.org/TR/xmlschema-2/#double

"The special values positive and negative infinity and not-a-number have lexical representations INF, -INF and NaN, respectively. Lexical representations for zero may take a positive or negative sign."

Do we need to worry about those?

Comment 4

[Steve Speicher]

Attachment: patch2 - with support for INF/-INF/NaN

I hesitate to say this is good enough since the one test case fails.  Though it is unclear if -INF < INF, I would think so.

Let me know if there might be a better way to handle this.

Comment 5

[Doron Rosenberg (IBM)]

Why is it failing?  I am not sure we need to even consider the 3 text values, do other processors support them?

Comment 6

[Steve Speicher]

(In reply to comment #5)
> Why is it failing?  I am not sure we need to even consider the 3 text values,
> do other processors support them?
> 

It is failing since strtod doesn't return appropriate values for INF and -INF (actually tested float and ToFloat() has the same problems).  strtod usually returns 0.0 for both INF and -INF. ToFloat() usually returns garbage for INF and -INF.

X-Smiles uses the Xerces validator, which handles these properly ie -INF < INF, -INF < everything, everything < INF, ... what you'd expect.

So I recommend considering support for double done and followup with with a separate INF/-INF bug for str functions (or should we handle it indirectly in our processing of infinity).  Note, after saying all of this...I can't possibly think that anyone is using infinity but you never know.

Comment 7

[Steve Speicher]

Attachment: patch for schema test suite, shows INF edge cases

Don't know if you want these committed but thought it might be helpful.  Updated to test with INF/-INF

Comment 8

[Doron Rosenberg (IBM)]

Comment on attachment 221739 [details] [diff] [review]
patch2 - with support for INF/-INF/NaN

Yeah, lets go with this and file a bug about INF/-INF.

Comment 9

[Steve Speicher]

Comment on attachment 221811 [details] [diff] [review]
patch for schema test suite, shows INF edge cases

obsoleting, will move to bug regarding INF/-INF

Comment 10

[Allan Beaufour]

Comment on attachment 221739 [details] [diff] [review]
patch2 - with support for INF/-INF/NaN

Isn't this Doron-land? That said, the code looks sane, except for:

>-  return (pEnd != aString);
>+  // If end pointer hasn't moved, then there was an error

Either the code or the comment is wrong then.

>+  if (pEnd == aString) {
>+    NS_NAMED_LITERAL_CSTRING(temp, aString);
>+
>+    // doubles may be INF, -INF or NaN
>+    if (!temp.Equals(NS_LITERAL_CSTRING("INF")) &&
>+        !temp.Equals(NS_LITERAL_CSTRING("-INF")) &&
>+        !temp.Equals(NS_LITERAL_CSTRING("NaN"))) {
>+      isValid = PR_FALSE;
>+    }
>+  }
>+  return isValid;

With that fixed, r=me

Comment 11

[Steve Speicher]

Attachment: patch 3, with comment fixed

Doron allowed me to enter Doron-land.

Fixed comment, ready for checkin.

Comment 12

[Allan Beaufour]

(In reply to comment #11)
> Created an attachment (id=222030) [edit]
> patch 3, with comment fixed
> 
> Doron allowed me to enter Doron-land.

:) I meant: r=doronr, and be done with it?

Comment 13

[aaronr]

checked into trunk for sspeiche

Comment 14

[Doron Rosenberg (IBM)]

Doron-land is a happy place with clowns and free baloons.