On Fri, May 1, 2009 at 3:43 PM, Scott Seely <sSe...@myspace-inc.com> wr= ote:

Lane and I hav= e dug into this during the week. Adding the xmlns to the entry would disambiguate things but makes the schema a mess. I came = up with something, but it=92s some complex schema.

=A0

XSD does offer= another option: declare the type of the element. XSD has this feature in the spec at =A0http://www.w3.org/TR/xmlschema-1/#xsi_type. Instead of declaring the type in the schema, the REST XML declares the type= on the <entry> element. Example:

<entry xsi:= type=3D"os:Person">

</entry>=

=A0

This allows us= to use one xmlns for all of REST OpenSocial, allows parity with PoCo XML, and is about as difficult to implement as the xmlns option (decoding would switch on the xmlns attribute or on the xsi:ty= pe attribute).

=A0

Are folks OK w= ith this compromise?

=A0

From: opensocial-and-gadgets-spec@googlegroups.com [mailto:open= social-and-gadgets-spec@googlegroups.com] On Behalf Of Scott Seely
Sent: Tuesday, April 21, 2009 11:04 AM
To: portablecontacts@googlegroups.com; opensocial-and-gadgets-spec@googlegroups.com
Subject: [opensocial-and-gadgets-spec] Re: Issue with Google's P= oCo endpoint (and inconsistency between the PoCo/OS specs?)

=A0

Another option= (not being discussed) is to use an XMLNS to clearly mark the element name as a PoCo person and share the markup/XSD bet= ween the two specs. This would allow for the desired clarity (it=92s a PoCo pers= on) without worrying about clashes between other things (PoCo doesn=92t have activities).

=A0

Consider this = in terms of the work going on within the Activity Streams community (ht= tp://activitystrea.ms) as yet another point we might want to connect.

=A0

Just a thought= =85

=A0

From: port= ablecontacts@googlegroups.com [mailto:portablecontacts@googlegroups.com= ] On Behalf Of Joseph Smarr
Sent: Tuesday, April 21, 2009 9:48 AM
To: opensocial-and-gadgets-spec@googlegroups.com; Portabl= eContacts
Subject: Re: [opensocial-and-gadgets-spec] Re: Issue with Google'= ;s PoCo endpoint (and inconsistency between the PoCo/OS specs?)

=A0

Agreed, +1 for #1 as well (just using <entry> for all endpoints). Thanks! js

On Tue, Apr 21, 2009 at 9:37 AM, Adam Winer <awi...@gmail.com> wrote:

On Tue, Apr 21, 2009 at 9:30 AM, Lane LiaBraaten <lliab...@google.com> wrote:
>
>
> On Mon, Apr 20, 2009 at 6:25 PM, Louis Ryan <lr...@google.com> wrote:
>>
>> I dont believe RelaxNG can do a type parameterization based on an<= br> >> attribute.
>> I could live with #1 which would be fine for validation, we would = just
>> select a different schema per endpoint which=A0shouldn't=A0be = a big deal. The
>> schema for each type can share common parts through standard XSD/R= elax
>> import mechanisms.
>
> +1 - I like this approach because it 1) solves the 1:1 mapping and 2)<= br> > simplifies our XSD.=A0 We can define much simpler XSDs for each data type,
> then include a schema for each endpoint that imports the data XSDs.=A0 That
> is, put the schema information in the part of the spec where it's relevant,
> rather than lumping it all into an appendix at the end.

That makes a lot of sense; =A0I can get behind this. =A0+1 for #1.

-- Adam

