Re: [XBL] content element and locked

On Wed, 10 Jan 2007, Cyril Concolato wrote:
> 
> Thanks. I think section 3.7 "Binding Inheritance" is becoming clearer every day. I think it could be improved with the following changes:

> - The text in the example uses the terms "explicit inheritance chain" 
> and "implicit inheritance chain" which are the appropriate terms. I 
> think you should introduce them at the beginning of the section and then 
> use them consistently.

Ok, I tried to do that.


> I suggest replacing the first paragraph: 
>
> "Bindings can inherit from each other explicitly using the extends 
> attribute.They can also inherit from each other implicitly if multiple 
> bindings are attached to an element."
>
> with
>
> "Bindings can inherit from each other explicitly using the extends 
> attribute, thus creating explicit binding inheritance chains. They can 
> also inherit from each other implicitly if multiple bindings are 
> attached to an element, thus creating the implicit binding inheritance 
> chain."

Since the definition of the term is right below that paragraph, I'll omit 
the mention of the term in the first paragraph. (I've received feedback 
before asking for terms to be only used once defined.)


> - You should also change replace in the text below the figure: "with the 
> implicit inheritance chain going down each explicit inheritance chain 
> sequentially." with "with the implicit inheritance chain going down each 
> explicit inheritance chain*s* sequentially."

I believe that would be gramatically incorrect in English.


> - Then, you should use "The base binding (of the implicit inheritance 
> chain) is the binding ..." instead of "A base binding is a binding ..." 
> in the definition of base binding.

I'm not sure this one actually helps that much. The spec would become much 
more verbose if we called it that.


> - Similarly, use "The base binding of an explicit inheritance chain the 
> binding"

Done that one.


> - Similarly, use "The most derived binding is the binding that no other 
> binding inherits from."

Not sure what you mean here.


> So do I understand correctly from the algorithm that a Node can be 
> assigned to a locked content only using the xblSetInsertionPoint method 
> ?

That's one way; the other way is by it being assigned before the element 
is locked, and locking the insertion point dynamically.


>> [the example in section "4.5. The Final Flattened Tree"]
> 
> I see from that example that there are 2 'content' elements marked with 
> a *, meaning that C is assigned to both content elements. I don't see 
> the use for this possibility to assign a node to multiple content 
> elements, since in the end, a Node can appear only once in the final 
> flatten tree (is that correct?). If there is no use, I don't see the 
> point of mentioning it, it is quite confusing and I would remove the '*' 
> on content*/R.

It's not that there is a use or not. It just happens when you have nested 
bindings. There are two bound elements in that example. One is inside the 
other's shadow tree. What would you final flattened tree look like if you 
didn't assign the element to a <content> element in both shadow trees?


> Thanks for the clarification. It's better. I think it would be clearer 
> if a Node could be assigned to, at most, one content element in the 
> binding implicit inheritance chain.

This is already the case. It can only be assigend to two <content> 
elements when there are two totally separate bound elements, each with 
their own implicit binding chain, both of which have the node as their 
explicit child (which, again, can only occur if the second binding is on 
one of the elements in the first binding's shadow tree, and that bound 
element has as its child node a <content> element from the outer binding's 
shadow tree).


> That would mean unassign all unlocked content elements from all bindings 
> and not just for the current binding.

As described above, I don't understand what that would mean.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 11 January 2007 00:05:56 UTC