Re: Spec review, part 1


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.)

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.

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.

But there might be a reasonable way out, with two inclusions modes
specified either with load/submission or on the embedding group

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.

Feedback welcome,



On Thu, Jun 14, 2012 at 2:12 AM, Joern Turner
<> 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 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:
> 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:
>> Twitter:
>> Blog:
>> Blog RSS feed:
>> From: "Klotz, Leigh" <>
>> To: Erik Bruchez <>
>> Cc: Nick Van den Bleeken <>,
>> <>, <>
>> Date: 13/06/2012 03:23 PM
>> Subject: RE: Spec review, part 1
>> ------------------------------------------------------------------------
>> I agree.
>> -----Original Message-----
>> From: [] On Behalf Of Erik
>> Bruchez
>> Sent: Wednesday, June 13, 2012 9:23 AM
>> To: Klotz, Leigh
>> Cc: Nick Van den Bleeken;;
>> 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
>> <> 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 18:26:25 UTC