Re: Spec review, part 1

Eric,

Am 14.06.12 20:25, schrieb Erik Bruchez:
> Joern,
>
> Thanks for that feedback.
>
> The issue you are raising with ids is interesting.
>
> There are 3 ways to go about this:
>
> 1. Don't do anything to solve the problem and stay with plain
> inclusion semantics.
> 2. Provide capability for full encapsulation (see below).
> 3. Do something in between (like id prefixing).
>
> In our implementation, we have implemented a superset-of-a-subset of
> XBL 2. The main reason we did so was because XBL provides shadow
> content, which is content that is fully encapsulated from the point of
> view of the component implementor and the component user. In such as
> system, communication between the component and the outside world is
> tightly controlled via events.
>
> We use that notion of shadow DOM for both custom UI components and to
> implement dynamic behavior for our form builder (this allows you to
> dynamically modify an XForms document as you go, without fully
> reloading it each time, very much as you would do in a browser), and
> we would likely use it for sub-forms as well.
>
> Doing things this way has huge benefits in terms of modularization,
> encapsulation and abstraction: you can reuse such a component
> anywhere, without clashes, and multiple times. On the other hand, it
> is a bit harder to implement than plain includes.
>
> (Note that XBL 2 is dead, but all its major concepts live on in the
> Shadow DOM work [1]. The only missing aspect is declarative XML markup
> to describe components. The big hope is that this will fully make it
> to web browsers in the future. Chrome already has support for that,
> used internally.)
Yes, i'm aware of XBL 2, its fate and the fact that Orbeon has 
implemented a 'superset of a subset' as you say.

And i have considered myself more than once to do the same thing but to 
be honest never could get warm with XBL 2. While the ideas are surely 
interesting i always felt it to be much too heavy-weight to really 
integrate it in betterFORM. Besides it's complexity (and of course it's 
lack of acceptance) i just don't wanted to add another technology to the 
already diverse mix in XForms - IMO it always has been (and still is) 
one of the main hurdles for XForms beginners that they have to deal with 
XPath, Schema, XML Events etc. to get going (all of these being not 
trivial im themselves). This does not make XForms a first class choice 
when starting with simple use cases (and realizing later that aren't 
that simple ;) To cut it short XBL 2 was not what i felt would make 
things easier.
>
> This is not to rule out the plain include approach: it is a common way
> to deal with composition in software, and valid in its own right.
Right.
>
> So now the question is: what should XForms 2 say about this, if
> anything? I doesn't seem like doing full encapsulation is is in scope
> for XForms 2, but I think that's the right thing to do in the longer
> term. If that's the case, then I am not in favor of being too specific
> in the spec about specifying something like id prefixing, because
> that's just a stopgap measure.
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.
>
> But there might be a reasonable way out, with two inclusions modes
> specified either with load/submission or on the embedding group
> element:
>
> 1. Plain inclusion.
> 2. Loosely-specified encapsulation.
>
> With mode #1, nothing is done to address id clashes. Embedding and
> embedded XForms elements have visibility on each other.
>
> With mode #2, some unspecified mechanism must be implemented by the
> XForms implementation to do some level of encapsulation. This would
> allow simpler id prefixing methods as well as full shadow tree
> encapsulation. Not all implementations would necessarily guarantee
> full encapsulation.
>
> For #2 to work, some minimal level of interoperability must be
> specified. For example:
>
> - events from the embedded form should not flow over to the embedding form
> - the embedding form should not be able to address elements of the
> embedded form with simple id references
> - the embedded form should not be able to address elements of the
> embedding form with simple id references
> - the embedding form must be able to dispatch an event to the embedded form
> - the embedded form must be able to dispatch an event to the embedding form
>
> You could imagine the following syntax for the two modes:
>
> <xf:load resource="Child.xhtml" show="include" targetid="mountPoint"/>
> <xf:load resource="Child.xhtml" show="embed" targetid="mountPoint"/>
>
> Remains communication in pseudo-encapsulated mode. It comes down to
> what event target behaves specially.
>
> The embedding form could dispatch events to the "mount point". The
> embedded form could dispatch it to its "document", if there is such a
> thing, or via a special id (we use the id of the XBL binding for the
> UI components, and we have #document as a special id representing the
> top-level XForms document).
>
> The embedding form could attach event handlers to the mount point, as
> for any handler, and would receive events dispatched by the embedding
> form. Similarly, the embedded form could attach event handlers to its
> document and and receive events dispatched by the embedded form.
>
> This is exactly what we do with our UI components to implement two-way
> communication via events.
I see your point about #2 but tend to prefer #1 mostly for 2 reasons:

- it's much simpler either to implement and to understand
- 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.

I'm surely biased here as we implemented the simpler approach but in 
practice we did not find problems with the 'lack of encapsulation'. 
Actually as you stated in your former mail: "things after embedding the 
form are as if the included models and
groups had been in the page in the first place". This is something users 
easily understand.

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.

I see that your approach is superior with regard to re-use of multiple 
similar 'components' and also might allow a finer-grained control but 
i'm not at all sure if i would like to pay the price of imcreased 
complexity for both users and implementers.

We almost always re-used complete model/UI combinations and have been 
able to address very complex scencarios with that and with a minimum of 
extra learning or additional concepts.

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.

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.

Thanks a lot Eric for your interesting insights into the 'encapsulated 
approach'. That's really appreciated. And sorry for the long read.

Best,

Joern


