W3C home > Mailing lists > Public > public-webapi@w3.org > March 2008

Re: [Element Traversal LC] access to element by index

From: Doug Schepers <schepers@w3.org>
Date: Fri, 28 Mar 2008 17:23:20 -0400
Message-ID: <47ED61C8.6060403@w3.org>
To: "Web APIs WG (public)" <public-webapi@w3.org>

Hi, Daniel-

Daniel Glazman wrote (on 3/28/08 4:24 PM):
> Doug Schepers wrote:
>> The question is, can we revisit it in light of existing 
>> implementations in JSR-280 and in deployed code in mobile devices?  At 
>> the very least, we would have to leave 'childElementCount', and add an 
>> additional nodeList (be it static or live).  At that point, yes, it 
>> does seem like it might be getting a little heavy, and may also lead 
>> to non-interoperable content.
>> I will liaison with JSR and with the SVG WG to see how they feel about 
>> this decision.  I can see both sides, so I'll abide by the will of the 
>> WebAPI WG and the dependent groups.
> Let me summarize that : vendors implemented something that is not even
> a CR yet, so it's an-risk document, and you should take that as an
> argument against changes ???
> My answer is clearly NO. Drafts are well DRAFTS. Their introduction
> explicitely states it's not recommended to assume the specification
> is firm and will remain as is.

I agree that any implementation takes on risks when it does not respect 
the instability of a draft document.  In fact, I just said so. [1]

But let's be realistic, as well.  Implementation schedules and market 
pressures also play into the big picture; the standards process, for all 
its benefits, is known to be slow.  So we're faced with a situation in 
which a core set of functionality and design goals were established, and 
a feature set specified; it then left the original spec it started in, 
and was generalized to be more broadly applicable as its own spec.  It 
went through lengthy review by authors and implementors, and was thought 
to be stable; the very issue you point out was discussed and decided 
against.  This whole thing took place over the course of 3 or 4 years.

I think in this case, the implementors were not unreasonable to jump the 
gun a bit.  And regardless of whether what the implementors did is 
justifiable, if content is created that uses the nodeList, it will be 
incompatible with existing deployed implementations, which I think we 
can all agree defeats the point of standards.  It's also disrespectful 
to the implementors who proposed, supported, and implemented this spec.

Speaking of jumping the gun, I haven't yet heard back from the 
implementors or the WGs in question, so I'm asking you to exercise some 
patience for a formal response to your comment.  It's possible that when 
all is said and done, there may be a favorable judgment regarding adding 
a nodeList.

If you would please provide some detailed and concrete use cases where 
you think that your proposed functionality is needed, that would 
certainly make for a stronger case.  I also think it's within scope for 
us to examine whether this functionality should go into the Selectors 
API spec instead.

[1] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0231.html

-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI
Received on Friday, 28 March 2008 21:23:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:25 UTC