Re: url params et al

Not sure what exactly the AVT would mean here --- looks like a
double-eval --- since 
src= "instance('default')/data/foo" 
presumably goes off to fetch what  is placed at data/foo? -- or
perhaps I'm making that interpretation because of the explicit
instance() call?

What I mean is,
if you just had src="data/foo" 
then you dont know  off-hand whether data/foo above is a relative
path name or an XPath expression --- and in that case
src="{data/foo}" 
makes it explicit that one should retrieve the URI value of  src
from data /foo 
so presumably data looks like:
<data>
<foo>http://www.example.com/foo</foo>
<bar>http://www.example.com/bar</bar>
</data>



Joern Turner writes:
 > 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).
 > > 
 > > 
 > > 

-- 
Best Regards,
--raman

Title:  Research Scientist      
Email:  raman@google.com
WWW:    http://emacspeak.sf.net/raman/
GTalk:  raman@google.com, tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman

Received on Monday, 28 August 2006 22:07:25 UTC