Re: url params et al

Leigh,

you wrote:
 > - xf:*/@src (not quote * but I mean everywhere it's used)

But what should we do when having something like this?:

<xf:instance id="default" src="{instance('default')/data/foo}" />

Obviously it would be hard to evaluate the AVT in this case or can 
anyone think of a senseful way to process this?

Joern



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 
> <mailto: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 <mailto:model/@functions> [cut]
> - model/@schema <mailto:model/@schema>
> - submission/@action <mailto:submission/@action>
> - submission/@method <mailto:submission/@method>
> - submission/@version <mailto:submission/@version> [XSLT allows it on 
> output attributes and these attributes are based on XSLT output]
> - submission/@indent <mailto:submission/@indent>
> - submission/@encoding <mailto:submission/@encoding>
> - submission/@omit-xml-declaration 
> <mailto:submission/@omit-xml-declaration>
> - submission/@cdata-section-elements 
> <mailto:submission/@cdata-section-elements>
> - submission/@replace <mailto:submission/@replace>
> - submission/@separator <mailto:submission/@separator>
> - submission/@includenamespaceprefixes 
> <mailto:submission/@includenamespaceprefixes>
> - submission/@mediatype <mailto:submission/@mediatype>
> - bind/@type <mailto:bind/@type> [cut]
> - bind/@p3ptype <mailto:bind/@p3ptype> [cut]
> - xf:*/@src (not quote * but I mean everywhere it's used)
> - xf:*/@appearance
> - xf:*/@inputmode <mailto:i/@inputmode>
> - xf:*/@incremental <mailto:t/@incremental>
> - upload/@mediatype <mailto:upload/@mediatype>
> - select1/@selection <mailto:select1/@selection>
> - select/@selection <mailto:select/@selection>
> - repeat/@start <mailto:repeat/@start>
> - repeat/@end <mailto:repeat/@end>
> - repeat/@step <mailto:repeat/@step>
> - @ev:event [cut]
> - @ev:phase [cut]
> - @ev:propagate [cut]
> - (other ev:event attributes are IDREF and are cut anyway)
> - dispatch/@name <mailto:dispatch/@name>
> - dispatch/@bubbles <mailto:dispatch/@bubbles>
> - dispatch/@cancelable <mailto:dispatch/@cancelable>
> - load/@resource <mailto:load/@resource>
> - load/@show <mailto:load/@show>
> - insert/@position <mailto:insert/@position>
> - message/@level <mailto:message/@level>
> - */@xf:repeat-startindex <mailto:*/@xf:repeat-startindex> [cut?]
> - */@xf:repeat-number <mailto:*/@xf:repeat-number> [cut?]
> - repeat/@startindex <mailto:repeat/@startindex>
> - repeat/@number <mailto:repeat/@number>
> - case/@selected <mailto: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).
> 
> 
>

Received on Monday, 28 August 2006 19:15:47 UTC