W3C home > Mailing lists > Public > public-xg-webid@w3.org > January 2012

Re: WebIDRealm RDFa

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Wed, 04 Jan 2012 19:09:16 -0500
Message-ID: <4F04EA2C.8050306@openlinksw.com>
To: Henry Story <henry.story@bblfish.net>
CC: public-xg-webid@w3.org
On 1/4/12 6:58 PM, Henry Story wrote:
> Well a good way to help people who are new join, is to have test suites they can try out their endpoints out on, to automate the job we are doing. Then things will play themselves out even faster!

Er.. I've done many iterations of that with more complex standards than 

ODBC, JDBC, OLE-DB, ADO.NET, SQL etc.. all have test suites, tracers etc..

> I am not sure if you follow the BrowserId work, but I can tell you that they are working on their test cases.

We've long implemented BrowserID. Its even part of our HTML based Cert. 

>> >  
>>> >>    It's simpler than OpenId, but as we are moving to security space, things just are more complicated.
>>> >>  
>> >  
>> >  I haven't inferred anything about OpenID vs WebID.
>> >  
>> >  OpenID is good for WebID, they are mutually beneficial in the real world. Same applies to OAuth.
> yes, but OpenId has even more places things can go wrong. WebId is simpler than OpenId, but not so simple we
> can do without tests.

I am really not trying to trigger a WebID vs OpenID vs anything else re. 
my comments.

> But anyway, clearly you don't want to work on a common test suite to help new people join.

See my opening comments. It's been done before, many times over with 
standards much more complex than WebID, used by masses of people world 

>   Perhaps WebID would be just too simple then....

No comment :-)

> Henry



Kingsley Idehen	
Founder&  CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Received on Thursday, 5 January 2012 00:11:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:54 UTC