Last Comment Bug 303198 - Handle at attr evaluating to NaN for insert/delete
: Handle at attr evaluating to NaN for insert/delete
Status: RESOLVED WONTFIX
:
Product: Core
Classification: Components
Component: XForms (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: xforms
: Stephen Pride
Mentors:
http://www.mozilla.org/projects/xforms/
Depends on:
Blocks: 326372 326373
  Show dependency treegraph
 
Reported: 2005-08-03 00:26 PDT by Allan Beaufour
Modified: 2016-02-04 12:20 PST (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (1.11 KB, application/xhtml+xml)
2005-10-28 13:17 PDT, aaronr
no flags Details

Description Allan Beaufour 2005-08-03 00:26:47 PDT
As mentioned in bug 302499, we need to handle that the at attribute evaluates to
NaN for insert and delete. For insert NaN should insert at the end of the nodes
set, while it's not quite clear what to do for delete.

I've written the WG about the issue.

Code-wise we need to implement/expose a isNaN() function. The "cleanest" would
probably be to do a nsIDOMNSXPathResult, that implements:
boolean isNaN()
and let Transformiix handle it.
Comment 1 Allan Beaufour 2005-08-18 01:04:15 PDT
(In reply to comment #0)
> As mentioned in bug 302499, we need to handle that the at attribute evaluates to
> NaN for insert and delete. For insert NaN should insert at the end of the nodes
> set, while it's not quite clear what to do for delete.
> 
> I've written the WG about the issue.

The resolution is that NaN -> NOP for both insert and delete.
Comment 2 aaronr 2005-10-28 13:17:58 PDT
Created attachment 201184 [details]
testcase
Comment 3 Victor Engmark 2005-12-05 05:14:19 PST
(In reply to comment #1)
> The resolution is that NaN -> NOP for both insert and delete.

Sorry, but no.

http://www.w3.org/TR/xforms/slice9.html#action-insert, point 2b, states that "[i]f the result is NaN, the insert appends to the end of the node-set."

For delete, however, any @at which does not match a node index will result in NOP.
Comment 4 Allan Beaufour 2005-12-06 18:10:50 PST
(In reply to comment #3)
> (In reply to comment #1)
> > The resolution is that NaN -> NOP for both insert and delete.
> 
> Sorry, but no.

Sorry, but yes.

> http://www.w3.org/TR/xforms/slice9.html#action-insert, point 2b, states that
> "[i]f the result is NaN, the insert appends to the end of the node-set."
> 
> For delete, however, any @at which does not match a node index will result in
> NOP.

What I wrote is what was agreed upon by the XForms working group.
Comment 5 Victor Engmark 2005-12-07 02:06:50 PST
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #1)
> > > The resolution is that NaN -> NOP for both insert and delete.

> > http://www.w3.org/TR/xforms/slice9.html#action-insert, point 2b, states that
> > "[i]f the result is NaN, the insert appends to the end of the node-set."
> > 
> > For delete, however, any @at which does not match a node index will result in
> > NOP.
> 
> What I wrote is what was agreed upon by the XForms working group.

How can that be, when the standard clearly says the opposite? Is this part of XForms 1.1? Will you not implement according to XForms 1.0?
Comment 6 Allan Beaufour 2005-12-07 08:28:29 PST
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > (In reply to comment #1)
> > > > The resolution is that NaN -> NOP for both insert and delete.
> 
> > > http://www.w3.org/TR/xforms/slice9.html#action-insert, point 2b, states that
> > > "[i]f the result is NaN, the insert appends to the end of the node-set."
> > > 
> > > For delete, however, any @at which does not match a node index will result in
> > > NOP.
> > 
> > What I wrote is what was agreed upon by the XForms working group.
> 
> How can that be, when the standard clearly says the opposite? Is this part of
> XForms 1.1? Will you not implement according to XForms 1.0?

Oh, actually I assumed that it had made it to XForms 1.0 Second Edition, it apparently hasn't :( Hmmm, I'll have to ask the WG again (as I'm not part of it anymore).
Comment 7 Allan Beaufour 2006-04-03 08:03:29 PDT
Asked about it:
http://lists.w3.org/Archives/Member/w3c-forms/2006AprJun/0010.html
Comment 8 aaronr 2006-06-19 14:27:16 PDT
(In reply to comment #7)
> Asked about it:
> http://lists.w3.org/Archives/Member/w3c-forms/2006AprJun/0010.html
> 

Comeback from John Boyer at the June 2006 F2F: "I don't see any action items related to this for 1.0 errata, and it has a well-defined behavior 1.0 that is even preserved in the 1.1 draft, so I don't think we have to chase it anymore.  If NaN, then append."
Comment 9 Allan Beaufour 2006-08-08 05:49:50 PDT
(In reply to comment #8)
> (In reply to comment #7)
> > Asked about it:
> > http://lists.w3.org/Archives/Member/w3c-forms/2006AprJun/0010.html
> > 
> 
> Comeback from John Boyer at the June 2006 F2F: "I don't see any action items
> related to this for 1.0 errata, and it has a well-defined behavior 1.0 that is
> even preserved in the 1.1 draft, so I don't think we have to chase it anymore. 
> If NaN, then append."

That is true for insert. But about delete? That was what this started with in comment 0. It has now been ignored twice by the WG, and I believe it is still undefined.

I'm 100% confident that it was resolved, but aparently never written down. I do not have time to chase it down (or the energy to talk to various people in the WG.)
Comment 10 David Bolter [:davidb] 2016-02-04 12:20:55 PST
RIP xforms

Note You need to log in before you can comment on or make changes to this bug.