W3C home > Mailing lists > Public > www-forms@w3.org > September 2005

RE: Binding to nodes that do not exist

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Fri, 9 Sep 2005 15:46:16 +0100
Message-ID: <E53D5B38-EB46-4006-8C4F-F3820CC7F009@S009>
To: "'Vincent Berger'" <vincent.berger@afp.com>
Cc: <www-forms@w3.org>, <formsPlayer@yahoogroups.com>

Hi Vinzo,

> It shouldn't but it does, in fact, in my XForms Navigator (Novell, may be
> advance :)

Not really. The reason that some people are suggesting we invent a new
function to do this is because the way the if() function *should* work now
is very different to this.

> What kind of failure (error/exception ...) should occur, according to you

I'm not suggesting that you get an exception for your use of if(), but with
the mark-up you have used you should get a binding exception for passing a
string to the @ref on xf:group. The fact that you don't get a binding
exception makes me think that the if() function is not returning a string.
Let's go back to the spec:

The if() function is defined in XForms to look like this:

  string if(boolean, string, string)

This means that the input 'object' for the 2nd and 3rd parameters should
either be a string, or it will be *converted* to a string using clearly
defined rules. These conversion rules are actually defined by the XPath
spec, and not by XForms. It means that this, for example:

  if(x, /null, .)

is equivalent to this:

  if(x, string(/null), string(.))

However, whatever it is that you pass in, the returned value is currently
defined by the XForms specification to always return a string.

Your original suggestion was to use a xf:group with a @ref set like this:

  <xf:group ref="if(string-length(name(/path/to/the/node)) > 0, /null, .)">

Since your call to if() will *always* give a string to the @ref, never a
node, then really this should give a binding exception. What you have done
is like doing this:

  <xf:group ref="'I am a string'">

which would also give a binding exception.

The problem going forward is that if() has been defined to have a certain
type of behaviour. If we redefined if() like this:

  object if(boolean, object, object)

It would not be backwards compatible with the current behaviour. To get the
current behaviour you would have to do this:

  if(test, string(a), string(b))

Now, that may not be a big deal, and certainly if any other implementations
have implemented this wrongly then there may be an argument for saying let's
just change if(). But as things stand, the behaviour you describe sounds
like it is wrong.



Mark Birbeck
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
Received on Friday, 9 September 2005 14:46:51 UTC

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