>> #2 Really doesn't seem like it adds much value. It=A0doesn't=A0help with
>> validation and=A0doesn't=A0make consumption simpler either. >> #3 is evil
>> #4 would obviously be fine in OpenSocial land and would allow us t= o keep a
>> single mega-XSD for validation but maybe thats not such a great th= ing
>> anyway.
>>
>> On Mon, Apr 20, 2009 at 5:08 PM, Adam Winer <awi...@gmail.com> wrote:
>>>
>>> Another option:
>>>
>>> 5) =A0Use <entry> for people, and keep the meaningful names for all
>>> other first-class data types.
>>> Pros: Requires no PoCo changes. =A0Supports validation.
>>> Cons: Is ugly. =A0Horribly ugly.
>>>
>>> Alignment between OpenSocial and PoCo does imply the possibili= ty of
>>> additional requirements on PoCo, does it not? =A0One would hop= e there'd
>>> be some room for change in either spec. =A0In this case, "support for
>>> XML beyond just people" becomes a requirement for any sha= red format.
>>> I'm not an XML Schema fan in general, but we do need some = hope of
>>> validating XML content. =A0Does anyone know if RelaxNG would support
>>> type=3D"..." attributes?
>>>
>>> On Mon, Apr 20, 2009 at 2:09 PM, Joseph Smarr <jsm...@gmail.com> wrote: >>> > I would vote for #2, and here's why: the specific ali= gnment we achieved
>>> > is
>>> > that "any compliant OpenSocial RESTful Protocol Prov= ider is also a
>>> > compliant
>>> > Portable Contacts Provider". So it's fine if the= OS response has some
>>> > "extra
>>> > stuff" as long as the PoCo-specific subset is identi= cal. Thus the extra
>>> > <person> sub-node does NOT fit this description, bu= t adding an extra
>>> > type=3D"person" attribute (or something similar= like that) does, since
>>> > PoCo
>>> > consumers can safely ignore it. That being said, if the primary issue
>>> > here
>>> > is static schema validation, then this doesn't really= solve the
>>> > problem.
>>> > However, I believe most implementations will expect people-data under
>>> > <entry> when making a getPeople call, so if adding type=3D"person"
>>> > doesn't
>>> > help the XSD stuff, I might argue just to get rid of it altogether and
>>> > rely
>>> > instead on context. Or if there's some clever XML way= to reference a
>>> > different schema for entry without adding intermediate no= des, that
>>> > would
>>> > work too, but I think the highest priority should be alignment with
>>> > PoCo and
>>> > alignment with JSON, cuz that's when stuff will break= for normal use
>>> > cases...
>>> >
>>> > Anyone disagree?
>>> >
>>> > Thanks, js
>>> >
>>> > On Mon, Apr 20, 2009 at 12:54 PM, Lane LiaBraaten
>>> > <api.lliab...@gmail.com>
>>> > wrote:
>>> >>
>>> >> [adding in opensocial spec list (n.b. you need to be = a member of both
>>> >> groups or your response will bounce)]
>>> >>
>>> >> Context for the folks on the OpenSocial spec list... = This thread is
>>> >> about
>>> >> alignment between OpenSocial's REST protocol and PoCo.=A0 PoCo only has
>>> >> one
>>> >> first-class data type (Contact), so an XML reponse contains a bunch of
>>> >> <entry> nodes an each one is a Contact.=A0 OpenSocial supports several
>>> >> first-class data types (e.g. activities, groups, etc.= ) and OS defined
>>> >> XML
>>> >> nodes for each: <person>, <activity>, etc= ., so an XML response
>>> >> contains a
>>> >> bunch of <entry> nodes, each containing one <person>, <activity>, or
>>> >> other
>>> >> first-class data type node.
>>> >>
>>> >> There are pretty much 2 issues:
>>> >> =A0 Inconsistency: PoCo returns response/entry/{perso= n data} while
>>> >> OpenSocial returns response/entry/person/{person data= }.
>>> >> =A0 1:1 Mapping: Both specs say that there is a 1:1 mapping between XML
>>> >> and
>>> >> JSON format, but in OpenSocial's case this isn= 9;t true.=A0=A0 Because
>>> >> OpenSocial
>>> >> defined XML nodes for each first-class data type (e.g= . <person>,
>>> >> <activities>, etc), there is more information i= n the XML format than
>>> >> the
>>> >> JSON and there is no 1:1 mapping.
>>> >>
>>> >> Here are a few potential solutions:
>>> >>
>>> >> 1) In OpenSocial, use <entry> for all first-cla= ss data types
>>> >> =A0 - Pros: Solves the 1:1 mapping issue in OpenSocial; doesn't affect
>>> >> JSON
>>> >> =A0 - Cons: Makes validating the XML impossible or meaningless as an
>>> >> OpenSocial <entry> could contain just about any subnodes.
>>> >>
>>> >> 2) In OpenSocial, use <entry type=3D"person">...</entry> instead of
>>> >> <entry><person>...</person</entry&g= t;.
>>> >> =A0 - Pros: PoCo clients can just ignore the type attribute; doesn't
>>> >> affect
>>> >> the JSON
>>> >> =A0 - Cons:
>>> >> =A0=A0=A0=A0=A0 * Doesn't solve the 1:1 issue as the XML format still contains
>>> >> more
>>> >> info than JSON.
>>> >> =A0=A0=A0=A0=A0 * Makes validating the XML impossible or meaningless as an
>>> >> OpenSocial <entry> could contain just about any subnodes (and, IIUC,
>>> >> there's
>>> >> no way to validate this with an XSD where the content= of a node/type
>>> >> is
>>> >> dependent on the value of an attribute).
>>> >>
>>> >> 3) In OpenSocial, add a 'type' property in JS= ON.=A0 This would map to
>>> >> <entry><type>person</type>...</entry> in XML
>>> >> =A0- Pros: solves the 1:1 mapping problem
>>> >> =A0- Cons: bolts strong-typing on to JSON which seems bad; doesn't help
>>> >> w.r.t. issue w/ conditional validation
>>> >>
>>> >> 4) In both specs, use <person> instead of <entry> when mapping from
>>> >> JSON
>>> >> to XML
>>> >> =A0- Pros: solves the 1:1 mapping; doesn't affect= JSON at all
>>> >> =A0- Cons: Backwards compatability is an issue for al= l these, but this
>>> >> may
>>> >> be the worst offender since it touches both specs. >>> >>
>>> >> What does everyone think of these options?=A0 Anyone have other ideas?
>>> >>
>>> >> -Lane
>>> >>
>>> >> On Mon, Apr 20, 2009 at 10:26 AM, Joseph Smarr <jsm...@gmail.com>= ;
>>> >> wrote:
>>> >>>
>>> >>> Lane-there definitely should NOT be a person elem= ent inside the entry
>>> >>> element in OS. I believe we decided that it could reference a
>>> >>> different
>>> >>> schema or xmlns or have some type attribute in th= e entry or some way
>>> >>> of
>>> >>> telling what type of entry it is, but we certainl= y never agreed to a
>>> >>> sub-node, so this is definitely a bug on the OS s= ide.
>>> >>
>>> >> Unfortunately, this was never fully addressed.=A0 You made this
>>> >> suggestion
>>> >> on the list [1], but there wasn't any resolution = and the schema that
>>> >> was
>>> >> approved uses a person sub-node.
>>> >>
>>> >> [1]
>>> >>
>>> >> = http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/th= read/27a2f9d86d55b33b/
>>> >>
>>> >>> This isn't how it looks in JSON, is it? I'= ;m pretty sure the
>>> >>> shindig-php
>>> >>> code i worked on never had a person element, sinc= e partuza works fine
>>> >>> in my
>>> >>> PoCo test harness...
>>> >>
>>> >> The JSON format doesn't specify the type so this = problem does not come
>>> >> up.=A0 The test harness works fine for Google too, since the harness
>>> >> uses
>>> >> JSON.=A0 You can get it to return the xml if you add ?format=3Dxml to the
>>> >> API
>>> >> base URL (like this: http://is.gd/tw1P)
>>> >>
>>> >>
>>> >>>
>>> >>>
>>> >>> Thanks, js
>>> >>>
>>> >>> On Mon, Apr 20, 2009 at 9:44 AM, Lane LiaBraaten<= br> >>> >>> <api.lliab...@gmail.com>
>>> >>> wrote:
>>> >>>>
>>> >>>> Hey Sean,
>>> >>>>
>>> >>>> Thanks for reporting the issue. =A0There'= s definitely an <entry> tag
>>> >>>> missing, but the <person> element shoul= d be defined. =A0We had several
>>> >>>> threads about this back in November when we w= ere working on aligning
>>> >>>> the PoCo and OpenSocial. =A0Since OpenSocial works with more data
>>> >>>> types
>>> >>>> than just Contacts (e.g. Groups, Activities, etc.), we need to
>>> >>>> define
>>> >>>> what kind of content is in the entry.
>>> >>>>
>>> >>>> Basically OpenSocial defines the response as:=
>>> >>>> <response xmlns=3D"http://ns.opensocial.o= rg/2008/opensocial">
>>> >>>> =A0<startIndex> 1 </startIndex> >>> >>>> =A0<itemsPerPage> 10 </itemsPerPage>
>>> >>>> =A0<totalResults> 100 </totalResults>
>>> >>>> =A0<entry>
>>> >>>> =A0 =A0<person xmlns=3D"http://ns.opensoc= ial.org/2008/opensocial">
>>> >>>> =A0 =A0 =A0<id>example.org:34KJDCSKJN2HHF0DW20394</id>
>>> >>>> =A0 =A0 =A0<displayName>Janey</displ= ayName>
>>> >>>> =A0 =A0 =A0<name>
>>> >>>> =A0 =A0 =A0 =A0<formatted>Jane Doe</formatted>
>>> >>>> =A0 =A0 =A0</name>
>>> >>>> =A0 =A0 =A0<gender>female</gender>
>>> >>>> =A0 =A0</person>
>>> >>>> =A0</entry>
>>> >>>> </response>
>>> >>>>
>>> >>>> Like you said, the PoCo spec never mentions t= he <person> element
>>> >>>> (and
>>> >>>> it's obviously not essential since all en= tries are Contacts).
>>> >>>> However, to stayed synced with OpenSocial, we need to decide how to
>>> >>>> handle this. =A0Any suggestions?
>>> >>>>
>>> >>>> -Lane
>>> >>>>
>>> >>>> OpenSocial REST XSD -
>>> >>>>
>>> >>>> http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/REST= -API.html#XML_format_XSD
>>> >>>> OpenSocial REST Response definition and examp= les -
>>> >>>>
>>> >>>>
>>> >>>> http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/RES= T-API.html#rfc.section.3.1
>>> >>>>
>>> >>>> On Mar 26, 9:22=A0am, Sean Sullivan <s...@seansullivan.com= > wrote:
>>> >>>> > On Wed, Mar 25, 2009 at 11:01 PM, Joseph Smarr <jsm...@gmai= l.com>
>>> >>>> > wrote:
>>> >>>> > > Yes, you heard right, Gmail is now = a full-fledged Portable
>>> >>>> > > Contacts
>>> >>>> > > provider, complete with Google Code developer guide and
>>> >>>> > > everything!
>>> >>>> > > :)
>>> >>>> > > Congrats to Google, and congrats to= the whole PoCo community for
>>> >>>> > > this
>>> >>>> > > awesome milestone. Read all about i= t at
>>> >>>> >
>>> >>>> > >
>>> >>>> > > > >= http://googlesocialweb.blogspot.com/2009/03/take-your-google-contacts..= .
>>> >>>> >
>>> >>>> > Very cool.
>>> >>>> >
>>> >>>> > Using the jpoco library, I sent a couple= of requests to Google's
>>> >>>> > Poco
>>> >>>> > endpoint. I noticed that Google's XM= L response contains a <person>
>>> >>>> > element:
>>> >>>> >
>>> >>>> > <?xml version=3D"1.0" encoding=3D"UTF-8"?><response
>>> >>>> > xmlns=3D"http://ns.opensocial.org/2008/= opensocial"><person
>>> >>>> > xmlns=3D"http://ns.opensocial.org/2008/= opensocial">
>>> >>>> > =A0 <displayName>Joe The Plumber&l= t;/displayName>
>>> >>>> > =A0 <emails>
>>> >>>> > =A0 =A0 <type>CUSTOM</type>
>>> >>>> > =A0 =A0 <value>test...@test123.com</value>=
>>> >>>> > =A0 </emails>
>>> >>>> > =A0 <id>118910240772174568914</id>
>>> >>>> > =A0 <name>
>>> >>>> > =A0 =A0 <familyName>The Plumber</familyName>
>>> >>>> > =A0 =A0 <givenName>Joe</givenName>
>>> >>>> > =A0 </name>
>>> >>>> > =A0 <nickname>Joe</nickname>=
>>> >>>> > </person></response>
>>> >>>> >
>>> >>>> > The PoCo specification doesn't defin= e a <person> element.
>>> >>>> > =A0Instead,
>>> >>>> > PoCo defines an element called <entry= >
>>> >>>> >
>>> >>>> > Can you tell me which element name is correct?
>>> >>>> >
>>> >>>> > Cheers,
>>> >>>> >
>>> >>>> > Sean
>>> >>>>
>>> >>>>
>>> >>>
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >
>>> >
>>> > >
>>> >
>>>
>>>
>>
>>
>>
>
>
> >
>

=A0

=A0