[Versa] Versa issue: subgraph primitives?

[Michael Olson]

> I think we need to generalize this considerably.
>
> I've given myself a while to think about the interlocking bits of
> context, subexpressions, subgraphs, functions, etc.  For this  
> particular
> case, I think it's a matter of allowing general context definition as
> part of a query.
>
> Here's an idea that I've thought out in the mechanics, but am still
> considering in substance:
>
> * A query comprises zero or more definitions followed by one expression
>
> A definition is one of the following:
>
> 1) A namespace declaration, e.g.
>
> xmlns dc: http://purl.org/dc/elements/1.1/;
>
> 2) A variable assignment, e.g.
>
> docs = all() |- dc:title -> *;
>
> 3) A function defn, e.g.:
>
> tagmatch(doc, tag): contains($doc - dc:subject -> *, $tag)  ;
>

The first two we came up with independently (I assmue) and I like the  
addition of the third.

> 4) A subgraph definition:
>
> subgraph: join(statements($docs, *, *), statements($authors, *, *));
>
> I'm especially not set on the syntax of (1) or (4).
>

I'm not sure I like the 4th.  I think I like the form

query:== { query } query-expression

for expressing sub graphs better.

> Definitions are read from left to right (they always end with a
> semicolon).  The query starts with the context provided by the host
> system, and each definition can modify this context.  This means that  
> we
> now have side effects with respect to context, but since there are no
> flow of control constructs, I don't think this presents much of an
> 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.
>
> The problem is that leaving this sort of thing to the host system, as  
> we
> did for Versa ~1.0 simplifies the language greatly, which is a good
> thing.  I think that we should consider doing the same for Versa 2.0,
> but if so, I think that all (1) through (4) of the above should be
> treated this way.
>
> 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.
>


So WRT to variables, functions and namespaces I think we are on the  
same page.

WRT scope as I called it in the spec you think there should be a  
declaration of the form

"subgraph:" query

and I think that we should specify it as (not query-expression is just  
what a query used to be in the ENBF)

('{' query '}')? query-expression


> But maybe it's worth defining a small, nonnormative host language,
> either in text or in XML, that allows for context-setting operations.
>

I don't know if there is too much to be gained from this.  the work to  
define and implement this language (cross platform) is probably much  
greater then having each language just do it them selves.

Mike

>
> --  
> 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
>
------------------------------------------------------------------------ 
-----------------
Mike Olson                                                Principal  
Consultant
mike.olson at fourthought.com                +1 720 253 4662
Fourthought, Inc.                                       
http://Fourthought.com
PO Box 270590,                                       http://4Suite.org
Louisville, CO 80027-5009, USA
XML strategy, XML tools, knowledge management