My first thought is +1, but what's the mechanism so "Each attribute
property schema is bound to a unique attribute-type namespace, can be
described by a standard key string (does not need to be defined
through a URL value)."?
Any thoughts on a query language? CouchDB views would work, but I'm
loath to do that. Same goes for W3C SPARQL-JSON stuff, Jaql. JSONPath
doesn't really map to the problem. JSONQuery would do the trick, but
it's got a bunch of stuff that AX doesn't need. Maybe JSON Schema or a
profile?
These all seem way too complicated, and at least XML has common
implementations of this stuff.
--
j
On Dec 8, 2009, at 10:44 PM, David Recordon wrote:
I'd prefer that we use the JSON structure defined in Portable Contacts
which is also now being used by OpenSocial.
http://portablecontacts.net/
--David
On Tue, Dec 8, 2009 at 8:42 PM, Joseph A Holsten
<[email protected]> wrote:
What is the thinking about that serialization format? I note the
wiki page
doesn't mention anything. XML, JSON with some namespacing,
something custom
and or backwards compatible?
When you request attributes, would you normally expect the objects in
standard types?
as in "I want an email address" -> {"email": "[email protected]",
"verification-timestamp": "2009-12-08"}
Or should you be able to request subattributes?
"I want an email address including a timestamp and method of
verification"
-> ...
Seems like asking for subattributes would be nifty, but quite nasty
to spec.
I sure can't think of any existing way to do this short of SPARQL
or some
NOSQL query language.
--
j
On Dec 8, 2009, at 7:59 PM, Allen Tom wrote:
I think the more general idea for AX 2.0 is to define a way for
structured
data (aka objects) to be shared. This might conflict with the goal
of
making
the messages compact.
At least with the case of email address, we'd like a way to return
the
email
address, as well as attributes about the address. Ideally, we'd
make this
mechanism generic so that any attribute can have metadata
associated with
it.
Allen
The spec would need to require the colons, and probably permit
empty
strings in place of the numbers when an OP wanted to say nothing
at all
about validation, e.g.
openid.ax.d.c=::+1-555-555-1212
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
