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: [xdi] Minutes: XDI TC Telecon Friday 2013-04-19


Markus, cool. I took a quick look across the samples and caught a few that need updates:

XDI PARSER - DEFAULT SAMPLE

=markus!<+name><<$string>>/<>/"Markus"  <== SHOULD BE =markus<+name>&/&/"Markus"

XDI VALIDATOR SAMPLE #1

()/$is$ref/(=!1111)          <== SHOULD BE ([=]!1111)
(=!1111)/$ref/()               <== SHOULD BE ([=]!1111)
=markus/+friend/=drummond
=markus<+email>&/&/"markus.sabadello@gmail.com"
=markus<+name>&/&/"Markus Sabadello"

SAME FOR XDI VALIDATOR SAMPLE #2

SAME FOR XDI MESSENGER SAMPLE #1 AND #6

SAME FOR XDI LOCAL MESSENGER - ALL SAMPLES

SAME FOR XDI GRAPHER - SAMPLE #1

XDI CONVERTER SAMPLE #4

(=!91F2.8153.F600.AE24)/$ref/()
$do$if$and/$true/({$from}/$is/=!91F2.8153.F600.AE24)
$do$if$and/$true/({$msg}$secret<$token>&/$equals/$secret<$token>&)
$do/$all/()
+friend$do$if/$true/(=!91F2.8153.F600.AE24/+friend/($from))                    <== SHOULD BE {$from}
+friend$do/$get/=!91F2.8153.F600.AE24                                                       <== SHOULD BE [=]!91F2.8153.F600.AE24
=!91F2.8153.F600.AE24$<+email>&/&/"markus.sabadello@gmail.com"
=!91F2.8153.F600.AE24/+friend/=!1111                                                      <== SHOULD BE [=]!91F2.8153.F600.AE24
=!91F2.8153.F600.AE24/+friend/=!2222                                                      <== SHOULD BE [=]!91F2.8153.F600.AE24
=markus/$ref/=!91F2.8153.F600.AE24                                                      <== SHOULD BE [=]!91F2.8153.F600.AE24
()/$is$ref/(=!91F2.8153.F600.AE24)                                                      <== SHOULD BE [=]!91F2.8153.F600.AE24

XDI CONVERTER - OTHER APPS LINK

The >>> Other Apps... link in the top right menu bar doesn't work.

SAME FOR XDI LOCAL MESSENGER - SAMPLE #4 AND OTHER APPS LINK



On Sun, Apr 21, 2013 at 3:30 PM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
Just wanted to note that the XDI2 web tools have been updated again to match the latest decisions, i.e. [ ] for classes, and & for values:

http://xdi2.projectdanube.org/

Markus


On Sun, Apr 21, 2013 at 11:19 PM, Drummond Reed <drummond.reed@xdi.org> wrote:

XDI TC Minutes


Following are the minutes of the unofficial telecon of the XDI TC at:


Date:  Friday, 19 April 2013 USA
Time:  09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)


ATTENDING


Markus Sabadello

Les Chasen

Joseph Boyle

Phil Windley

Drummond Reed


REGRETS


Animesh Chowdhury


PRESENTATIONS/DISCUSSIONS

POSSIBLE CLOSURE OF THE XRI TC

Chet Ensign has inquired whether the XRI TC is ready to be closed down and have its activities taken over by the XDI TC. All attendees on the call were in favor of this, so Drummond will proceed to work with Chet to facilitate it.


SYNTAX DEMO

Markus gave a demo of the updated syntax using the XDI2 utilities publicly available at:


  http://xdi2.projectdanube.org/


DECISION POINTS FOR THIS CALL


This week's decision queue is the following set of proposals:

SYNTAX CLOSURE


Drummond posted the final two issues to:


 https://wiki.oasis-open.org/xdi/XdiSyntaxExamples


The issues are:

  1. Recommendation to apply square bracket [ ] syntax to classes and not singletons.

  2. Decision about colon (or an alternate) for the value context.


First we discussed that we can and should use the term “arcs” for what in XRI were called subsegments, because in XDI each arc in the graph corresponds to one subsegment.


Secondly, we discussed and agreed on the proposal to switch square bracket syntax from singletons to classes for the reasons explained in the proposal:

  1. It makes singletons the default, which is more intuitive.

  2. It matches with the singular case in the English language.

  3. It removes ambiguity about whether singletons or classes should be used for specialization—singletons will be used by default.


Following are examples that Markus made during the call.


***********


Earlier syntax:

=markus+|&email:/:/".."


Joseph's syntax:

=markus+email^&:/:/".."


#### IMPLEMENTED NOW IN XDI2:


=markus[<+email>]:/:/"markus.sabadello@gmail.com"      ( attribute singleton)


=markus<+email>!1:/:/"email1"         ( attribute class with 2 instances)

=markus<+email>!2:/:/"email2"


[$do][$if][$and]...                    ( sequence of entity singletons in a policy)


#### LATEST IDEA:


=markus<+email>:/:/"markus.sabadello@gmail.com"      ( attribute singleton)


