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