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 parse tree example Re: [xdi] Agenda: XDI TC Telecon Friday 09:00 - 10:30AM PT 2013-04-05


Yes I've also been wondering about the <<>>.

To me it's two separate syntax items, but that's because I'm stilling thinking in the "old" XRI/segment/subsegment/xref terms.
With the more modern ABNF approach we are taking now, it might be more appropriate to just consider it a single syntax item.

Orthogonal to that, whether you write "<>" or just "<" doesn't make a big difference I think, just a matter of taste.
I chose to write "<>" simply because I felt it emphasizes that it's a context function rather than a context symbol.

I think both this format and the previous XDI/JSON format have value, depending on the use case.

Markus

On Mon, Apr 8, 2013 at 3:32 PM, Joseph Boyle <planetwork@josephboyle.net> wrote:
Looks great! Maybe I should just try writing client code expecting this format from the server, instead of writing _javascript_ to parse Display Format.

The object (3rd member of the triple - how do we distinguish this from JSON {} and other kinds of objects?) "markus.sabadello@gmail.com" is a plain JSON value which seems right to me.

The <<>> operator is represented as {"<>":{"<>":{ while I was thinking {"<":{"<":{ or maybe {"<<":{ if it is a single operator, though ideally I wish we could avoid needing double-character operators. I didn't get Drummond's mail, so maybe I'm behind on the latest syntax.

JSON.stringify appears to take an indent argument where a number means to use that many spaces, and a string means to use the string itself as the indent. Not sure if there is a standard for display  though http://www.freeformatter.com/json-formatter.html defaults to 3 spaces.

JSON.stringify with no extra arguments is what _javascript_ code would likely use to serialize a graph to upload to the server. Not sure yet if it has any quirks we need to know about http://freshbrewedcode.com/jimcowart/2013/01/29/what-you-might-not-know-about-json-stringify/

On Apr 8, 2013, at 1:41 AM, Markus Sabadello <markus.sabadello@gmail.com> wrote:

I did an experimental implementation of this.

1. Go to http://xdi2.projectdanube.org/XDIConverter?sample=1
2. Select XDI/JSON/GOM in the "to" drop down box.
3. Turn on "pretty=1"
4. Click Go.

Markus

On Sun, Apr 7, 2013 at 2:11 AM, Joseph Boyle <planetwork@josephboyle.net> wrote:
Thanks Phil - I've written it up in https://wiki.oasis-open.org/xdi/JSONSerializationRules/Discussion for further scrutiny.

I've included recently discussed terminology revisions like segment => address (some still under discussion)

On Apr 6, 2013, at 3:34 PM, Phil Windley <phil@windley.org> wrote:

Like. 

On Apr 5, 2013, at 10:08 AM, Joseph Boyle <planetwork@josephboyle.net> wrote:

This is an example of the kind of parse tree I naturally get from _javascript_ code I'm writing to parse XDI.
It is probably similar to the Java data structures Markus's XDI2 creates from parsing XDI.

If we can simply JSON-serialize a parse tree that is convenient for programmers, then they can simply JSON-deserialize and use it without more complicated parsing steps.


On Apr 4, 2013, at 11:33 PM, Drummond Reed <drummond.reed@xdi.org> wrote:

JSON SERIALIZATION OPTIONS

Today (Thursday) Joseph and Drummond were able to meet and go over new options for the JSON serialization that could be more “developer friendly” by not requiring parsing of the subject/predicate keys in order to build an XDI graph object model (GOM).
Joseph will present an example of what the GOM could look like an how to serialize it.


=drummond<+email>!uuid:f81d4fae-7dec-11d0-a765-00a0c91e0001<<$string>>/<>/


Version 1:  Separate context symbol and identifier

Compact: [[{"cs":"=","id":"drummond"},{"cs":"<","id":{"cs":"+","id":"email"}},{"cs":"!","id":"uuid:f81d4fae-7dec-11d0-a765-00a0c91e0001"},{"cs":"<<","id":{"cs":"$","id":"string"}}],{"cs":"<","id":""},"dsr@ex1.com"]

Formatted:
[
   [
      {
         "cs":"=",
         "id":"drummond"
      },
      {
         "cs":"<",
         "id":{
            "cs":"+",
            "id":"email"
         }
      },
      {
         "cs":"!",
         "id":"uuid:f81d4fae-7dec-11d0-a765-00a0c91e0001"
      },
      {
         "cs":"<<",
         "id":{
            "cs":"$",
            "id":"string"
         }
      }
   ],
   {
      "cs":"<",
      "id":""
   },
   "dsr@ex1.com"
]

Version 2: Bottom-level context symbol - identifier sequence left in one string. Context functions still (usually>) require separate object.

Compact: [["=drummond",{"cs":"<","id":"+email"},"!uuid:f81d4fae-7dec-11d0-a765-00a0c91e0001",{"cs":"<<","id":"$string"}],{"cs":"<"},"dsr@ex1.com"]

Formatted:
[
   [
      "=drummond",
      {
         "cs":"<",
         "id":"+email"
      },
      "!uuid:f81d4fae-7dec-11d0-a765-00a0c91e0001",
      {
         "cs":"<<",
         "id":"$string"
      }
   ],
   {
      "cs":"<"
   },
   "dsr@ex1.com"
]














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