Re: Spec review, part 1

Eric,

thanks for getting back. Please allow a few comments.

Am 20.06.12 19:14, schrieb Erik Bruchez:
> 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.
Right. And i'd like to emphasize that this is (at least in our practice 
over the last years) the most common use case. And i'd like to add that 
nowadays we're using subforms in nearly every project without any 
problems you refer to below. IMO this shouldn't be underestimated - at 
least the WG always asked for feedback from the real world.

>
> 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).
Sorry if i consider this case as a bit constructed - in the overwhelming 
majority of cases subforms are designed for a certain environment - they 
are not components and subforms shouldn't be confused with those. I 
think these are different planets though they might share the same shape.

But even if they are not designed explicitly for inclusion - with a bit 
of accuracy (naming conventions) you can drastically reduce that 
likelihood. Consider CSS - today pages are dynamically constructed and 
assembled from different sources and though clashes might happen i won't 
go so far to say that 'the likelihood of clashes is high' nor that the 
consequences are unbearable. The 'users' referred here are XForms 
authors - not end users. You won't really state that XForms authors 
aren't bright enough to deal with this - at least they need to be bright 
enough to deal with this complex technology.

Subforms are typically used to modularize big, complex applications (at 
least we use it like that). So, when using a subform you do it for a 
certain purpose or environment. It's not rare that in this case the 
forms are even generated which makes the avoidance of id clashes simply 
a task for the developer of the generator. Even if we remove all 
potential conflicts this won't make a component model out of XForms and 
i consider it a misconception trying to do so. That is not to say that a 
component model *within* XForms might not be useful.

So of course you can try to remove all uncertainty from the world but as 
we see in the real world this often also results in the loss of freedom. 
Though i think it's a good idea that a spec mentions potential problems 
and boundaries i don't think it's necessary nor desirable that it 
normatively tries to resolve all those.

>
> 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.
Right - agree. Simple enough that implementers adapt it but nevertheless 
i don't think that a spec should normatively dictate this.
>
> Open questions if we go down that path:
>
> - Would prefixing/namespacing be tightly specified in the spec, or only loosely?
I think i made myself clear here - loosely IMO.

> - Does this allow embedding/embedded form to access each other's
> elements? Do we say anything about this?
What is meant by 'elements'? Model, UI, events?

A subforms that cannot interact with its parent (or however you want to 
call it) it pretty useless. There need to be mechanisms to at least 
exchange some data even if i won't go so far as to say one model can 
freely access another model data or manipulate them.

An example from our experience might shed some light on this. We added 
an extension function to access a foreign models instance nodes just 
like the standard instance() func
tion does.

However this proved to be not one of our best ideas - the likelihood 
that users try to use this function e.g. on a xf:bind is high and 
creates the problem of cross-model dependencies - i don't think that 
this is a particular good idea. On the other hand there needs to be a 
way to exchange some data.

An example: one of our customers has build a complex wizard with 
subforms - each page being a subform on its own. The data each subform 
picks up are gathered in an instance of the parent form. This works 
quite well but of course requires to exchange some data. We found that 
this is kind of a pattern for subforms. You often need to pass some data 
'down' to a subform, allow it to act upon those and then pass them 'up' 
again. This way the subform can contain the logic and constraints of 
this particular subset of the data - the parent does not need to know 
about those. This pattern works very well and we've used it in different 
contexts.

> - What happens with events? If they flow along the subform boundary,
> they might contain ids which are not visible from the embedding form.
Not sure if i get the point here - seems just another variant of the 
argument above (2.)
>
> 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.
Again - i doubt the argument that this 'will very quickly not work' - 
it's at least a exaggeration. I think we agreed that implementers can 
surely chose to resolve that for their users behind the scences and at 
least it would be worth a 'SHALL' in the spec but IMO not more than that.

I surely fully respect the competence of the WG but i'm simply not 
sharing the idea that a spec should resolve any and all potential issues 
that might arise when users don't take care.

Maybe i'm an extremist here but i believe that even the tiniest piece of 
addition to a spec that already is as complex as XForms should be 
considered very very thoroughly and in this case i'm clearly against 
adding a second mode for embedding.

Thanks for reflecting on my remarks - very much appreciated. And please 
excuse if i should have over-reacted on some points - just tried to make 
myself clear.

Joern
>
>> 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 Thursday, 21 June 2012 21:59:45 UTC