[Versa] statements function

[Uche Ogbuji]

On Thu, 2005-09-15 at 13:09 -0600, Michael Olson wrote:
> >
> >> We still have the same problems with the "statement" function though.
> >
> > I don't think we should play games with argument-passing semantics for
> > any function.  All function invocations should evaluate the expression
> > provided for the argument, and pass the result.
> >
> 
> I guess I don't see it as playing games, but defining what a filter  
> expression means.  To me it is intended that a filter expression will  
> have a different meaning the a pattern-expression, that's why I  
> separated them.  Regardless of where it is located in a query
> 
> . < 18
> 
> to me means that it is working against a current context (that damn  
> word again) node to evaluate, which further implies that where ever it  
> is located it cannot be evaluated until the previous portions of the  
> expression are evaluated.

What makes that a filter expression?  The fact that it has a dot in it?
Is 10 > 18 a filter expression?

> This holds for the traverse operator.
> 
> Maybe it is as simple as saying
> 
> "in a traverse operator, . < 18 is short hand for (!x : $x < 18)"

Actually, we've been discussing

{. < 18}

That's short enough for me.  We don't need to (IMO) confuse things by
allowing a form without the syntax help ({} in this case).

> Then, what I have been calling operator expressions can be promoted to  
> be used else where, and they are evaluated like other expressions so  
> you have
> 
> all() |- ns:age -> . < 18

Again, this is a syntactic construct, and I think it *would* be OK for .
< 18 here to be treated as a predicate (as it was in Versa 1.0)

However, I'm also fine making people write

all() |- ns:age -> . { < 18 }

> translates to all resources over the age of 18 (based on what I said  
> above)
> 
> and
> 
> statements(all(),ns:age,. < 18)
> 
> translates to the empty set because "." has no meaning (unless this  
> query is within another query that defines dot but let's ignore that  
> case for now).

Sure it has a meaning.  Like in XPath, any query can have a context
object.  Again, I'm thinking of query composition.  If the user doesn't
pass in a context object, we should define a default, such as empty
list.


> and to get the same results as the filter operator you would need to do
> 
> statements(all(),ns:age,(!x : $x < 18))
> 
> I think I'm OK with this.

Again

statements(all(), ns:age, {. < 18})


-- 
Uche Ogbuji                               Fourthought, Inc.
http://uche.ogbuji.net                    http://fourthought.com
http://copia.ogbuji.net                   http://4Suite.org
Use CSS to display XML, part 2 - http://www-128.ibm.com/developerworks/edu/x-dw-x-xmlcss2-i.html
XML Output with 4Suite & Amara - http://www.xml.com/pub/a/2005/04/20/py-xml.html
Use XSLT to prepare XML for import into OpenOffice Calc - http://www.ibm.com/developerworks/xml/library/x-oocalc/
Schema standardization for top-down semantic transparency - http://www-128.ibm.com/developerworks/xml/library/x-think31.html