>
> Feedback welcome,
>
> -Erik
>
> [1] http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html
>
> On Thu, Jun 14, 2012 at 2:12 AM, Joern Turner
> <joern.turner@betterform.de>  wrote:
>> Hello,
>>
>> just my 2 cents from our experience with our load embed implementation...
>> Am 14.06.12 00:38, schrieb John Boyer:
>>
>>> So I suppose the note telling authors that no special processing occurs
>>> so don't let IDs clash really means implementation-specific behavior if
>>> they do.
>>
>> I'm looking at http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0 and there is
>> already a note saying:
>> "Note that the load action performs no special processing of id attributes;
>> therefore authors should pay careful attention to avoid id conflicts."
>>
>> I think this is pretty clear.
>>
>> However here we hit a limitation regarding id handling - suppose you want to
>> embed the same form twice. This simply won't work if the embedded
>> model/group uses specific ids.
>>
>> I know it's hard and we also haven't come up with a mechanism yet but it
>> would have been good to at least try to address that issue. Just a guess -
>> maybe we can add an attribute to load that allows to define a prefix to be
>> added for every id in the embedded markup. As i said - just a first guess
>> and surely not elaborate.
>>
>>>
>>> But what does it mean to say that a new model should behave as if it had
>>> been in the page all along?
>>> We're well past the phase where the xforms processor initializes all
>>> models by dispatching xforms-model-construct to them. Wouldn't it be
>>> better to be explicit and say that any newly embedded model receives
>>> xforms-model-construct... which begets xforms-model-construct-done,
>>> which begets xforms-ready?
>>
>> Yes, i fully agree. Otherwise you loose any real chance to use embedding for
>> modularization - let me explain: we try to setup our forms so that they can
>> be used either standalone or embedded. But model init events are an
>> important part of a form and if these events are not dispatched during
>> embedding you'll end up with 2 different ways of processing a form.
>>
>> Back in 2011 Lars Windauer was asked for preparing a spec text for embed but
>> we did. In the meantime the WG seems to have moved forward so i'm not sure
>> if that's fully relevant still. Just for reference you can still find our
>> version here:
>> https://betterform.de/trac/wiki/loadEmbed
>>
>> In our version we added the sentence:
>> "The processor begins initialization by dispatching xforms-model-construct
>> to each XForms model in the embedded XML content if any. Processing
>> concludes as described by 4.2 Initialization Events. "
>>
>> Probably that helps here...
>>>
>>>
>>> Also, a special attribute of targetid is clearly missing, since it is
>>> referenced in the text.
>>>
>>> Cheers,
>>> John M. Boyer, Ph.D.
>>> Distinguished Engineer, IBM Forms and Smarter Web Applications
>>> IBM Canada Software Lab, Victoria
>>> E-Mail: boyerj@ca.ibm.com
>>>
>>> Twitter: http://twitter.com/johnboyerphd
>>> Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
>>> Blog RSS feed:
>>> http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw
>>>
>>>
>>>
>>>
>>>
>>> From: "Klotz, Leigh"<Leigh.Klotz@xerox.com>
>>> To: Erik Bruchez<erik@bruchez.org>
>>> Cc: Nick Van den Bleeken<Nick.Van.den.Bleeken@inventivegroup.com>,
>>> <public-forms@w3.org>,<public-xformsusers@w3.org>
>>> Date: 13/06/2012 03:23 PM
>>> Subject: RE: Spec review, part 1
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>>
>>> I agree.
>>>
>>> -----Original Message-----
>>> From: ebruchez@gmail.com [mailto:ebruchez@gmail.com] On Behalf Of Erik
>>> Bruchez
>>> Sent: Wednesday, June 13, 2012 9:23 AM
>>> To: Klotz, Leigh
>>> Cc: Nick Van den Bleeken; public-forms@w3.org; public-xformsusers@w3.org
>>> Subject: Re: Spec review, part 1
>>>
>>> Looking at this again, I think what I felt was missing could be
>>> covered with wording along the lines of:
>>>
>>> "things after embedding the form are as if the included models and
>>> groups had been in the page in the first place"
>>>
>>> This would make it clear what happens with events, id resolution, and
>>> visibility of the embedded form on the embedding form, in particular.
>>>
>>> -Erik
>>>
>>> On Thu, Jun 7, 2012 at 12:47 PM, Leigh L Klotz Jr
>>> <leigh.klotz@xerox.com>  wrote:
>>>   >  Is this for submission or for load? We agreed to load/@show=embed at
>>> a F2F
>>>   >  meeting. It was proposed (and implemented) by betterForm, and it's also
>>>   >  implemented on XSLTForms, so we have one split-agent and one client
>>>   >  implementation. We also agreed that submission should have the same
>>>   >  capabilites as load, so that's why I added it there.
>>>   >
>>>   >  Leigh.
>>>   >
>>>   >
>>>   >>>  9. show="embed"
>>>   >>>
>>>   >>>  I think the current text is still very incomplete. Need to
>>>   >>>  discuss/action to complete it.
>>>   >>
>>>   >>  Leigh added this just before he left the group, I also expressed my
>>>   >>  concerns about this text at the last editorial meeting.
>>>   >>>
>>>   >>>
>>>   >>>  In general, there are some wording issues (tenses, in particular).
>>> How
>>>   >>>  do we fix that?
>>>   >
>>>   >
>>>
>>>
>>
>
>

Received on Thursday, 14 June 2012 21:07:22 UTC