The default bug view has changed. See this FAQ.

Handle at attr evaluating to NaN for insert/delete

RESOLVED WONTFIX

Status

Core Graveyard
XForms
RESOLVED WONTFIX
12 years ago
9 months ago

People

(Reporter: Allan Beaufour, Unassigned)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

1.11 KB, application/xhtml+xml
Details
(Reporter)

Description

12 years ago
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.
(Reporter)

Comment 1

12 years ago
(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

12 years ago
Created attachment 201184 [details]
testcase

Comment 3

12 years ago
(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.
(Reporter)

Comment 4

12 years ago
(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

12 years ago
(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?
(Reporter)

Comment 6

12 years ago
(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).

Updated

11 years ago
Blocks: 326372

Updated

11 years ago
Blocks: 326373
(Reporter)

Comment 7

11 years ago
Asked about it:
http://lists.w3.org/Archives/Member/w3c-forms/2006AprJun/0010.html
(Reporter)

Updated

11 years ago
Assignee: aaronr → xforms

Comment 8

11 years ago
(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."
(Reporter)

Comment 9

11 years ago
(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.)
RIP xforms
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.