xdi message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Digesting last XDI TC call
- From: Markus Sabadello <markus.sabadello@xdi.org>
- To: OASIS - XDI TC <xdi@lists.oasis-open.org>
- Date: Sun, 31 Mar 2013 23:36:31 +0200
So we talked about the JSONModel
I have been staring now for a pretty long time at some of the examples we came up with:
And:
=markus+email[1]/$ref/=markus+email!:uuid:3333
=markus+email[2]/$ref/=markus+email!:uuid:2222
=markus+email[3]/$ref/=markus+email!:uuid:1111
=markus!(+email)/$ref/ =markus+email!:uuid:1111
And:
=markus+address!:uuid:123+street[1]<$string>/<>/"..."
=markus+address!:uuid:123+street[2]<$string>/<>/"..."
=markus+address!:uuid:123!(+city)<$string>/<>/"..."
=markus+address!:uuid:123!(+country)<$string>/<>/"..."
=markus+address!:uuid:456<$string>/<>/"..."
And:
=sender$msg!:uuid:1234$do/$add/...
=sender$msg[1]/$ref/=sender$msg!:uuid:1234
I completely understand how they work and what were the steps we took to arrive at this, and I believe I can implement this.
BUT: It all seems very complex to me. :)
I think the biggest turn-offs for me here are:
1. There are two different ways of expressing that something is an instance of something:
1.a. +email!:uuid:1111 is an instance of an +email.
1.b. +email[1] is also an instance of an +email, and in addition it is an ordered element in an array.
1.c. But for example, =!2222!:uuid:1111 is not an instance of =!2222.
2. There are three different ways of expressing that something can have a value:
2.a. +email!:uuid:1111 can have a value, because it is an instance of something that has a + context symbol
2.b. +email[1] can have a value, because it is an instance of something that has a + context symbol
2.c. !(+email) can have a value, because it is a singleton
3. There is no clean syntax for an array/collection/group/set.
If I got this summary wrong, please let me know, but I think it is accurate.
So basically you have to consider both the context symbol, and the brackets, and several special rules, in order to understand what you're dealing with.
I feel this is just so unintuitive, and much more complicated than what we had before in the
ContextFunctions proposal.
And while I very much support the idea of 100% map-ability between JSON and XDI (for the purpose of connectors), I don't think it's a great idea to base the XDI graph model itself (and its terminology) on JSON.
So I took a step back and tried to imagine what would work.
I think my favorite thing to do now would be to move back to the general
ContextFunctions idea, with a few slight changes:
1. Pattern for root: ( )
2. Pattern for entity: (no pattern)
3. Pattern for attribute: < >
4. Pattern for value: < >
5. Pattern for collection: [ ]
6. Pattern for entity member: ! for unordered, * for ordered
7. Pattern for attribute member: <!> for unordered, <*> for ordered
Using these patterns, here are the same examples as above:
And:
=markus[+email]<*1>/$ref/=markus[+email]<!:uuid:3333>
=markus[+email]<*2>/$ref/=markus[+email]<!:uuid:2222>
=markus[+email]<*3>/$ref/=markus[+email]<!:uuid:1111>
=markus<+email>/$ref/ =markus[+email]<!:uuid:1111>
And:
=markus[+address]!:uuid:123[+street]<*1><$string>/<>/"..."
=markus[+address]!:uuid:123[+street]<*2><$string>/<>/"..."
=markus[+address]!:uuid:123<+city><$string>/<>/"..."
=markus[+address]!:uuid:123<+country><$string>/<>/"..."
=markus[+address]<!:uuid:456><$string>/<>/"..."
And:
=sender[$msg]!:uuid:1234$do/$add/...
=sender[$msg]*1/$ref/=sender[$msg]!:uuid:1234
I think this supports all the requirements we found and has much cleaner syntax than the JSONModel.
Feedback?
Markus
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]