Re: url params et al

Mark,

while I go with most of what you say, I don't see any use case for AVTs 
within @ref, @nodeset or MIP attributes. These are XPath expressions by 
nature, so anything expressible with AVTs is expressible without them, 
e.g. ref="{/myexpr}" can be written as ref="*[name()=/myexpr]".

Is it just to late for me and I'm missing sth obvious ?

Regards,
Uli.

Mark Birbeck wrote:
> 
> Hi Keigh,
> 
> Very thorough work! I'd like to suggest though, that the dividing line
> is not actually between whether an attribute takes an XPath expression
> or not, but is in fact determined by the point at which an expression
> is evaluated, and what happens to the results of the evaluation. As
> I'll try to show, I believe that the only place where the design of
> XForms *prevents* us from using AVTs is in model item properties--all
> other places are pretty easy.
> 
> 
> EVALUATING AT THE POINT OF USE
> 
> Let's say we agree that xf:setvalue evaluates any @ref and @value
> attributes at the point at which the action is performed. That may
> seem obvious, but I'm not sure it's clear in the spec--but let's
> pretend it is. :) If the XPath expressions are evaluated only at the
> point of use, then you could have AVTs in xf:setvalue with absolutely
> no problems. You could even have *nested* AVTs to whatever level you
> like, since its just a case of repeatedly parsing until you are left
> with no more squiggly brackets.
> 
> If we take this idea of 'evaluating at the point of use' concept, and
> regard it as a 'safe' use of AVTs, then we can see that there is
> actually no difference between these kinds of uses of AVTs:
> 
>  <xf:setvalue ref="{/myexpr}">3</xf:setvalue>
> 
>  <xf:load ref="{/myexpr}" />
> 
> and these kind:
> 
>  <xf:toggle case="{/mycase}" />
> 
>  <xf:dispatch target="{/mynode}" name="{/mytask}" />
> 
>  <xf:submission action="{/myurl}" ... />
> 
> 
> REWIRING
> 
> If we take as another example an xf:input with @ref:
> 
>  <xf:input ref="{/myexpr}">
>    <xf:label>Data</xf:label>
>  </xf:input>
> 
> things might seem to be a little trickier. However, I would argue that
> now that we have a bit more clarity in the notion of rewiring, it's
> not actually that difficult to implement--it's not much different to
> the xf:setvalue example above, since the evaluation takes place once
> and then won't change until the next rewiring. (And it's actually not
> much different to something like @ref="a[position()=../b]".)
> 
> 
> MASTER DEPENDENCY GRAPH
> 
> In fact, the only place things get tricky is when you use an AVT in
> the master dependency graph:
> 
>  <xf:bind nodeset="a" relevant="{../b} &gt; 7" />
> 
> The problem here is that if you simply store a dependent relationship
> between 'a' and 'b', you miss the fact that 'a' could also be
> dependent on 'c' or 'd'. You'd either have to say that all changes to
> 'b' cause a rebuild (not nice), or you'd have to say that the
> functionality defined in the XForms MDG needs to be extended to cope
> with rebuilding part of the graph, rather than the whole graph.
> 
> (In other words, the solution is not as simple as just adding an extra
> (intermediate) vertex, since that vertex itself needs to be
> 'reconstructed' when 'b' changes.)
> 
> 
> SUMMARY
> 
> The reason most stuff is easy is in fact because AVTs themselves are
> not difficult to implement! If you can create an XPath parser then
> what else is there to do? In terms of evaluating an expression that
> contains an AVT it's extremely easy, so provided that an expression is
> 'fire and forget' (or at least 'evaluate for now') then an AVT can be
> used.
> 
> It's only the MDG that's difficult, and as it happens that's not
> really to do with AVTs per se--it's to do with intoducing a vertex
> that needs to change as the result of a changed value, when there is
> no clear notion in the current graph functionality as to how the
> vertex should change. In other words, it's to do with the fact that
> expressions are not 'fire and forget', and dependent relationships are
> established. We'd have a similar problem if we wanted to get smarter
> about the values some functions return, like a clock, for example--the
> current MDG model wouldn't provide us with a way to do this.
> 
> 
> CONCLUSION
> 
> My conclusion would therefore be to suggest that everyone just has a
> go at implementing AVTs wherever they want! Obviously @action on
> xf:submission is one of the most useful, but I don't see any reason
> why people don't just give it a go on any attribute they feel like,
> and feed back their experiences. My feeling is that whereever there
> are problems, it won't actually be because of AVTs, but because there
> is no clear definition of when some attribute is 'used'. (For example,
> XML Events doesn't define properly when event listeners are attached,
> and that would need to be done before we could know whether AVTs are
> usable in @ev:event or not. @ev:handler would in most cases be ok,
> though.)
> 
> So, since nearly every situation in which AVTs might be used is
> actually pretty easy, I think the most useful experiences we'll get
> will be to do with the problem of xf:bind.
> 
> Regards,
> 
> Mark
> 
> 
> 
> On 25/08/06, Klotz, Leigh <Leigh.Klotz@xerox.com> 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
>> - xf:*/@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).
>>
>>
>>
>>
>>
> 
> 
> 


-- 
Ulrich Nicolas Lissé

Received on Friday, 25 August 2006 21:46:24 UTC