

RE: url params et al

From: John Boyer <boyerj@ca.ibm.com>
Date: Fri, 25 Aug 2006 10:46:46 -0700
To: "Klotz, Leigh" <Leigh.Klotz@xerox.com>
Cc: "Francisco Monteiro" <monterro2004@tiscali.co.uk>, "T.V Raman" <raman@google.com>, www-forms@w3.org, www-forms-request@w3.org
Message-ID: <OFF2EB4BB6.14129F6D-ON882571D5.005FF2B1-882571D5.0061B2F3@ca.ibm.com>
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


"Klotz, Leigh" <Leigh.Klotz@xerox.com> 
Sent by: www-forms-request@w3.org
08/25/2006 09:42 AM

"T.V Raman" <raman@google.com>
<www-forms@w3.org>, "Francisco Monteiro" <monterro2004@tiscali.co.uk>
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
(Reference page http://saxon.sourceforge.net/saxon7.3/changes.html).
Received on Friday, 25 August 2006 17:47:18 GMT
