You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Dan Brickley <da...@danbri.org> on 2008/06/26 10:21:31 UTC
Schema sources (was Re: Shindig PHP Architecural Overview Article)
Rajdeep Dua wrote:
> Thanks for the encouraging feedback.
> Chris - I will make the changes based on your feedback
>
> The schema diagram has been drawn manually -- no auto-generation as of now
> ,exploring various tools to do this.
Ah ok. Where in the PHP/Java/Javascript sources (or wiki etc) is the
most authoritative source spec for the schema? I'm looking at mapping
this stuff into RDF/FOAF, but for now have just worked from one of the
demo SQL backends that was circulated...
cheers,
Dan
--
http://danbri.org/
RE: Schema sources (was Re: Shindig PHP Architecural Overview Article)
Posted by "Michael Ryan (Software Developer)" <Mi...@apollogrp.edu>.
Without cluttering the js/API itself, not so much, JavaScript itself
doesn't have an internal enumeration type, usually this is worked around
by having a static class that has each key to a paired value that is
used, this makes the code more obvious as you can use friendly
inferences maybe through an enum helper...
if (Enum.contains(enumeration, value)) ...
would be easier against multiple enumerations as opposed to creating
static case statements...
I don't know all the specifics of the JS for shindig, just javascript in
general.
--
Michael J. Ryan -- Software Developer -- Apollo Group
> -----Original Message-----
> From: Dan Brickley [mailto:danbri@danbri.org]
> Sent: Thursday, June 26, 2008 3:50 AM
> To: shindig-dev@incubator.apache.org
> Subject: Re: Schema sources (was Re: Shindig PHP Architecural Overview
> Article)
>
> Dan Brickley wrote:
> > Rajdeep Dua wrote:
> >> Thanks for the encouraging feedback.
> >> Chris - I will make the changes based on your feedback
> >>
> >> The schema diagram has been drawn manually -- no auto-generation
as
> >> of now
> >> ,exploring various tools to do this.
> >
> > Ah ok. Where in the PHP/Java/Javascript sources (or wiki etc) is the
> > most authoritative source spec for the schema? I'm looking at
mapping
> > this stuff into RDF/FOAF, but for now have just worked from one of
> the
> > demo SQL backends that was circulated...
>
> Kevin Marks in IRC gently encouraged me to look in the spec,
>
> phenny: danbri: 07:27Z <KevinMarks> tell danbri OpenSocial Person
field
> is in the Spec:
>
http://code.google.com/apis/opensocial/docs/0.8/reference/#opensocial.P
> erson.Field
>
> Which apart from making me realise it was a dumb sounding question,
> makes me also clarify my question: is there a *machine-friendly*
schema
> of some kind that can be used as a common authoritative source. The
> spec
> source doesn't seem designed (microformats-style) to be
machine-parsed.
>
> To which Kevin in IRC is just now replying: these docs are generated
by
> javadoc from the Javascript API source. And a copy of that seems to be
> in the Apache SVN:
>
>
http://svn.apache.org/repos/asf/incubator/shindig/trunk/features/openso
> cial-reference/person.js
> ...and more in
>
http://svn.apache.org/repos/asf/incubator/shindig/trunk/features/openso
> cial-reference/
>
>
> So I'll treat that as authoritative at least until I find a copy on
the
> main opensocial site...
>
>
> Looking there in person.js I see (to use gender as an example)
>
> /**
> * Person's gender, specified as an opensocial.Enum with the enum's
> * key referencing opensocial.Enum.Gender.
> * Container support for this field is OPTIONAL.
> *
> * @member opensocial.Person.Field
> */
> GENDER : 'gender',
>
> ...but nothing more in the js to associate either 'GENDER' or 'gender'
> with the enumerated values (rather than, say, a string). All the
typing
> information is in the comments.
>
> Over in enum.js we see the enumerated values, but I don't see how to
> programmatically associate them with the GENDER field:
>
> /**
> * @static
> * @class
> * The enum keys used by the gender field.
> * <p><b>See also:</b>
> * <a href="opensocial.Person.Field.html">
> * opensocial.Person.Field.Gender</a>
> * </p>
> *
> * @name opensocial.Enum.Gender
> */
> opensocial.Enum.Gender = {
> /** @member opensocial.Enum.Gender */
> MALE : 'MALE',
> /** @member opensocial.Enum.Gender */
> FEMALE : 'FEMALE'
> };
>
>
> Am I missing something obvious? Is there a way I can write a bit of
.js
> to determine that one field is string-valued, while another takes an
> enum?
>
> thanks for listening ;)
>
> cheers,
>
> Dan
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
Re: Schema sources (was Re: Shindig PHP Architecural Overview Article)
Posted by Kevin Brown <et...@google.com>.
On Thu, Jun 26, 2008 at 3:49 AM, Dan Brickley <da...@danbri.org> wrote:
> Dan Brickley wrote:
>
>> Rajdeep Dua wrote:
>>
>>> Thanks for the encouraging feedback.
>>> Chris - I will make the changes based on your feedback
>>>
>>> The schema diagram has been drawn manually -- no auto-generation as of
>>> now
>>> ,exploring various tools to do this.
>>>
>>
>> Ah ok. Where in the PHP/Java/Javascript sources (or wiki etc) is the most
>> authoritative source spec for the schema? I'm looking at mapping this stuff
>> into RDF/FOAF, but for now have just worked from one of the demo SQL
>> backends that was circulated...
>>
>
> Kevin Marks in IRC gently encouraged me to look in the spec,
>
> phenny: danbri: 07:27Z <KevinMarks> tell danbri OpenSocial Person field is
> in the Spec:
> http://code.google.com/apis/opensocial/docs/0.8/reference/#opensocial.Person.Field
>
> Which apart from making me realise it was a dumb sounding question, makes
> me also clarify my question: is there a *machine-friendly* schema of some
> kind that can be used as a common authoritative source. The spec source
> doesn't seem designed (microformats-style) to be machine-parsed.
>
> To which Kevin in IRC is just now replying: these docs are generated by
> javadoc from the Javascript API source. And a copy of that seems to be in
> the Apache SVN:
>
>
> http://svn.apache.org/repos/asf/incubator/shindig/trunk/features/opensocial-reference/person.js
> ...and more in
> http://svn.apache.org/repos/asf/incubator/shindig/trunk/features/opensocial-reference/
>
>
> So I'll treat that as authoritative at least until I find a copy on the
> main opensocial site...
The official versions used to generate the spec documentation are checked
into the opensocial-resources SVN repository on code.google.com:
http://opensocial-resources.googlecode.com/svn/spec/0.8/
>
>
> Looking there in person.js I see (to use gender as an example)
>
> /**
> * Person's gender, specified as an opensocial.Enum with the enum's
> * key referencing opensocial.Enum.Gender.
> * Container support for this field is OPTIONAL.
> *
> * @member opensocial.Person.Field
> */
> GENDER : 'gender',
>
> ...but nothing more in the js to associate either 'GENDER' or 'gender' with
> the enumerated values (rather than, say, a string). All the typing
> information is in the comments.
>
> Over in enum.js we see the enumerated values, but I don't see how to
> programmatically associate them with the GENDER field:
>
> /**
> * @static
> * @class
> * The enum keys used by the gender field.
> * <p><b>See also:</b>
> * <a href="opensocial.Person.Field.html">
> * opensocial.Person.Field.Gender</a>
> * </p>
> *
> * @name opensocial.Enum.Gender
> */
> opensocial.Enum.Gender = {
> /** @member opensocial.Enum.Gender */
> MALE : 'MALE',
> /** @member opensocial.Enum.Gender */
> FEMALE : 'FEMALE'
> };
>
>
> Am I missing something obvious? Is there a way I can write a bit of .js to
> determine that one field is string-valued, while another takes an enum?
>
> thanks for listening ;)
>
>
> cheers,
>
> Dan
>
> --
> http://danbri.org/
>
Re: Schema sources (was Re: Shindig PHP Architecural Overview Article)
Posted by Dan Brickley <da...@danbri.org>.
Dan Brickley wrote:
> Rajdeep Dua wrote:
>> Thanks for the encouraging feedback.
>> Chris - I will make the changes based on your feedback
>>
>> The schema diagram has been drawn manually -- no auto-generation as
>> of now
>> ,exploring various tools to do this.
>
> Ah ok. Where in the PHP/Java/Javascript sources (or wiki etc) is the
> most authoritative source spec for the schema? I'm looking at mapping
> this stuff into RDF/FOAF, but for now have just worked from one of the
> demo SQL backends that was circulated...
Kevin Marks in IRC gently encouraged me to look in the spec,
phenny: danbri: 07:27Z <KevinMarks> tell danbri OpenSocial Person field
is in the Spec:
http://code.google.com/apis/opensocial/docs/0.8/reference/#opensocial.Person.Field
Which apart from making me realise it was a dumb sounding question,
makes me also clarify my question: is there a *machine-friendly* schema
of some kind that can be used as a common authoritative source. The spec
source doesn't seem designed (microformats-style) to be machine-parsed.
To which Kevin in IRC is just now replying: these docs are generated by
javadoc from the Javascript API source. And a copy of that seems to be
in the Apache SVN:
http://svn.apache.org/repos/asf/incubator/shindig/trunk/features/opensocial-reference/person.js
...and more in
http://svn.apache.org/repos/asf/incubator/shindig/trunk/features/opensocial-reference/
So I'll treat that as authoritative at least until I find a copy on the
main opensocial site...
Looking there in person.js I see (to use gender as an example)
/**
* Person's gender, specified as an opensocial.Enum with the enum's
* key referencing opensocial.Enum.Gender.
* Container support for this field is OPTIONAL.
*
* @member opensocial.Person.Field
*/
GENDER : 'gender',
...but nothing more in the js to associate either 'GENDER' or 'gender'
with the enumerated values (rather than, say, a string). All the typing
information is in the comments.
Over in enum.js we see the enumerated values, but I don't see how to
programmatically associate them with the GENDER field:
/**
* @static
* @class
* The enum keys used by the gender field.
* <p><b>See also:</b>
* <a href="opensocial.Person.Field.html">
* opensocial.Person.Field.Gender</a>
* </p>
*
* @name opensocial.Enum.Gender
*/
opensocial.Enum.Gender = {
/** @member opensocial.Enum.Gender */
MALE : 'MALE',
/** @member opensocial.Enum.Gender */
FEMALE : 'FEMALE'
};
Am I missing something obvious? Is there a way I can write a bit of .js
to determine that one field is string-valued, while another takes an enum?
thanks for listening ;)
cheers,
Dan
--
http://danbri.org/