W3C home > Mailing lists > Public > www-forms@w3.org > August 2006

RE: url params et al

From: Klotz, Leigh <Leigh.Klotz@xerox.com>
Date: Mon, 28 Aug 2006 16:16:43 -0700
Message-ID: <E254B0A7E0268949ABFE5EA97B7D0CF402264647@usa7061ms01.na.xerox.net>
To: <mark.birbeck@x-port.net>, <www-forms@w3.org>

For the record, I'm not opposed to Mark's proposed process...I just want
to have a process so we can follow it when we add new attributes in
later versions.  I propose the XSLT 2.0 rules, but surely it's possible
to work out others.  For example, the XSLT rules would not allow
toggle/@case because it's an IDREF.  Clearly that is of value, but we
have to weigh the cost of the rules against the value of the result.
Leigh. 

-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
Behalf Of Mark Birbeck
Sent: Monday, August 28, 2006 4:08 PM
To: www-forms@w3.org
Subject: Re: url params et al


Hi Raman,

> What I mean is,
> if you just had src="data/foo"
> then you dont know  off-hand whether data/foo above is a relative
> path name or an XPath expression --- and in that case
> src="{data/foo}"
> makes it explicit that one should retrieve the URI value of  src
> from data /foo
> so presumably data looks like:
> <data>
> <foo>http://www.example.com/foo</foo>
> <bar>http://www.example.com/bar</bar>
> </data>

That's right, but I think the 'guts' of Joern's example is that the
XPath expression you're flagging up is on an @src attribute which is
on an instance element...and it's this instance that is referred to in
the XPath expression! It takes you through the looking-glass, a
little...

But this is why I made the point in my previous post about there being
no easy rule to divide up those attributes that can have AVTs and
those that can't. Leigh suggested dividing attributes into those that
take XPath expressions and those that don't, but there are plenty of
attributes that take XPath expressions that are easy-peasy to work out
how an AVT would behave, and there are attributes that _don't_ take
XPath expressions for which it's pretty damn difficult to work out how
they behave--@src being one of them.

The key thing is to get a handle on their point of evaluation, and
then it should be reasonably straightforward to work this out. One way
to approach this is to start with something like the document load
event as our cut-off point for "AVT processing", and then if it's
possible to use AVTs before that, great, but at least we have a
reasonable starting-point.

So to kick things off, I propose that AVTs cannot be used in any
attribute that is evaluated *before* the DOM 'load' event. Anyone care
to raise? :)

To clarify, that would mean that in this initial proposal, AVTs
couldn't be used in any @src attribute in an XHTML document, so that's
not just xf:instance/@src, but img/@src too. But they _could_ be used
in a/@href, xf:toggle/@case and xf:setvalue/@ref.

Regards,

Mark


On 28/08/06, T.V Raman <raman@google.com> wrote:
>
>
> Not sure what exactly the AVT would mean here --- looks like a
> double-eval --- since
> src= "instance('default')/data/foo"
> presumably goes off to fetch what  is placed at data/foo? -- or
> perhaps I'm making that interpretation because of the explicit
> instance() call?
>
>
>
>
> Joern Turner writes:
>  > 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).
>  > >
>  > >
>  > >
>
> --
> Best Regards,
> --raman
>
> Title:  Research Scientist
> Email:  raman@google.com
> WWW:    http://emacspeak.sf.net/raman/
> GTalk:  raman@google.com, tv.raman.tv@gmail.com
> PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
> Google: tv+raman
>
>
>
>


-- 
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 Monday, 28 August 2006 23:17:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:06 GMT