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: Updated JSON serialization rule for literal values & new graph tree serialization proposal


Per Markus' feedback below, I updated https://wiki.oasis-open.org/xdi/JSONSerializationRules to eliminate the requirement that XDI literal values be enclosed in arrays.

Also, since Joseph has suggested at least one alternative JSON serialization, and I have suggested a third one, I suggest we refer to our current JSON serialization as key-value serialization, since it emulates the structure used by a key-value store.

I would suggest that we call the other two serializations:
After talking with Joseph this morning I was inspired to work out the rules and post some examples of graph-tree serialization. I just posted this to:
To save you time, I'm pasting in both examples below so you can see what it looks like. The key (literally) is:
  • All XDI contexts are nested JSON objects (one per XDI context).
  • Relational statements originating from a context are serialized using the special member key "/":
  • A literal statement originating from a context is serialized using the special member key "&":
  • An inner graph is serialized using the special member key "()":

Examples

Non-Recursive

{
    "=drummond": {
        "[<+email>]": {
            "!1": {
                "&": "drummond@example.com"
            },
            "!2": {
                "&": "dsr@example.net"
            }
        },
        "<+email>": {
            "/": {
                "$ref": [
                    "=drummond{<+email>]!1"
                ]
            }
        },
        "+home": {
            "<+email>": {
                "/": {
                    "$ref": [
                        "=drummond{<+email>]!2"
                    ]
                }
            }
        },
        "+work": {
            "<+email>": {
                "/": {
                    "$ref": [
                        "=drummond{<+email>]!1"
                    ]
                }
            }
        },
        "/": {
            "+friend": [
                "=markus",
                "=joseph"
            ]
        }
    }
}

Recursive (Inner Graph)

This example represents a typical XDI message.

{
    "([@]!9999)": {
        "/": {
            "$set": [
                "[@]!9999[$msg]!1234"
            ]
        }
    },
    "[@]": {
        "!9999": {
            "[$msg]": {
                "!1234": {
                    "/": {
                        "$is()": [
                            "([=]!3333)"
                        ],
                        "$do": [
                            "[=]!3333$do"
                        ]
                    },
                    "<$t>": {
                        "&": "2011-04-10T22:22:22Z"
                    },
                    "$do": {
                        "/": {
                            "$set": {
                                "()": {
                                    "[=]": {
                                        "!3333": {
                                            "<+age>": {
                                                "&": 33
                                            },
                                            "[<+tel>]": {
                                                "!1": {
                                                    "&": "+1.206.555.1111"
                                                },
                                                "!2": {
                                                    "&": "+1.206.555.2222"
                                                },
                                                "/": {
                                                    "+home": [
                                                        "[=]!3333[<+tel>]!1"
                                                    ],
                                                    "+work": [
                                                        "[=]!3333[<+tel>]!2"
                                                    ],
                                                    "+work+fax": [
                                                        "[=]!3333[<+tel>]!2"
                                                    ]
                                                }
                                            }
                                        }
                                    }
                                }
                            }
                        }
                    }
                }
            }
        }
    }
}

On Wed, Apr 24, 2013 at 2:43 AM, Markus Sabadello <markus.sabadello@gmail.com> wrote:
I agree, the value of the literal should just be the native JSON type.

Markus


On Wed, Apr 24, 2013 at 9:23 AM, Drummond Reed <drummond@connect.me> wrote:
Today I updated XDI syntax on most of our major wiki pages. The revised pages include:
I still have more work to do to bring other pages current, and then move to updating our Kavi docs, especially the XDI Graph Patterns doc.

I also had a good session on the ABNF with Joseph. He is going to be driving forward with completing an updated formal ABNF proposal and then the new serialization proposal(s).

One open issue I noted at the bottom of the page when updating https://wiki.oasis-open.org/xdi/JSONSerializationRules. Now that we support JSON data types natively as XDI literals, the requirement to put all XDI objects inside JSON arrays seems outdated. 

If we are going to continue to use it as one serialization format, I suggest that only contextual and relational statements should have JSON arrays as the value. This makes sense because they can have one or more XDI objects.

For literal statements, it seems easier and more intuitive to have the value be the native JSON data type, rather than forcing that data type to be inside an array which by definition will have just one element.

Thoughts?

=Drummond 







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