Re: json query language (fwd)

[Michael Schwartz <mike@gluu.org>]

Below is a more thoughtful analysis from Yuriy Zabrovarnyy of the 
suggestion to adopt an json-path like approach to XDI. With one comment 
by me...

- Mike


---------- Forwarded message ----------
Date: Mon, 19 Mar 2012 14:56:30 +0200
From: Yuriy Zabrovarnyy <yzabrovarniy@gmail.com>
To: Michael Schwartz <mike@gluu.org>
Subject: Re: json query language

Hi Mike,

Here are some thoughts which we may discuss.

1. MEMORY
Main problem of xpath (for xml) or json-path (for json) is that both needs
whole object model in memory.

In general xml parsers are tree based (Document object model) and stream
based (SAX).
Look to the most popular xpath java implementation, jaxen (
http://jaxen.codehaus.org/),
it supports only tree based parsers DOM, XOM, dom4j, jdom.
In theory it should be possible to have SAX based xpath but nobody made it.
(There is project started saxpath.org but no real implementation.)

Parsing to a DOM requires around 10-15 times the amount of memory as the
XML document requires disk space.
For example, a 1 megabyte XML document will parse into a DOM taking up
10-15 megabytes of memory.

2. NAVIGATION

In xpath it's possible to navigate in xml document: select ancestor,
descendant, root. I think it doesn't fit into XDI spirit.
How link contract concept should work with this? In $get operation we
specify exact operation target (address of node) and there is
no way to read information which is above. In XDI query we shouldn't use
navigation "UP" at all (only "DOWN").

3. FILTERING

I think we need not navigation (like xpaht)  but "smart" filtering.

3.1 XDI SPECIFIC FILTERING

In XDI query we need smart filtering of $get response.

* Arc
Whether to return contextual, literal or relational arcs.

* Depth
How deep we go from target of $get operation.

* Follow
Whether or not to resolve relational arcs target. Keep in mind example 
with posts that have reference to author. Here a big problem is that in 
99% percent, to query target of relational arc, another link contract is 
needed then for original the operation.

** Mike's note: In LDAP the "follow referral" the only time I've seen 
follow-referrals used is to re-direct write operations sent to an LDAP 
consumer to the master. It seems unusual to have a request trigger off a 
stream of backend Internet requests... then the server becomes more like a 
proxy.

3.2 EXPRESSIONS

We can use expression for filtering. However for this we need to extend XDI
Graph Model. We need to introduce literal value types.

Think about LDAP. In order to evaluate expression e.g. a>18 "a" should be 
decimal. In oxServer all values are string, so we can implement any string 
operation (e.g. *str*, =) but NOT compare or boolean operations.

Thanks,
Yuriy Z

On Sat, Mar 17, 2012 at 8:27 PM, Michael Schwartz <mike@gluu.org> wrote:

> Yuriy,
>
> I don't think the XPATH approach will work, because we don't have the
> graph until we execute the query... at that point, when the graph is
> returned from the request... perhaps you could use the XPATH approach...
> Anyway, give it some thought if you can, because if we can use something
> from Craig Burton's suggestion, that will help us get him on our side.
>
> - Mike
>
>
> ------------------------------**---------------------
>
> Michael Schwartz
> Gluu
> Founder / CEO
> mike@gluu.org
> +1 646-810-8761