You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Chris Chabot <ch...@google.com> on 2009/06/14 16:09:18 UTC
Re: [opensocial-and-gadgets-spec] Re: Poco alignment: some minor
mistakes need to be changed on the 0.9 RESTful spec?
Ok that's all fine and well, but my larger concern right now is: but what do
we practically implement in php-shindig for 0.9? For 0.9 we've already
stated that we wanted to be (re)aligned with PoCo, and it seems there's some
inconsistencies left.
So what *should* we implement right now? Go for complete alignment (since we
stated that as goal for this revision) in php-shindig, and deal with the
confusion and/or incompatibilities with java-shindig (and/or other
implementations), do we align with the java & javascript implementations, or
... ?
-- Chris
On Fri, Jun 12, 2009 at 8:55 PM, Arne Roomann-Kurrik <ku...@google.com>wrote:
> Awesome work! I'd love to get these truly aligned for the next version.
> Most of these changes seem fairly simple too.
>
> What's the difference between "languages" and "languagesSpoken"? Seems
> redundant.
>
> ~Arne
>
>
>
> On Fri, Jun 12, 2009 at 6:58 AM, Chris Chabot <ch...@google.com> wrote:
>
>> Awesome job going through that Jacky!
>>
>> The list looks quite comprehensive, and more importantly, correct too me.
>> Since this affects both the spec and the php and java reference
>> implementations I would like to invite everyone to take a quick gander at
>> the spreadsheet, and once we all agree about what is or isn't correct, we
>> can go and make the adjustments that are required.
>>
>> Wha'da'ya'all think?
>>
>> -- Chris
>>
>>
>> On Fri, Jun 12, 2009 at 3:25 PM, Jacky <Ja...@gmail.com> wrote:
>>
>>>
>>> Hi All,
>>>
>>> I'm doing the poco alignment for PHP Shindig recently. When reading
>>> through the spec, I found some small mistakes on the 0.9 RESTful spec
>>> as following:
>>>
>>> - in 3.2 Person / 3.3 Group / 3.4 Activity / 3.5 AppData
>>> All items should use "entry" in XML format, instead of "person",
>>> "group", "activity" or "appdata".
>>>
>>> - need to change all "Singluar" into "Singular".
>>>
>>> - Sometimes the description and XML schema are not consistent.
>>> I've composed a complete side-by-side comparison matrix of Portable
>>> Contacts, OpenSocial 0.9 Spec (description), OpenSocial 0.9 XML
>>> schema, Java Shindig and PHP Shindig on http://bit.ly/PocoAlignment.
>>> And it seems like the following attributes need to be adjusted:
>>>
>>> Person: age, appdata, hasApp
>>> Name: additionalName
>>> Address: extendedAddress, poBox, primary
>>> Organization: address, field, location, primary, salary, subField,
>>> webpage
>>> Account: primary
>>>
>>> Thanks,
>>> - Jacky
>>>
>>>
>>
>>
>>
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups
> "OpenSocial and Gadgets Specification Discussion" group.
> To post to this group, send email to
> opensocial-and-gadgets-spec@googlegroups.com
> To unsubscribe from this group, send email to
> opensocial-and-gadgets-spec+unsubscribe@googlegroups.com<op...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>
RE: [opensocial-and-gadgets-spec] Re: Poco alignment: some minor mistakes need to be changed on the 0.9 RESTful spec?
Posted by Scott Seely <sS...@myspace-inc.com>.
Chris-- I think that the PHP Shindig issue is a question for another list. I believe that the real question is "what should we look for in a conforming 0.9 implementation?"
The XML alignment is a bit trickier. PoCo has pushed back on an XSD (and continues to not have one) whereas OpenSocial constituents have been adamant that we have an XSD. The XSD argument seems to be centered around code generation concerns. Also note that since a PoCo response lives in the global XMLNS, the current direction of PoCo and OpenSocial generate different infosets. Because of this, the code generation advocates still would have issues.
The primary issue we need to address is this: a PoCo request will only EVER return person data and an OpenSocial request may return person, appdata, activities, groups, etc. We both wrap our responses in a response object that indicates which page of data was returned. The key problem that we have been trying to tackle is how to cleanly wrap these items to make the entry items self describing.
We can do the following to get self describing 'entry' elements in XML:
1. Use xsi:type attributes on each entry. xsi:type is used to denote the type of an element when the data is ambiguous. This is easy to parse, but many code generators don't know how to handle parsing this type of attribute. To me, this isn't a concern. If a person MUST use XML, they can probably parse it. All other issues should be able to be handled by simple client libraries and a few days of effort. The client library is equivalent to the code-gen'd issue in that someone else handles parsing markup into program data.
2. Use separate XMLNS for each entry. This option seems appealing until one sees that the resulting XSD uses options that aren't commonly available on most code generators. Altova produces commercial generators that do handle the cases, but then we are in a place where users must purchase a commerical tool to use the XSD.
3. Indicate the types in the result via the HTTP Content header. This idea is very appealing because it handles making the JSON and XML responses self describing.
I'm sure that there are other options-- these are the 3 I've investigated to solve this problem.
________________________________
From: opensocial-and-gadgets-spec@googlegroups.com on behalf of Chris Chabot
Sent: Sun 6/14/2009 7:09 AM
To: opensocial-and-gadgets-spec@googlegroups.com; shindig-dev@incubator.apache.org
Subject: [opensocial-and-gadgets-spec] Re: Poco alignment: some minor mistakes need to be changed on the 0.9 RESTful spec?
Ok that's all fine and well, but my larger concern right now is: but what do we practically implement in php-shindig for 0.9? For 0.9 we've already stated that we wanted to be (re)aligned with PoCo, and it seems there's some inconsistencies left.
So what *should* we implement right now? Go for complete alignment (since we stated that as goal for this revision) in php-shindig, and deal with the confusion and/or incompatibilities with java-shindig (and/or other implementations), do we align with the java & javascript implementations, or ... ?
-- Chris
On Fri, Jun 12, 2009 at 8:55 PM, Arne Roomann-Kurrik <ku...@google.com> wrote:
Awesome work! I'd love to get these truly aligned for the next version. Most of these changes seem fairly simple too.
What's the difference between "languages" and "languagesSpoken"? Seems redundant.
~Arne
On Fri, Jun 12, 2009 at 6:58 AM, Chris Chabot <ch...@google.com> wrote:
Awesome job going through that Jacky!
The list looks quite comprehensive, and more importantly, correct too me. Since this affects both the spec and the php and java reference implementations I would like to invite everyone to take a quick gander at the spreadsheet, and once we all agree about what is or isn't correct, we can go and make the adjustments that are required.
Wha'da'ya'all think?
-- Chris
On Fri, Jun 12, 2009 at 3:25 PM, Jacky <Ja...@gmail.com> wrote:
Hi All,
I'm doing the poco alignment for PHP Shindig recently. When reading
through the spec, I found some small mistakes on the 0.9 RESTful spec
as following:
- in 3.2 Person / 3.3 Group / 3.4 Activity / 3.5 AppData
All items should use "entry" in XML format, instead of "person",
"group", "activity" or "appdata".
- need to change all "Singluar" into "Singular".
- Sometimes the description and XML schema are not consistent.
I've composed a complete side-by-side comparison matrix of Portable
Contacts, OpenSocial 0.9 Spec (description), OpenSocial 0.9 XML
schema, Java Shindig and PHP Shindig on http://bit.ly/PocoAlignment.
And it seems like the following attributes need to be adjusted:
Person: age, appdata, hasApp
Name: additionalName
Address: extendedAddress, poBox, primary
Organization: address, field, location, primary, salary, subField,
webpage
Account: primary
Thanks,
- Jacky
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
To post to this group, send email to opensocial-and-gadgets-spec@googlegroups.com
To unsubscribe from this group, send email to opensocial-and-gadgets-spec+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
-~----------~----~----~----~------~----~------~--~---