Re: Unfortunate choice of attribute name in XForms 1.1: xforms:submission/@target

Erik Bruchez wrote:
>> in your post starting this thread you wrote
>> >> > (Note that in our implementation, we already support an extension
>> >> > attribute called xxforms:target on xforms:submission and 
>> xforms:load,
>> >> > which behaves like its HTML counterpart.)
>> Note that we have @show on xf:load which mirrors the HTML form/@target 
>> attribute. No need for @target there.
> I am not in favor of frames in general, but @target does more than @show 
> since it allows you to target a frame by name, not just open a new window:
> It also support the predefined _blank, _self, _parent and _top names.
> I don't entirely dislike the idea of reusing @show, but it seems that it 
> falls short of being an equivalent to the HTML @target attribute, in 
> addition to being a less familiar name.

Yes, of course. But "new" easily maps to "_blank", and "replace" to
"_self". The rest is frame-related which I wouldn't terribly miss.

>> So, why not adding @show to xf:submission? It would be optional and 
>> would only be considered when @replace="all" (analogous to @target, 
>> which is only evaluated on @replace="instance" or @replace="text").
>> We don't need to match the HTML attribute names, we only need a 
>> mapping like this:
>> html:form    xf:submission (defaults to @replace="all")
>> @action        @resource
>> @enctype    @method
>> @target        @show
>> Adding a new attribute to xf:submission, however, does not feel good 
>> to me. We already have 21 attributes for this element. This painfully 
>> highlights the need for a submission refactoring. Which would be worth 
>> another thread.
> Yes, submission has a lot of attributes...
> But using attributes with familiar names would help in that kind of 
> situation. Introducing xforms:submission/@target as a new attribute in 
> XForms 1.1, but with a meaning different from the HTML @target 
> attribute, does add to the confusion, especially for authors with a 
> solid HTML background.

But we already deprecated @action in favor of @resource. So we have 
different names anyway.

> I am not sure why xforms:load/@show was picked back in the days, but 
> today, in the context of XForms 1.2 in particular, it seems that we are 
> trying if possible to be closer from HTML.

This is an XLink behaviour attibute, see It supports values "new",
"replace", "embed", "other", and "none", which of course is not helpful 
with regard to frames.


> -Erik
> -- 
> Orbeon Forms - Web Forms for the Enterprise Done the Right Way

Ulrich Nicolas Lissť

Received on Tuesday, 8 April 2008 22:22:47 UTC