Re: CDR Framework: Last Call Comments

Ian,

Thanks for your feedback.  I have responded inline to each of your 
comments.

Please let us know within two weeks if this reply does not address your 
comments.

Thanks,
Steve Speicher
(appologies in advance of potential repost)

Ian Hickson <ian@hixie.ch> wrote on 12/28/2005 07:59:45 PM:

> * http://www.w3.org/TR/2005/WD-CDR-20051219/#dom
> 
> The specification encourages subsetting. Subsets encourage a splintering 

> of the Web, which is bad for everyone.
> 
> Please change the specification so that subsets are discouraged.
> 

The specification addresses subsetting, it doesn't necessarilly encourage 
or discourage its use.

Due to the nature of constrained devices within the mobile industry, many 
vendors have coordinated such subset profiles and therefore will depend on 
CDF profiles to provide interoperable rich content to such devices.

> * http://www.w3.org/TR/2005/WD-CDR-20051219/#child-to-parent-dom-access
> 
> The ReferencedDocument interface requires that implementations perform 
> security checks at the element level. Historically, implementations have 

> only needed to perform checks at the Document/Window boundary. Changing 
> this will introduce a very high potential for security bugs.
> 
> Please do not introduce the ReferencedDocument interface.
> 
> Instead, the Window.parent member can be used in existing UAs to get to 
> the parent Window context.
> 
> Please coordinate with the new Web APIs group in creating specifications 

> for the Window interface.
> 

Since the CDF Framework document addresses generic DOM-based markups, we 
can not rely on the HTML DOM (where Window.parent resides) [1] and this 
doesn't satisfy a need to determine the element in the parent document 
that is the doing the referencing.

We have discussed with the Web APIs WG.  They have reviewed our proposal 
and recommend we progress with what we have specified.  We will continue 
to coordinate with Web APIs WG as at some point they may adopt this.
 
> * http://www.w3.org/TR/2005/WD-CDR-20051219/#parent-to-child-dom-access
> 
> The specification contradicts itself. On the one hand it says "If access 

> to the child document is disabled or there is no child document the 
> attribute must be null.", and on the other it says "Accessing parent or 
> child documents through the DOM as described in sections 2.1.2 and 2.1.3 

> can be disabled for security reasons. In such cases user agents should 
> throw a SecurityException.".
> 
> Please correct the specification to be clear as to what should happen if 

> the contentDocument attribute is disabled.
> 

The sentence: "If access to the child document is disabled or there is no 
child document..."
will be changed to something like: "If there is no child document..."
 
> * http://www.w3.org/TR/2005/WD-CDR-20051219/#security-exception
> 
> Please do not use a code so close to the LSExceptionCode codes of DOM3 
LS, 
> as this may lead to unintended clashes in future.
> 

There doesn't appear to be any guidance on exception code numbering for 
extensions.  Whether we select max+1 or some arbitrary number, we still 
run the risk of conflict.  We'll coordinate with the DOM/WebAPIs group to 
ensure the code we use should not conflict.

> * http://www.w3.org/TR/2005/WD-CDR-20051219/#event-propagation
> 
> Please define what "events targetted at the document shall propagate to 
> the parent document" means, in particular in terms of the DOM3 Events 
> capture phase.
> 

This may read better as "events targeted at the child document shall 
propagate to the parent document".  An event can bubble or be targeted 
from the child document to its parent document(depending on the propagate 
attrib).

> * http://www.w3.org/TR/2005/WD-CDR-20051219/#security-event
> 
> "When a document breaks through the user agent security policy" -- 
surely 
> this is supposed to say "When a document attempts to break through the 
> user agent's security policy"? Since if the document has actually broken 

> it, it's too late to do anything.
> 
> Please change the first sentence of 2.2.2 Security Event to specifically 

> define when the "security" event should be fired.
> 
> The event doesn't say what its default action is.
> 
> Please define the default action of the "security" event.
> 

This section is undergoing some modifications and you will be notified 
separately.  We have consolidated the security related comments.

> * http://www.w3.org/TR/2005/WD-CDR-20051219/#event-related-legacy-markup
> 
> "what phases it supports" implies that some events may support less than 

> all the phases. This is incorrect.
> 
> Please remove the mention of "what phases it supports".
> 
It is possible to not participate in bubble phase [2]
Though the text will be updated from:
"what phases it supports (capture, target, bubble)"
to "whether it supports the bubble phase"


[1] http://lists.w3.org/Archives/Public/www-dom/2002JulSep/0006.html
[2] 
http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-Event-canBubble
ACTION-337

Received on Monday, 20 February 2006 20:16:13 UTC