Ian Hickson a écrit :

On 1/9/07, Cyril Concolato <cyril.concolato@enst.fr> wrote:

After a second reading of the specification, I understand that now better
the processing of content elements. I made a diagram of the algorithm. I
attach it in case you find it useful and right. I had a hard time
understanding what you meant by "next most derived" in step 6. I think you
mean "the parent binding in the binding chain". If so, could you use my
wording or another explicit wording instead.

I've now explicitly defined the term "next most derived".

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. 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."
- 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."
- 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.
- Similarly, use "The base binding of an explicit inheritance chain the binding"
- Similarly, use "The most derived binding is the binding that no other binding inherits from."

From this diagram, I understood a bit more the 'locked' attribute. I
understand that a node may be assigned to multiple content elements. But, am
I correct to say that if a node is assigned a locked content, it cannot have
another content assigned (locked or not).

The "locked" attribute has no bearing on being assigned to multple
<content> elements.

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

Each explicit child can only be assigned to a
single <content> element per shadow tree. It's just that in certain
edge cases (namely when the parent of a <content> element is itself
bound), it is possible for an explicit child to be taking part in two
separate shadow trees nested one in the other, and then it is assigned
to two <content> elements. See 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.

Some points remain unclear. I'm still not 100% sure about when the
assignment of a content element to a node is removed. Do you remove all
assignments when you redistribute nodes? I don't think so, otherwise Step 1
would never be applied. But on the other hand, if a node is assigned to a
unlocked content element, each time the nodes are redistributed, a new
assignment may happen. Thus the number of content assigned to a node could
increase indefinitely. Could you clarify?

I've tried to clarify this. Let me know if that's better.

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. That would mean unassign all unlocked content elements from all bindings and not just for the current binding.

Regards,

Cyril