What's the holdup on that official WG, anyway? Is what's in the wiki
the proposed WG scope? Seems good enough to work with. I'd bet JSON
the namespacing and query language are big enough problems that
this'll fork into at least one other spec, but that's for a WG to
investigate.
I notice that there's no explicit mention of Breno's versioning use
cases on the wiki page, though it does mention AX validate mode. That
spec will have to be updated to work with the new assertion coding at
least, yes?
--
j
On Dec 9, 2009, at 8:56 PM, Allen Tom wrote:
+1
I believe the current thinking is that JSON will be used, since it's
widely
used and is fairly compact. Obviously nothing has been specified yet
since
there's no official WG.
Allen
On 12/8/09 8:44 PM, "David Recordon" <[email protected]> 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
