- From: John Boyer <boyerj@ca.ibm.com>
- Date: Tue, 15 Apr 2008 22:07:45 -0700
- To: "Mark Birbeck" <mark.birbeck@x-port.net>
- Cc: "Erik Bruchez" <ebruchez@orbeon.com>, <public-forms@w3.orgpublic-forms>
- Message-ID: <OF959EF32B.6B5ABEFB-ON8825742D.001B891B-8825742D.001C2DE3@ca.ibm.com>
Nobody really picked up discussion of this on the mailing list after the lengthy discussion on the telecon, so let me proceed with it... 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. 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. 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(). The use of ID is increasingly ill-advised anyway given dynamic content. 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. John M. Boyer, Ph.D. Senior Technical Staff Member Lotus Forms Architect and Researcher Chair, W3C Forms Working Group Workplace, Portal and Collaboration Software IBM Victoria Software Lab E-Mail: boyerj@ca.ibm.com Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw "Mark Birbeck" <mark.birbeck@x-port.net> Sent by: public-forms-request@w3.org 04/09/2008 03:16 AM To "Rogelio Pérez Cano" <rogeliop@satec.es>, "Erik Bruchez" <ebruchez@orbeon.com> cc "Forms WG (new)" <public-forms@w3.org> Subject Re: Unfortunate choice of attribute name in XForms 1.1: xforms:submission/@target Rogelio -- you are right, but it has been 're-introduced' in XHTML 1.1 Modularisation. And Erik, you are exactly right that we need this, but I think John's answer might cover this. John says that @target could be used in a number of ways depending on the context, and the reason this is legitimate is that in XHTML @target is actually only a hint. It's probably obvious why it's a hint--if a browser doesn't have support for multiple windows, or is only a small screen device or a photocopier, then @target="x" might have to do nothing. It's not dissimilar to the way we do some things in XForms, in that it captures the 'authors intent', but that doesn't necessarily mean that the author will get what they want in all environments. So the question is about whether it being a hint is appropriate to all uses of @target in XForms (i.e., there may be situations where the processor _must_ act in a certain way, in which case you might argue it's no longer a hint). I haven't been through and looked at them, though. Regards, Mark 2008/4/8 Rogelio Pérez Cano <rogeliop@satec.es>: > > Hi Erik, all, > please correct me if I´m wrong but at least in XHTML 1.0 Strict the > "target" attribute doesn´t exist, so I´m not sure if it´s going to be a > problem, for sure xhtml/html experts in the group may have better opinion on > it. > > Regards. > > Roger. > > -----Mensaje original----- > De: public-forms-request@w3.org [mailto:public-forms-request@w3.org] En > nombre de Erik Bruchez > Enviado el: martes, 08 de abril de 2008 2:24 > Para: Forms WG (new) > Asunto: Unfortunate choice of attribute name in XForms 1.1: > > > xforms:submission/@target > > > All, > > It just occurred to me that the XForms 1.1 xforms:submission/@target > attribute [1] is badly chosen. > > The reason is that a "target", in HTML speak, specifies an optional target > window or frame. This, in particular, applies to <a> and <form> in HTML. [2] > > In the future, we may want to officially support such a concept of target > window or frame in XForms. Purely out of familiarity with HTML, the name > "target" would be an obvious choice. But if we use "target" > now to specify the destination for data replacement, we won't be able to use > that name. > > (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.) > > For this reason I suggest that we change the name of this attribute in > XForms 1.1. Suggestions are welcome, but "destination" could work. > > -Erik > > [1] http://www.w3.org/TR/xforms11/#submit > [2] http://www.w3.org/TR/html401/present/frames.html#adef-target > > -- > Orbeon Forms - Web Forms for the Enterprise Done the Right Way > http://www.orbeon.com/ > > > > -- Mark Birbeck mark.birbeck@x-port.net | +44 (0) 20 7689 9232 http://www.x-port.net | http://internet-apps.blogspot.com x-port.net Ltd. is registered in England and Wales, number 03730711 The registered office is at: 2nd Floor Titchfield House 69-85 Tabernacle Street London EC2A 4RR
Received on Wednesday, 16 April 2008 05:08:41 UTC