RE: url params et al

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 <mailto:i/@inputmode> 
- xf:*/@incremental <mailto:t/@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).