Re: proposal for new submission replace mode 'new'

I would try hard to stay away from adding a new value for "replace" unless
there is a very strong argument to show that it is absolutely necessary.

As I tried to argue above, with HTML as a host language, replace="all" can
already result in different behaviors depending on the document type
returned by the submission.

-Erik

On Mon, May 31, 2010 at 2:59 AM, Joern Turner
<joern.turner@googlemail.com>wrote:

> Nick,
>
> On Sun, May 30, 2010 at 8:07 PM, Nick Van den Bleeken <
> Nick.Van.den.Bleeken@inventivegroup.com> wrote:
>
>>  John,
>>
>>
>>
>> I didn’t read your e-mail before sending my previous reply, a value of
>> ‘target’ for replace sounds reasonable for me. Though I don’t think that it
>> is strictly needed, we already have other attributes that if present have
>> influence on another attribute.
>>
> Sure - but it is a difference if an attribute has influence (by adding an
> aspect) or if it completely overwrites the basic behavior. IMO that can
> confuse authors.
>
>
>>
>> Regads,
>>
>>
>>
>> Nick Van den Bleeken
>>
>> R&D Manager
>>
>>
>>
>> Phone: +32 3 821 01 70
>>
>> Office Fax: +32 3 821 01 71
>>
>> <nick.van.den.bleeken@inventivegroup.com>
>> nick.van.den.bleeken@inventivegroup.com **
>>
>> <http://www.inventivedesigners.com/>http://www.inventivedesigners.com
>>
>> <http://be.linkedin.com/in/nvdbleek>Linked in
>>
>>
>>
>> *From:* John Boyer [mailto:boyerj@ca.ibm.com]
>> *Sent:* vrijdag 28 mei 2010 18:40
>> *To:* Joern Turner
>> *Cc:* Leigh L. Klotz, Jr.; Nick Van den Bleeken; www-forms@w3.org
>>
>> *Subject:* Re: proposal for new submission replace mode 'new'
>>
>>
>>
>>
>> Joern raises a good point here, indirectly perhaps.
>> Using things like _top may destroy the XForms processor, but this is
>> consistent with replace="all" behavior, so that doesn't seems to bad.
>> But with target="_blank" or target="#ID", the result is not consistent
>> with replacing all of the containing document.
>>
>> Might it be better, then, to have one more attribute value for replace,
>> e.g. replace="target", which indicates that what to do with the submission
>> result is being delegated to the target attribute, and whatever happens next
>> is defined by that attribute.  This would at least make things explicit at
>> the markup level and at the code level, as Joern originally asked, i.e.
>> replace="target" would be clear about what is going on to the form author
>> and, for the implementer, would cause execution to follow a new code branch
>> in which the target attribute is processed.  At the spec level, there would
>> be no need to explain away the various @replace values where  @target made
>> no sense.
>>
>> I think we may have even discussed this possibility during one of the
>> target attribute discussions in the hazy past.
>>
>> John M. Boyer, Ph.D.
>> STSM, Lotus Forms
>> 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
>>
>>
>>
>>    From:
>>
>> Joern Turner <joern.turner@googlemail.com>
>>
>> To:
>>
>> Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>
>>
>> Cc:
>>
>> "Leigh L. Klotz, Jr." <Leigh.Klotz@xerox.com>, "www-forms@w3.org" <
>> www-forms@w3.org>
>>
>> Date:
>>
>> 05/27/2010 08:07 AM
>>
>> Subject:
>>
>> Re: proposal for new submission replace mode 'new'
>>
>>
>>  ------------------------------
>>
>>
>>
>>
>> On Thu, May 27, 2010 at 4:33 PM, Nick Van den Bleeken
>> <Nick.Van.den.Bleeken@inventivegroup.com> wrote:
>> > Hi Joern,
>> >
>> > First of all I'm happy that you can live with the target attribute.
>> i feel generous today ;)
>>
>> >
>> > One of the reasons to go with a target attribute is: That we can leave
>> the value space of the replace attribute as is
>> ("all"|"instance"|"text"|"none" | QNameButNotNCName), and define value space
>> of the new target attribute as host-language dependent.
>>
>> This only leads to a problem when using '_top', '_parent' or '_self'
>> as this results in replacing the current viewport of the browser (the
>> viewport the form is running in) and this surely should lead to the
>> destruction of the XForms processor shouldn't it? But in case i use
>> '_blank' (which was my original use case) i want the processor to keep
>> on living.  Do we possibly need to constrain the possible value space
>> of @target?
>>
>> Joern
>> >
>> > This will make it possible to align the attribute, when XForms is using
>> XHTML as host language, to be fully compatible with the target attribute
>> defined in that host language (if we were re-using the replace attribute we
>> would have needed to define a naming schema that allowed the current values
>> and targeting a new window, parent frame, other name frame, other
>> 'window',...).
>> >
>> > It is also the case that the default value for the replace attribute is
>> 'all' so the author can omit the attribute when using the target attribute.
>> An implementation can as always log a warning when the target attribute is
>> used and replace is not 'all'.
>> >
>> > Regards,
>> >
>> > Nick Van den Bleeken
>> > R&D Manager
>> >
>> > Phone: +32 3 821 01 70
>> > Office Fax: +32 3 821 01 71
>> > nick.van.den.bleeken@inventivegroup.com
>> > http://www.inventivedesigners.com
>> > Linked in
>> >
>> >> -----Original Message-----
>> >> From: www-forms-request@w3.org [mailto:www-forms-request@w3.org<www-forms-request@w3.org>]
>> On Behalf
>> >> Of Joern Turner
>> >> Sent: donderdag 27 mei 2010 15:33
>> >> To: Leigh L. Klotz, Jr.
>> >> Cc: www-forms@w3.org
>> >> Subject: Re: proposal for new submission replace mode 'new'
>> >>
>> >> Leigh,
>> >>
>> >> thanks for the quick reply.
>> >>
>> >> First of all i appreciate that the use case now has been addressed
>> >> though i'm not completely happy from a design point of view. It might
>> >> well be my personal indisposition but i don't like it too much if the
>> >> existence of one attribute (in this case 'target') changes the
>> >> behavior of another (the replace attribute). IMO this often puzzles
>> >> users and more easily leads to authoring mistakes than to use distinct
>> >> values of one attribute for distinct functionalities.
>> >>
>> >> This also reflects in implementations: you have to check several
>> >> attributes before deciding what to do. But anyway, the resolution of
>> >> the use case is the important thing here and in the end i can live
>> >> with it.
>> >>
>> >> Thanks,
>> >>
>> >> Joern
>> >>
>> >> On Wed, May 26, 2010 at 6:22 PM, Leigh L. Klotz, Jr.
>> >> <Leigh.Klotz@xerox.com> wrote:
>> >> > Joern,
>> >> >
>> >> > We agree with your use case, and note that we already have a proposed
>> >> > feature for XForms 1.2, with a slightly different expression.
>> >> >
>> >> > Please see the current proposal at
>> >> > http://www.w3.org/MarkUp/Forms/wiki/Submission_Embedding
>> >> >
>> >> > Briefly, we propose the new attribute submission/@target.  For
>> example,
>> >> in
>> >> > your use case of a new window in an XHTML+XForms integration, the
>> >> attribute
>> >> > value would be XHTML name "_blank" :
>> >> >
>> >> >  <submission replace="all" target="_blank" ... />
>> >> >
>> >> > As with all XForms 1.2 proposed features, we seek feedback on
>> >> experimental
>> >> > implementations.  There is already one implementation, cited in the
>> >> feature
>> >> > proposal.
>> >> >
>> >> > Please see our discussion at
>> >> >
>> http://lists.w3.org/Archives/Public/public-forms/2010May/att-0025/2010-
>> >> 05-26.html#topic5
>> >> >
>> >> > Leigh.
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >> --
>> >> This message has been scanned for viruses and
>> >> dangerous content by MailScanner, and is
>> >> believed to be clean.
>> >> --
>> >>
>> >
>> >
>> > Inventive Designers' Email Disclaimer:
>> > http://www.inventivedesigners.com/email-disclaimer
>> >
>> > --
>> > This message has been scanned for viruses and
>> > dangerous content by MailScanner, and is
>> > believed to be clean.
>> > --
>> >
>> >
>> >
>>
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content, and is believed to be clean.
>> --
>>
>>
>> ------------------------------
>> Inventive Designers' Email Disclaimer:
>> http://www.inventivedesigners.com/email-disclaimer
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content, and is believed to be clean.
>> --
>>
>>
>