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

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 Tuesday, 21 February 2006 12:38:23 UTC