Re: [xdi] $get operation helpers / enhancements

On Tue, May 22, 2012 at 10:57 PM, Michael Schwartz <mike@gluu.org> wrote:

Markus, Yuriy Z. and TC:

See inline responses

>> I'm not sure if I fully understand the implications of distinguishing between binary
>> and non-binary literals on the graph level. How do $add and $mod operations work with binaries?

If you are trying to browse a graph with 1000 pictures, your client will never return. In oxServer, we use the data URI format to specify type of the data. This enables us to return results either with or without the binaries, which was proven to be an absolute requirement for oxPlus. Note: I am suggesting this as a MAY feature, so if an XDI server wants to treat all literal values the same, that’s ok.

Makes sense I guess.. If we have 1000s of arcs coming off a context, perhaps at some point we'll also need support for paging..

- "Server MAY return $is$binary as literal value instead of binary" - Just a note on terminology here, $is$binary isn't a literal, it's an XRI. So speaking of $is$binary as a literal value is a bit confusing to me. Also, there might be ambiguous situations if somebody stores an actual $is$binary relational arc in the graph.

$is$binary is a token with special meaning. We could put anything there or nothing. The idea is that we want to be able to list a return that you have pictures 1-1000, and then the client can choose which ones to download.

I understand, but this doesn't answer the question of ambiguity. Could there be an ACTUAL $is$binary arc in the graph? Should a server try to prevent that?

- $onelevel - I still don't understand why we can't use $level$1, $level$2, ...

$onelevel is a frequent requirement for browsing trees. I think we should prioritize the use cases that are needed first, and discuss enhancements later. We don’t need $level$2 right now, and in the last 20 years of LDAP history no one has. So why don’t we wait until we see the requirement, and then propose a new enhancement for semantics to support n level of searches.

$level$1 isn't any more difficult to implement/understand/use than $onelevel. We could say that a server MUST support 1 level and MAY support arbitrary levels.

- Filtering by arc types makes sense to me. Maybe this could also be done using the syntax for variables, instead of introducing special $ words.

Please give an example. I don’t understand your suggestion.

Not quite sure, maybe something like this to only get literals..

@!1111$msg!1$do/$get/@!4444
@!4444/!/($)

- The filter _expression_ syntax looks pretty complicated, would need description to understand how it works. How does the syntax for variables fit into this? Have you looked at Giovanni's earlier work on XDI queries?

Yes, and Giovanni’s filter requires an entire xdi statement.

The syntax I suggesting is pretty simple pre-fix notation using the logical operators we already have defined: $and, $or, $not. You evaluate the parens and then combine according to the logical operator. And if we can put the filter directly in the $get operation, we don’t need variables:
  @!1111$msg!e2bdc4de-f129-4d84-9009-3572c37b04d0$do/$get($and(context=*friends*)(rel=*yuriy*))/@!4444
Using this method, we really cut down on the amount of graph that gets returned for a given request to a graph node.

If we want to support variable substitution, I think this could be pretty straight forward:

$get($and($1)($2)) ???
Would these variables definitions have to be in the same message?
Also, maybe we should support an XRI reference to a filter defined in the graph:
$get($and(xri(=mike+search1!)(xri(=mike+search2!)))

So do you still see a need for the variable syntax? E.g. ($) ?

- Mike

Markus
On Tue, May 22, 2012 at 7:31 PM, Michael Schwartz <mike@gluu.org> wrote:

XDI TC:

Continuing the discussion on filtering $get requests, please review the following proposals.

Any feedback ahead of time would also be appreciated.

- Mike

===================================
$get operation
===================================

1) Server MAY return $is$binary as literal value instead of binary

=====================================================
Filter by arc type $literal, $relational, $contextual
=====================================================

Types:

$literal, $contextual, $relational
Example 1 - returns ONLY literal xdi statements

@!1111$msg!e2bdc4de-f129-4d84-9009-3572c37b04d0$do/$get$literal/@!4444
Example 2 - returns relational and contextual xdi statements

@!1111$msg!e2bdc4de-f129-4d84-9009-3572c37b04d0$do/$get$relational$contextual/@!4444
Example 3 - NO sense filter because it returns all xdi statements, $get operation by default returns all xdi statements. Filter can be simply skipped.

@!1111$msg!e2bdc4de-f129-4d84-9009-3572c37b04d0$do/$get$relational$contextual$literal/@!4444

=======
$binary
=======

To force $get operation to return binaries.

Example:

@!1111$msg!e2bdc4de-f129-4d84-9009-3572c37b04d0$do/$get$binary/@!4444

=========
$onelevel
=========

$onelevel - returns only one level from target node of $get operation

If client wants to go deeper then 1 one level for example 2, then it should made 2 sequential calls.

Example:

@!1111$msg!e2bdc4de-f129-4d84-9009-3572c37b04d0$do/$get$onelevel/@!4444

==============================
Filter _expression_ / Evaluation
==============================

In evaluation filter only string operations can be used.

Example:

@!1111$msg!e2bdc4de-f129-4d84-9009-3572c37b04d0$do/$get($and(context=*friends*)(rel=*yuriy*))/@!4444

---------------------------------------------------------------------
To unsubscribe, e-mail: xdi-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xdi-help@lists.oasis-open.org

xdi message