Re: ElementTraversal comments

On Tue, 26 Feb 2008 06:42:49 +0100, Doug Schepers <schepers@w3.org> wrote:
> Anne van Kesteren wrote (on 2/25/08 4:25 PM):
>> * It's not clear from the introduction why we need childElementCount.  
>> Having both linked list and array like traversing for the DOM is  
>> already slightly unclear to me, but childElementCount seems to provide  
>> neither.
>
> I've reworded the introduction slightly, in hopes of making it more  
> clear.  I've also added explanatory text to example 3.2, which  
> demonstrates the use of childElementCount.

Where is the draft located that contains these changes? It seems you  
haven't updated the editor's copy which makes it hard for me to revew the  
changes.


>> * I don't understand "A User Agent may implement similar interfaces in  
>> other specifications, but such implementation is not required for  
>> conformance to this specification, if the User Agent is designed for a  
>> minimal code footprint." I suggest dropping this sentence.
>
> That's an odd request.  A better suggestion might be to clarify the  
> sentence, since I wouldn't have put it in if I didn't think the point  
> needed to be made.
>
> Most of the functionality of this spec is an optimized subset of DOM2  
> Traversal & Range, and it is intended that a UA could implement both by  
> aliasing; however, this isn't required for conformance to this  
> specification.  I hope that clarifies it for you.

It's not a subset at all. Clarification is ok too, but I think the  
sentence is a distraction.


>> * It's not clear to me how "For the purpose of ElementTraversal, an  
>> entity reference node which represents an element must be treated as an  
>> element node." works. Does this mean that an EntityReference node also  
>> implements this interface? I suggest dropping this sentence or stating  
>> that this interface assumes that all entities are normalized away or  
>> something.
>
> I put this in as a response to an earlier comment [1].  While I think  
> it's an edge case, the commenter was satisfied by the response.

That may very well be so, but I don't understand what it's saying.


> I'm reluctant to mandate how a UA implements the solution, whether by  
> implementing this interface on the entity reference node or only on the  
> expanded resulting DOM, because I don't know how every UA does so.  I  
> don't think it effects interoperability, so I prefer to leave it as is.

Leaving it as does not satisfy me as I think the sentence is unclear.


>> * "Accessing this attribute of an element must return a reference to  
>> the first child node of that element which is of nodeType 1, as an  
>> Element object." I don't think ", as an Element object." makes much  
>> sense in this sentence. (Likewise for similar sentences.)
>
> I don't agree, but if you care to suggest alternate wording, I'll  
> consider it.

"Getting this attribute of an element must return the first Element child  
node of that element or null if there are no Element child nodes."


>> * I don't think the IDL should be in the appendix. It's a useful  
>> overview of what the draft defines.
>
> I think this is a stylistic change that doesn't affect the readability  
> or usefulness of the specification.  I prefer to keep it as is, since it  
> makes more sense to me this way.

It would tell you upfront what the interface is and what members it  
introduces and provide pointers to the definitions of those members. I  
think that would make the draft more readable.


> Since I made only editorial, non-normative changes, I published them in  
> the upcoming LCWD document, to be published next Monday.

I don't understand why it's not in the editor's draft. Everything what  
this group does, including editorial work, is captured in public documents  
nowadays.


> [1] http://lists.w3.org/Archives/Public/public-webapi/2007Mar/0065.html


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Tuesday, 26 February 2008 09:47:18 UTC