W3C home > Mailing lists > Public > public-forms@w3.org > October 2008

Re: Draft minutes for 2008-10-15 F2F Virtual Day, Second Half

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Thu, 16 Oct 2008 10:26:47 -0700
Message-Id: <95BCDAF3-D77A-4AAF-ACC7-60013CD6A9E6@orbeon.com>
To: Forms WG <public-forms@w3.org>


I agree that it would be beneficial to define the functions using a  

Now if the default function namespace is XForms, wouldn't that cause  
the other standard XForms function to be unreachable unless a prefix  
is used? E.g. you could write:


but you would then have to write:


which would be a shame, as functions from the XPath 2.0 functions are  
used very frequently.

Note that I am actually asking the question, I don't have an answer at  
this point.

Also, if I remember well, Mike Kay had some interesting suggestions  
about this topic of function resolution, and maybe it would be worth  
running this by him at some point.


On Oct 16, 2008, at 4:05 AM, Mark Birbeck wrote:

> Hi everyone,
> On 10/15/08, Leigh L. Klotz, Jr. <Leigh.Klotz@xerox.com> wrote:
>> Draft minutes for  2008-10-15 F2F Virtual Day, Second Half.
>> First half of day is in IRC minutes, whose URL is included in this  
>> document.
> Wow...very impressive minutes, Leigh.
> And it sounds like it was an interesting day.
> One minor comment on the XPath function discussion; the evaluation
> context for XPath 2.0 includes a default function namespace, which is
> applied to functions that do not have a prefix. If we define this to
> be the XForms namespace, then by default authors can use XForms
> functions unprefixed. We should also provide a way for the author to
> override this.
> So, when defining the functions themselves in a specification, all
> that would need to happen is to ensure that they are defined *with*
> prefixes. It doesn't matter whether they are defined across one or ten
> specifications, as long as the prefix is always the same, they would
> be available to an XForms author for use *unprefixed*. In other words,
> we don't need to say anything about 'importing modules', etc., since
> that is all part of XPath.
> For example, in some spec we might say that there is a new function,  
> like this:
>  xf:new-func($a as xs:integer, $b as xs:boolean) as xs:integer
> This indicates that there is a function 'new-func', and that it is
> identified by the URI:
>  <http://www.w3.org/2002/xforms#new-func>
> That gives us a unique identifier for our function, and regardless of
> the context it is used in, we will always know what function we are
> talking about.
> How that function is coded up in mark-up will depend on the in-scope
> default function namespace at the time the function is called. In an
> XForms document with the 'default default', so to speak, an author can
> use the function like this:
>  @value="a + new-func( b )"
> I.e., they would not need to use the explicit prefix. Of course, an
> author could do so if they wanted to, like this:
>  @value="a + xf:new-func( b )"
> Regards,
> Mark
> -- 
> Mark Birbeck, webBackplane
> mark.birbeck@webBackplane.com
> http://webBackplane.com/mark-birbeck
> webBackplane is a trading name of Backplane Ltd. (company number
> 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
> London, EC2A 4RR)

Orbeon Forms - Web Forms for the Enterprise Done the Right Way
Received on Thursday, 16 October 2008 17:41:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:13:58 UTC