=markus[<+email>]!1:/:/"email1"         ( attribute class with 2 instances)

=markus[<+email>]!2:/:/"email2"


$do$if$and...                    ( sequence of entity singletons in a policy)


#### C AND JAVA LIKE SYNTAX:


=markus<+email>:/:/"markus.sabadello@gmail.com"      ( attribute singleton)


=markus<+email>[]!1:/:/"email1"         ( attribute class with 2 instances)

=markus<+email>[]!2:/:/"email2"


************

# DECISION: we will switch square bracket syntax to classes.


Next we discussed the context symbol character issue. Markus said he ran into parsing issues in the XDI2 implementation. He also feels it would be confusing to developers to have one syntax character that is sometimes a delimiter and sometimes not.


Drummond agreed that even though it could be dealt with in the ABNF, it would be best to use a symbol other than colon for the value context.


Joseph prefers colon because of alignment with JSON but was okay with other choices.


After a long discussion we settled on ampersand & because it partially aligns with C syntax in which it used to indicate that a variable name is a pointer to a value and not the value itself.


# DECISION: we will adopt ampersand as the value context symbol.


# DRUMMOND to update the affected wiki pages.


ABNF


With the new syntax we need to prepare the new ABNF. Drummond has done a first draft at:


https://wiki.oasis-open.org/xdi/XdiAbnf/Discussion (see the 2013-04-18 comment)


It compiles but does not yet parse XDI addresses correctly. Joseph, Markus, and Drummond did debugging session and caught the problem in the definition of xdi-chars (the syntax to exclude colons as terminating characters was incorrect).


# DRUMMOND to complete debugging of the consolidated ABNF and then ping the list.


# JOSEPH to then break it into the layered subsets that he has proposed.


$SET OPERATION


Recent discussions have produced good reasons to move forward with the $set operation that has been discussed several times in the past. See the first draft proposal at:


 https://wiki.oasis-open.org/xdi/SetOperation


Markus showed a demo of how $set would work to either add statements or modify literal values without needing to distinguish between them. Besides being simpler for developers, it also has better scalability properties—this is how most highly scalable database systems work.

Phil agreed that it would be good to have an XDI operation that would align with the semantics of SQL REPLACE.

This took us into a discussion of overall alignment between SQL, HTTP, and XDI. Standard SQL includes CREATE and UPDATE which align with $add and $mod. But MySQL adds the verb REPLACE which would correspond to $set. Markus created the table below to analyze the overall alignment.

XDI

error?

SQL

HTTP

PERL

JAVA







$add

if target exists

CREATE

PUT (not quite)

$x = "markus"

String x = "markus"

$mod

if target doesn't exist

UPDATE

PUT (not quite)

$x = "joseph"

x = "joseph"

$set

never

REPLACE, MERGE

PUT

$x = "drummond"

-

$del

never

DELETE

DELETE

(end-of-scope)

(end-of-scope)

$get

never

SELECT

GET

$x

x


We also discussed the behaviour of $del. We first defined it so that it gave an error if you tried to delete a statement that does not exist. We subsequently changed it to make $del idempotent.


HTTP REST INTERFACE

The prospect of $set aligning with HTTP PUT raised another topic we have discussed many times: an HTTP REST interface.


We agreed that the addition of a $set operation could make this easier. In an interactive discussion, Markus created the following notes about what a REST interface could look like:


 EXAMPLE XDI ENDPOINT: http://myxdi.com/xdi/

--------

 FULL-featured XDI interface:

 POST    http://myxdi.com/xdi/

 BODY:

 (XDI message envelope)

--------

 RESTful $get:

 GET     http://myxdi.com/xdi/=markus<+email>:

 HEADER:

 Xdi-Statement: {$msg}/$do/=!1111$do

 Xdi-Statement: {$msg}$oauth<$token>:/:/"abc123"

 Xdi-Sender: =!2222

 Xdi-Parameter: <$deref>:/:/true

 Xdi-Link-Contract: =!1111$do

 Authorization: Bearer abc123

--------

 RESTful $del:

 DELETE  http://myxdi.com/xdi/=markus<+email>

--------

 RESTful $set:

 PUT     http://myxdi.com/xdi/=markus<+email>:

 BODY:

 { ":": "markus.sabadellO@gmail.com" }  

--------


JSON SERIALIZATION OPTIONS

We had time to briefly review syntax options on Joseph’s proposal for an alternate JSON serialization options. There was a consensus that we can stick with single characters for


It was agreed that we should complete a full formal proposal for this format.


# JOSEPH to finish drafting this into a full proposal.


DECISION POINT QUEUE REVIEW

The decision queue stack is shown on the following three auto-generated Category pages:


 https://wiki.oasis-open.org/xdi/CategoryLastCall

 https://wiki.oasis-open.org/xdi/CategoryCurrent

 https://wiki.oasis-open.org/xdi/CategoryHighPriority


See also this list of proposals that need to be developed:


 https://wiki.oasis-open.org/xdi/XdiPendingIssues


NEXT CALL

The next call is next week at the regular time.










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