Re: Spec review, part 1

Joern and all,

Thanks for the feedback.

We discussed this in today's call, and the group is leaning towards
specifying a little more than plain inclusions at this point.

I think there at least two types of scenarios that make sense:

1. Plain inclusions. Say you have a large form and want to split it
into several parts, loaded dynamically. Then it would make sense if
the subform doesn't do any particular scoping. The embedding form and
the embedded form can access each other as if they had been the same
document all along.

2. Inclusions with some level of scoping. Say you have two existing
forms and want to combine them. In this case, the likelihood of
clashes is high.

If you only do plain inclusions, users of the feature will surely
shoot themselves in the foot as soon as they try to embed something
that was not initially designed to be compatible with the embedding
form (scenario #2). Things just won't work. So this would be the main
argument in favor of allowing a mode with scoping (the secondary
argument is that doing so enables more use cases).

It was pointed out during the call that, when you resolve ids, you
already need to implement the XForms id resolution algorithm. For an
implementor, adding scope resolution could be just an extra step to
perform there. The simplest implementation would like like this:

- upon embed, prefix all static ids on elements
- id resolution from embedded XForms adds a prefix to each id requested

Pretty simple.

Open questions if we go down that path:

- Would prefixing/namespacing be tightly specified in the spec, or only loosely?
- Does this allow embedding/embedded form to access each other's
elements? Do we say anything about this?
- What happens with events? If they flow along the subform boundary,
they might contain ids which are not visible from the embedding form.

Some follow-up on your message below:

> cases (and realizing later that aren't that simple ;) To cut it short XBL 2
> was not what i felt would make things easier.

Fair enough, implementing a component system is not easy! For us XBL
here is really a tool for component implementors. Once you have
developed such a component, the user uses it like any standard XForms
control. So while that certainly adds complexity to the
implementation, the complexity is fully hidden from form authors.

> Agree - it's better not to put that into the spec at least not as a MUST or
> SHOULD and to leave it to implementations to cope with the problem  -
> addressing it in a implementation-specific way or just ignore it or throw
> exceptions. That way there's room for creativity and we'll probably end up
> with more valid (and valuable) solutions over time.

So as mentioned above it seems that the working group is leaning
towards specifying a bit more here.

> - it does not risk causing confusion for users. Though that might be a a bit
> of an off-topic here i nevertheless feel that it should be noted that the
> syntax diversity in other places of XForms as well as the overly powerful
> insert action already cause enough problems. Introducing new diversity is
> probably not helpful and though you made your points perfectly clear i doubt
> that this distinction between #1 and #2 is easy to grasp for many users.

The big worry here is that having only plain includes will confuse
users, because things will very quickly not work as soon as you have
an id clash. So maybe there is no way around it: introducing embedding
will either lead to confused users because there are id clashes, or
because there are embedding options.

> Further (and more philosophic) what does encapsulation really means here? In
> the first place the type of encapsulation that's really important is the
> encapsulation of the model. I want to be sure that an embedding mechanism
> does not break the 'rules of the model' but this is not the case even for
> the simple variant of #1.

By encapsulation I simply mean that one side cannot see some (or any)
aspects of the other side.

> For me it feels that #2 addresses more the needs of a component model - we
> in contrast just wanted to re-use complete xforms models.

But the embedded forms also have controls, and that's where clashes
can happen too.

> Finally a different question regarding embedding. Why does the text mentions
> the group element as embedding target explicitly?
>
> "(...) "with the group set as content of the group indicated by attribute
> targetid (...)"
>
> Is there any specific reason why the element indicated by targetid must be a
> group element? Why can this element not just be any element of the host
> language? We almost always simply use a
> <div id="mountpoint"/>
> It's not really a big deal - just asking out of interest.

I think the spec should allow it to be the id of any containing
element: host language elements, xforms:group, xforms:case,
xforms:repeat.

-Erik

Received on Wednesday, 20 June 2012 17:15:21 UTC