Re: url params et al

Joern, you are right. I suspect that anything that takes place before 
the initialization of the models is complete should not support AVTs. 
This means in particular that the source for schemas and instances 
cannot be determined with AVTs.

-Erik

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


-- 
Orbeon - XForms Everywhere:
http://www.orbeon.com/blog/

Received on Monday, 28 August 2006 20:30:25 UTC