[Versa] Versa issue: subgraph primitives?

[Uche Ogbuji]

On Sun, 2005-09-04 at 13:45 -0400, Chimezie Ogbuji wrote:
> > issue.  One very useful result would be that we now have a host variable
> > binding mechanism: the host system can read variables set by the query,
> > rather than just slicing at the big hairball of results.
> 
> This would be very useful, and would probably eliminate most of the
> result fragment magic (/List/String, etc..) done currently when  XSLT
> is the host language.

Yes.  I think this is the #1 pain I have seen in working with Versa in
practice.

I do think we need some sort of host variable binding, but it's a very
tough matter because it would be nice to keep the language free of
side-effects within expressions.  That's actually the consideration that
first spurred me to consider the semicolon-separated definitions idea.


>  > In other words, I don't think we should have subgraph definitions unless
> > we also have variable , namespace, etc. definitions.  I see them all as
> > context-setting operations.
> > 
> > But maybe it's worth defining a small, nonnormative host language,
> > either in text or in XML, that allows for context-setting operations.
> 
> I can see the value in making the query language (and grammer) much
> simpler, but I can also see the value in not relying on a host
> language that is so verbose that it works against Versa's concise
> syntax (like XSLT or any XML-based host language - as RIL once was).
> So, I'm inclined to think a text based host language is preferable,

nod

> and there wouldn't be any harm in making it seperate from Versa.  I
> can easily imagine use cases for namespace and variable definitions
> (these are standard for XQuery and SPARQL - namespace definition only
> tho) but function definitions (within the query language) twist my
> head.  I would prefer to implement them as extension functions in
> whichever language and allow the extension mechanism to invoke them.

The idea would be to simplify some operations within Versa itself.  I
think it's such an important need that every time you end up trying to
do without it you end up deciding you need it after all.

A good example is XPath/XSLT.  Started with no means within the language
to define extension functions, and we ended up needing the EXSLT
functions module, which I've found almost indispensable in the end.

Did you find the example function def above confusing?


> As for the context-switching syntax, I'm also trying to imagine how
> that would work.  It would definately (if all the kinks are ironed
> out) be a incredible performance tuning tool for context-aware RDF
> datastores.  I would be inclined to move this to a seperate host
> language as well, as long as it was as concise and accessible enough
> so I wouldn't have to do what I had been doing before (rely heavily on
> scope and scoped-subquery) to do that kind of thing.

I'm fine with that.  I don't like the proposed { context } query,
because I think it's a bit of a hacked special case.  I'd prefer to be
sure we have a more general solution, or just leave it out of Versa
altogether.

FWIW, I definitely agree that a default host would be best as text,
which meets your "concise and accessible" test.


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