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

Re: url params et al

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Fri, 25 Aug 2006 12:09:38 -0700
Message-ID: <44EF4AF2.2060706@orbeon.com>
To: www-forms@w3.org


Good job! Clearly following XSLT 2.0 is the way to go.

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

Of course use cases include any situation where you must produce
output that must contain "{" in attributes! In particular, using XSLT
to produce an XForms page that contains VATs ;-)

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

I think this is just in line with the fact that XSLT does not provide
the ability to dynamically evaluate XPath expressions. However, all
vendors provides an evaluate() function, and IIRC (but don't quote me
on this) Mike Kay didn't see why XSLT wouldn't standardize evaluate().

I would say that if you support something like evaluate(), then you
may also support AVTs for XPath expressions. But for XForms, you
would not mandate this, in the same way that XSLT does not.

 > 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 don't have time to analyze all this right now, but I just scanned
it. BTW you have lots of "mailto:" links for all those attributes, I
don't know why.

 > I'm sure we can whittle this list down more if necesssary and still have
 > something valuable.
 > - model/@schema

When would you evaluate that? I would say this is a cut.

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

Yes to all of those I guess. You can define that they are evaluated at
some step 0 when submission takes place.

 > - bind/@type
 > - bind/@p3ptype
 > - xf:*/@src (not quote * but I mean everywhere it's used)

I think @src is deprecated in 1.1 (well, moved to the host language),
so we could forget about it.

 > - xf:*/@appearance
 > - xf:*/@inputmode
 > - xf:*/@incremental
 > - upload/@mediatype
 > - select1/@selection
 > - select/@selection
 > - repeat/@start
 > - repeat/@end
 > - repeat/@step
 > - dispatch/@name
 > - dispatch/@bubbles
 > - dispatch/@cancelable
 > - load/@resource
 > - load/@show
 > - insert/@position
 > - message/@level
 > - repeat/@startindex
 > - repeat/@number
 > - case/@selected

Anything in the UI that is not related to events is in general a no
brainer, because you can reevaluate AVTs when all the other bindings
are reevaluated, that is during refresh.

A good start!

Received on Friday, 25 August 2006 19:09:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:18 UTC