Re: url params et al

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).
>
>
>
>
>



-- 
Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/

Received on Friday, 25 August 2006 20:51:59 UTC