OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: json query language (fwd)

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.

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


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").


I think we need not navigation (like xpaht)  but "smart" 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.


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.

Yuriy Z

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


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
Founder / CEO
+1 646-810-8761

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]