Re: url params et al

Well done Francisco!

You are the first to spot my deliberate Monday morning mistake ;-)

  I actually mean't <xforms:output value="something"/>

Thanks.

Mark

On 28 Aug 2006, at 09:30, Francisco Monteiro wrote:

> Mark,
>
> <a href="{someXPath}"><xforms:setvalue value="someXPath"/></a>
>
> Where in the spec it says you can use setvalue like this?
>
> Francisco
>
> From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On  
> Behalf Of Mark Seaborne
> Sent: 28 August 2006 08:52
> To: Leigh; www-forms
> Subject: Re: url params et al
>
> Leigh,
>
> This is a great first step towards answering John's questions.
>
> Could I also ask the XForms WG to encourage working groups who own  
> host languages (esp. HTML) to think about allowing AVTs from XForms  
> at appropriate points in their languages too. For example at the  
> moment I can do this:
>
> <a href="someurl"><xforms:setvalue value="someXPath"/></a>
>
> but it would also be useful to be able to do this:
>
> <a href="{someXPath}"><xforms:setvalue value="someXPath"/></a>
>
> If the host language is happy to allow me to use XForms to modify  
> the content of an element, it seems a strange oversight that I  
> cannot do the same for an attribute.
>
> All the best
>
> Mark
>
>
> On 25 Aug 2006, at 19:14, Klotz, Leigh wrote:
>
>> I think many implementations have AVT-like strings already, and  
>> we're already getting experience with them outside of the XForms  
>> 1.1 recommendation draft.
>> This message is an effort to herd them without going to ether  
>> extreme of putting it into the WD today or "asking" the  
>> implementations to take them out.
>> I believe that XSLT 2.0 is a good place to start looking and  
>> personally I'd like to encourage vendors to look there.
>> Nesting:
>> Nesting is prohibited in XSLT 2.0, and I think the XForms vendors  
>> should do the same.
>> Quoting:
>> Another point related to nesting is quoting.
>> It appears that XSLT 2.0 does this with double braces; so you use  
>> "{{" instead of "{" to quote them, not backslash or entity  
>> definitions (which wouldn't work of course).
>> The main use case for quoting mentioned in Kay's book is regular  
>> expressions, but as XForms doesn't have bind/@pattern anyway, that  
>> one won't be encountered.
>> bind attributes:
>> If vendors follow XSLT 2.0's rules, then there won't be any in  
>> bind nodeset or calculate, because those are XPath expressions,  
>> and they aren't allowed there.
>> I don't know if the vendors who have implemented AVT or AVT-like  
>> constructs already agree on this point, but now would be a good  
>> time to speak up.
>> So, if we apply Kay's description of XSLT 2.0's rules, here's the  
>> attributes from the recently-posted XForms 1.1 Schema that I find  
>> make the first and second cut.
>> Second cut applies the first rule (i.e., attributes must be  
>> explicltly listed in the spec) and is noted after the attribute.
>> First cut: XForms 1.1 attributes that aren't XPath or IDREF
>> Second cut: attributes that appear problematic for structral  
>> reasons, a criterion mention in Kay's book and in John's message  
>> as well.
>> Third cut: Ones I'm not sure about; this is just the repeat  
>> attributes, which I don't understand anyway.
>> I'm sure we can whittle this list down more if necesssary and  
>> still have something valuable.
>> - model/@functions [cut]
>> - model/@schema
>> - submission/@action
>> - submission/@method
>> - submission/@version [XSLT allows it on output attributes and  
>> these attributes are based on XSLT output]
>> - submission/@indent
>> - submission/@encoding
>> - submission/@omit-xml-declaration
>> - submission/@cdata-section-elements
>> - submission/@replace
>> - submission/@separator
>> - submission/@includenamespaceprefixes
>> - submission/@mediatype
>> - bind/@type [cut]
>> - bind/@p3ptype [cut]
>> - xf:*/@src (not quote * but I mean everywhere it's used)
>> - xf:*/@appearance
>> - xf:*/@inputmode
>> - xf:*/@incremental
>> - upload/@mediatype
>> - select1/@selection
>> - select/@selection
>> - repeat/@start
>> - repeat/@end
>> - repeat/@step
>> - @ev:event [cut]
>> - @ev:phase [cut]
>> - @ev:propagate [cut]
>> - (other ev:event attributes are IDREF and are cut anyway)
>> - dispatch/@name
>> - dispatch/@bubbles
>> - dispatch/@cancelable
>> - load/@resource
>> - load/@show
>> - insert/@position
>> - message/@level
>> - */@xf:repeat-startindex [cut?]
>> - */@xf:repeat-number [cut?]
>> - repeat/@startindex
>> - repeat/@number
>> - case/@selected
>> Leigh.
>>
>> From: John Boyer [mailto:boyerj@ca.ibm.com]
>> Sent: Friday, August 25, 2006 10:47 AM
>> To: Klotz, Leigh
>> Cc: Francisco Monteiro; T.V Raman; www-forms@w3.org; www-forms- 
>> request@w3.org
>> Subject: RE: url params et al
>>
>>
>> That's good. One of the questions I felt we needed someone to  
>> research before going with AVTs was the question of iteration,  
>> i.e. if the result contains braces, do you reevaluate? Seems like  
>> one could create all kinds of Lisp-like constructs if so, but  
>> despite that was a minefield of complexity I was hoping we could  
>> avoid. Based on not even being able to nest them, I would say that  
>> iteration is out.
>>
>> That still leaves lots of process questions regarding their  
>> general availability. We do need experience over time with the  
>> feature because the common use cases are unlikely to break (which  
>> explains why "no one seems to be having a problem with them").  
>> Aside from the spec work we would need in the form of schema  
>> changes, it would be very helpful to have an explanation of why  
>> AVTs would pose no problem when use in the attributes of a bind  
>> element, like nodeset or calculate, for example. Would they be  
>> problematic when used in single node binding, nodeset binding  
>> attributes, and the special attributes of each element?
>>
>> A good example would be upload with a filename child element. If  
>> upload or filename ref contains an AVT that is dependent somehow  
>> on a change that would be made by the other element, , what happens?
>>
>> Based on these, I'm sure there are issues that must be worked out  
>> through full analysis of the language that may take a while to  
>> come up otherwise. It may not take tons of time to do the  
>> analysis, we just need someone to do it because it's not really a  
>> feature but rather an enhancement to pretty much all the features  
>> of the language.
>>
>> John M. Boyer, Ph.D.
>> Senior Product Architect/Research Scientist
>> Co-Chair, W3C XForms Working Group
>> Workplace, Portal and Collaboration Software
>> IBM Victoria Software Lab
>> E-Mail: boyerj@ca.ibm.com http://www.ibm.com/software/
>>
>> Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
>>
>>
>>
>>
>> "Klotz, Leigh" <Leigh.Klotz@xerox.com>
>> Sent by: www-forms-request@w3.org
>> 08/25/2006 09:42 AM
>>
>> To
>> "T.V Raman" <raman@google.com>
>> cc
>> <www-forms@w3.org>, "Francisco Monteiro" <monterro2004@tiscali.co.uk>
>> Subject
>> RE: url params et al
>>
>>
>>
>>
>>
>>
>> I looked at XSLT 2.0 in Michael Kay's book, and the the decision  
>> critera
>> for where AVTs work in XSLT 2.0.
>> As I remember it, the decision critera were as follows:
>> - attributes must be specifically identified
>> - must not be of type IDREF
>> - must not not be XPath expressions
>>
>> For the full text, which is about a page, please see ISBN:  
>> 0-7645-6909-0
>>
>> Also, rather than using a first-nodeset rule, they use concatenation
>> with a single space between, though if you set compatibility mode to
>> XSLT 1.0, they use a single node.
>>
>> AVTs cannot be nested, but Kay's book gives an example using  
>> concat of
>> how to achieve certain desired effects.
>>
>> There also appears to be some hair associated with call-template, as
>> Kay's Saxon processor provides a saxon:allow-avt attribute as an
>> extension.
>> (Reference page http://saxon.sourceforge.net/saxon7.3/changes.html).
>>
>>
>>
>