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

> Gosh it's feels really wrong to be raising this as an issue for 1.1  
> now as opposed to last year during last call.

It don't think it is wrong. It is hard to catch everything during last  
call. It may be unfortunate to raise it now, but an issue is an issue.  
Better raise it now than in five years.

> The target attribute does what it was designed to do, it directs the  
> result of the XForms submission to a place indicated by an XPath  
> expression.
>
> Right now it only works on a replace instance or text submission,  
> but if it started to work on a replace all submission, there's no  
> reason to suspect we wouldn't run the XPath against the containing  
> document.

Attributes which necessarily function as XPath expressions, like @ref,  
@nodeset, @value, etc. obviously need to be defined as containing  
XPath expressions in the first place.

But you can't make *every* attribute in the language an XPath  
expression. Or rather yes, you can, but it's not the philosophy we  
have followed so far in XForms, it's not that of any XML-based  
language I know, and I think it would be ill-advised to start now on  
that path for XForms.

For use cases where more often than not, attribute values are  
statically defined by the form author, the use of literals is good.  
Otherwise you constantly end up with double and single quotes, like  
method="'post'". I don't think we want to require that from form  
authors.

We have solutions for dynamically specifying attribute values which  
otherwise would be static: nested elements (which I don't like) or  
attribute value templates (my preference).

It makes sense for xforms:submission/@target, as defined now in XForms  
1.1, to be an XPath expression, because its purpose is always to point  
to a destination node.

But I think it would be wrong to use this same attribute for a  
completely different function, namely computing a window/frame id.

> This isn't the form tag, it's the submission element, and there is a  
> very easy way to convert from an HTML target attribute with an IDREF  
> to a submission element with a target whose XPath expression invokes  
> the id() function on the document().

I am not sure I am following that, but of course a conversion can be  
done. This does not address my initial concern, which regarded the  
native XForms syntax. I do think that syntax matters.

> The use of ID is increasingly ill-advised anyway given dynamic  
> content.

See above.

> For all of these reasons, I propose we stick with submission/@target  
> as an XPath expression and if we ever go to make it work for replace  
> all submission, then we'll make it work for replace all submission.

As already discussed, I don't like that reuse of the @target attribute  
for replace="all". It mostly comes down to not being good language  
design, IMO, to have a given attribute perform functions which are  
that different. This for me rules out, in the future, reusing @target  
for specifying a target window/frame if @target is already used for  
specifying a destination node in an instance.

Anyway, understand me: I really wouldn't want XForms 1.1 to drag for  
six more months just because of a stupid attribute name. I want XForms  
1.1 out and done.

What I am hoping is that there is a way to make this small change  
without XForms 1.1 dragging on and on. It is not a functional change,  
just a minor syntax change, which on the upside opens the door for  
reducing the gap between XForms and HTML.

-Erik

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/

Received on Wednesday, 16 April 2008 05:46:02 UTC