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-s...@googlegroups.com on behalf of Chris Chabot
Sent: Sun 6/14/2009 7:09 AM
To: opensocial-and-gadgets-s...@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 <kur...@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 <chab...@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
<jacky.chao.w...@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-s...@googlegroups.com
To unsubscribe from this group, send email to
opensocial-and-gadgets-spec+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
-~----------~----~----~----~------~----~------~--~---
