Issue 154120: Clarify Separation of Gadgets (Data Sections)
|
Created:
15 years, 4 months ago by Jon Weygandt Modified:
10 years, 3 months ago Base URL:
http://opensocial-resources.googlecode.com/svn/spec/ Visibility:
Public. |
Patch Set 1 #Patch Set 2 : Finished draft (first version) #
Total comments: 4
Patch Set 3 : Attempted to address Lane's issues. #
Total comments: 3
Patch Set 4 : Fixed the typos and grammer #
Total comments: 2
Patch Set 5 : Moved the background info over to the Social-Data spec #
Total comments: 1
Patch Set 6 : Removed "OpenSocial-" from Core-Data, create new types and revised references to "id"s #
Total comments: 2
Patch Set 7 : Merged appropriate changes from 152119 into this patch. #Patch Set 8 : Added Album. #
Total comments: 29
Patch Set 9 : Changes due to comments from #8, also rebased to latest version #Patch Set 10 : Added new types and applied them. Defined field types for Message. #
Total comments: 3
MessagesTotal messages: 33
This is really coming together! http://codereview.appspot.com/154120/diff/2001/3001 File draft/Social-Data.xml (right): http://codereview.appspot.com/154120/diff/2001/3001#newcode20 draft/Social-Data.xml:20: <t>This document defines all the data objects used in the OpenSocial APIs.</t> Please update this to explain that it extends the Core-Data spec with data objects used in the Social-Gadget and Social-API-Server specs. http://codereview.appspot.com/154120/diff/2001/3001#newcode120 draft/Social-Data.xml:120: anchor="primary-social-data"> Please add a <t></t> here explaining what Primary Social Data is (and how it's different from "Additional Social Data". Just a sentence or two should suffice. http://codereview.appspot.com/154120/diff/2001/3001#newcode553 draft/Social-Data.xml:553: <section title="Additional Social Data"> Please add a <t></t> element describing 'Additional Social Data' (and how it's different from Primary Social Data. One or two sentences should suffice. http://codereview.appspot.com/154120/diff/2001/3001#newcode632 draft/Social-Data.xml:632: <section title="OpenSocial Group ID" Title should be Group ID, not OpenSocial Group ID. (I think I prefer Group-ID, so it matches the anchor and identifiers w/o spaces are better for the ABNF in the API-Server.xml)
Sign in to reply to this message.
A preview of these files is available at: http://www.opensocial.org/Technical-Resources/draft/Core-Data.xml and http://www.opensocial.org/Technical-Resources/draft/Social-Data.xml
Sign in to reply to this message.
Attempted to address Lane's issues.
Sign in to reply to this message.
+1 http://codereview.appspot.com/154120/diff/2004/3009 File draft/Social-Data.xml (right): http://codereview.appspot.com/154120/diff/2004/3009#newcode21 draft/Social-Data.xml:21: OpenSocial APIs. Object here will make use of the <xref Object --> Objects defined http://codereview.appspot.com/154120/diff/2004/3009#newcode25 draft/Social-Data.xml:25: <t>JavaScript withing the gadget will be done using osapi APIs, withing --> within http://codereview.appspot.com/154120/diff/2004/3009#newcode31 draft/Social-Data.xml:31: </t> General preference for present tense (e.g. REST and RPC access *is* done using...). If you agree, try searching for "will" throughout.
Sign in to reply to this message.
Fixed the typos and grammer
Sign in to reply to this message.
One last thing.... Can you move the two remaining sections of the "Background" section out of the main OpenSocial-Specification and into the Social-Data section? Then you can delete the background section entirely (yay!) Thanks, Lane http://codereview.appspot.com/154120/diff/3013/2007 File draft/Social-Data.xml (right): http://codereview.appspot.com/154120/diff/3013/2007#newcode248 draft/Social-Data.xml:248: <section title="AppData" anchor="AppData"> Move the text from the Background > Key Concepts > Persistence section of the main OpenSocial spec to this section. (http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/OpenSocial-...) http://codereview.appspot.com/154120/diff/3013/2007#newcode321 draft/Social-Data.xml:321: <section title="Person" Move the text from the Background > Key Concepts > People section of the main OpenSocial spec to this section (http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/OpenSocial-...)
Sign in to reply to this message.
Moved the background info over to the Social-Data spec
Sign in to reply to this message.
http://codereview.appspot.com/154120/diff/4001/3018 File draft/Social-Data.xml (right): http://codereview.appspot.com/154120/diff/4001/3018#newcode424 draft/Social-Data.xml:424: value. This identifier MUST uniquely identify the user in a I choose "unique for the container" for this version. Discussion at: http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thre...
Sign in to reply to this message.
+1 - thanks! On Mon, Nov 23, 2009 at 3:25 PM, <jon.weygandt@gmail.com> wrote: > > http://codereview.appspot.com/154120/diff/4001/3018 > > File draft/Social-Data.xml (right): > > http://codereview.appspot.com/154120/diff/4001/3018#newcode424 > draft/Social-Data.xml:424: value. This identifier MUST uniquely identify > the user in a > I choose "unique for the container" for this version. Discussion at: > > http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thre... > > > http://codereview.appspot.com/154120 >
Sign in to reply to this message.
Removed "OpenSocial-" from Core-Data, create new types and revised references to "id"s
Sign in to reply to this message.
Since the concept of "id"s are used many places I went ahead and formalized the notion of Local-Id and Global-Id and made the appropriate changes. I made Global-Id optional, but if a container chooses to support it, it should be supported in all APIs, including JavaScript, since one day we may have pubsub. http://codereview.appspot.com/154120/diff/3021/3023 File draft/Core-Data.xml (right): http://codereview.appspot.com/154120/diff/3021/3023#newcode49 draft/Core-Data.xml:49: described in <xref target="RFC2234">RFC2234</xref> (Augmented Backus-Naur This typo is common across our documents, Lane could you fix these in the ones you are editing? http://codereview.appspot.com/154120/diff/3021/3023#newcode166 draft/Core-Data.xml:166: Domain-Name = *( ALPHA / DIGIT / "_" / "." / "-" ) We could attempt to reference the RFC for domain names, but I understand they are starting to allow international characters for them, so I'm not sure how that would work out here. For now I have kept to what I think the original intent was.
Sign in to reply to this message.
So userId, activityId, etc. are all "Object-Id" (defined as Local-Id / Global-Id) - sounds good to me. I'll fix those ABNF typos...nice catch. -Lane On Tue, Nov 24, 2009 at 9:16 AM, <jon.weygandt@gmail.com> wrote: > Since the concept of "id"s are used many places I went ahead and > formalized the notion of Local-Id and Global-Id and made the appropriate > changes. I made Global-Id optional, but if a container chooses to > support it, it should be supported in all APIs, including JavaScript, > since one day we may have pubsub. > > > http://codereview.appspot.com/154120/diff/3021/3023 > File draft/Core-Data.xml (right): > > http://codereview.appspot.com/154120/diff/3021/3023#newcode49 > draft/Core-Data.xml:49: described in <xref > target="RFC2234">RFC2234</xref> (Augmented Backus-Naur > This typo is common across our documents, Lane could you fix these in > the ones you are editing? > > http://codereview.appspot.com/154120/diff/3021/3023#newcode166 > draft/Core-Data.xml:166: Domain-Name = *( ALPHA / DIGIT / "_" / "." / > "-" ) > We could attempt to reference the RFC for domain names, but I understand > they are starting to allow international characters for them, so I'm not > sure how that would work out here. For now I have kept to what I think > the original intent was. > > http://codereview.appspot.com/154120 > > -- > > 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<opensocial-and-gadge... > . > For more options, visit this group at > http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en. > > >
Sign in to reply to this message.
Can you add Album to the Social-Data.xml file? On 2009/11/24 17:31:49, Lane LiaBraaten wrote: > So userId, activityId, etc. are all "Object-Id" (defined as Local-Id / > Global-Id) - sounds good to me. > > I'll fix those ABNF typos...nice catch. > > -Lane > > On Tue, Nov 24, 2009 at 9:16 AM, <mailto:jon.weygandt@gmail.com> wrote: > > > Since the concept of "id"s are used many places I went ahead and > > formalized the notion of Local-Id and Global-Id and made the appropriate > > changes. I made Global-Id optional, but if a container chooses to > > support it, it should be supported in all APIs, including JavaScript, > > since one day we may have pubsub. > > > > > > http://codereview.appspot.com/154120/diff/3021/3023 > > File draft/Core-Data.xml (right): > > > > http://codereview.appspot.com/154120/diff/3021/3023#newcode49 > > draft/Core-Data.xml:49: described in <xref > > target="RFC2234">RFC2234</xref> (Augmented Backus-Naur > > This typo is common across our documents, Lane could you fix these in > > the ones you are editing? > > > > http://codereview.appspot.com/154120/diff/3021/3023#newcode166 > > draft/Core-Data.xml:166: Domain-Name = *( ALPHA / DIGIT / "_" / "." / > > "-" ) > > We could attempt to reference the RFC for domain names, but I understand > > they are starting to allow international characters for them, so I'm not > > sure how that would work out here. For now I have kept to what I think > > the original intent was. > > > > http://codereview.appspot.com/154120 > > > > -- > > > > 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 > > mailto:opensocial-and-gadgets-spec@googlegroups.com. > > To unsubscribe from this group, send email to > > > mailto:opensocial-and-gadgets-spec+unsubscribe@googlegroups.com<opensocial-and-gadgets-spec%2Bunsubscribe@googlegroups.com> > > . > > For more options, visit this group at > > http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en. > > > > > > >
Sign in to reply to this message.
Merged appropriate changes from 152119 into this patch.
Sign in to reply to this message.
On 2009/11/24 17:31:49, Lane LiaBraaten wrote: > So userId, activityId, etc. are all "Object-Id" (defined as Local-Id / > Global-Id) - sounds good to me. I hope so! it sounds reasonable from reading various descriptions of the fields.
Sign in to reply to this message.
Added Album.
Sign in to reply to this message.
On 2009/11/24 18:28:41, Jon Weygandt wrote: > Added Album. Whoops...look like there are a few more. Can you also add: Body-Type Email (n.b. the emails field on Person should be updated from "Plural-Field <string>") Phone (the Person.phoneNumbers field should be updated from Plural-Field <string>) Response (e.g. https://groups.google.com/group/json-rpc/web/json-rpc-1-2-proposal?pli=1#resp...) Url - with fields for link text, type (e.g. blog, profile, etc), etc. Thanks, Lane
Sign in to reply to this message.
Wow! Thanks for the TREMENDOUS efforts on composing this!!! 2 thoughts: 1) Would it be possible to move the REST-API.xml#XML_format_XSD into Social-Data.xml as well? It looks binding tighter with the data structure, rather than RESTful protocol. 2) Shall we remove the data part from REST-API.xml, after this patch is stable? Thanks, - Jacky http://codereview.appspot.com/154120/diff/4016/3034 File draft/Core-Data.xml (right): http://codereview.appspot.com/154120/diff/4016/3034#newcode130 draft/Core-Data.xml:130: always returned in the "list" field of the result. Lists can either be the in the "entry" field? http://codereview.appspot.com/154120/diff/4016/3034#newcode134 draft/Core-Data.xml:134: returned. The paging mechanisms described here are based on the OpenSearch OpenSearch:<xref target="OpenSearch" /> <reference anchor='OpenSearch' target='http://www.opensearch.org/Specifications/OpenSearch/1.1'> <front> <title>OpenSearch 1.1, Draft 4</title> <author initials='D.' surname='Clinton' fullname='DeWitt Clinton'> <organization>OpenSearch.org</organization> </author> </front> </reference> http://codereview.appspot.com/154120/diff/4016/3034#newcode139 draft/Core-Data.xml:139: "result : {" Considering strip out the "result" part? IMHO, "collection" is a concept that contains a list of objects; and {result:collection} is the response of a request, which could be described in the REST-API.xml and RPC-protocol.xml. Therefore it might be easy for readers that the APIs are categorized into 2 types: 1. return collection: {result: collection} 2. return single object: {result: object} The above 2 types will be covered in REST-API.xml http://codereview.appspot.com/154120/diff/4016/3034#newcode288 draft/Core-Data.xml:288: <section title="Rules for mapping JSON to XML" Moving the samples mapping from application/json representation to XML representation and application/atom+xml representation in "REST-API.xml#dataRepresentations" to here? http://codereview.appspot.com/154120/diff/4016/3033 File draft/Social-Data.xml (right): http://codereview.appspot.com/154120/diff/4016/3033#newcode11 draft/Social-Data.xml:11: <title>OpenSocial Data Specification (draft)</title> "OpenSocial Social Data Spec" - counterpart towards "OpenSocial Core Data Spec" for Core-Data.xml http://codereview.appspot.com/154120/diff/4016/3033#newcode376 draft/Social-Data.xml:376: <ttcol align="left">Description</ttcol> sort the attributes? :) http://codereview.appspot.com/154120/diff/4016/3033#newcode376 draft/Social-Data.xml:376: <ttcol align="left">Description</ttcol> currentLocation: The field currentLocation is deprecated in 1.0 in favor of the standard location field, but is included for backwards compatibility. currentLocation will be fully removed in a future version of the spec. http://codereview.appspot.com/154120/diff/4016/3033#newcode376 draft/Social-Data.xml:376: <ttcol align="left">Description</ttcol> hasApp: Boolean value indicating whether the user has application installed. http://codereview.appspot.com/154120/diff/4016/3033#newcode549 draft/Social-Data.xml:549: <c>location</c> see currentLocation field. http://codereview.appspot.com/154120/diff/4016/3033#newcode683 draft/Social-Data.xml:683: non-empty value for either username or userId, and MAY contain both, in userId -> userid http://codereview.appspot.com/154120/diff/4016/3033#newcode703 draft/Social-Data.xml:703: <c>userId</c> userId -> userid http://codereview.appspot.com/154120/diff/4016/3033#newcode748 draft/Social-Data.xml:748: <c>type</c> remove "type" since it has been defined in Core-Data.xml. http://codereview.appspot.com/154120/diff/4016/3033#newcode944 draft/Social-Data.xml:944: <c>The salary the person receieves from the organization</c> organization "." :) http://codereview.appspot.com/154120/diff/4016/3033#newcode955 draft/Social-Data.xml:955: <c>type</c> remove "type" since it has been defined in Core-Data.xml.
Sign in to reply to this message.
@Jacky - note that the current REST and RPC specs will be migrated into Core-API-Server and Social-API-Server. The former describes the protocols and the latter describes the services related to social data (e.g. people, activities, etc). Where the XSD goes is still a good question. It's related to the server response/requests, but it also defines the XML representation of our data objects. Do you think it's possible to break the XSD into smaller parts that just define things like: * a request/response * a person * an activity * etc. These would be easier to place among the docs. I.e. the request/resonse XSD goes in the Core-API-Server, the XSD for objects goes in the Social-Data spec where the object is defined. http://codereview.appspot.com/154120/diff/4016/3034 File draft/Core-Data.xml (right): http://codereview.appspot.com/154120/diff/4016/3034#newcode139 draft/Core-Data.xml:139: "result : {" On 2009/12/01 10:37:35, Jacky.Chao.Wang wrote: > Considering strip out the "result" part? IMHO, "collection" is a concept that > contains a list of objects; and {result:collection} is the response of a > request, which could be described in the REST-API.xml and RPC-protocol.xml. > Therefore it might be easy for readers that the APIs are categorized into 2 > types: > 1. return collection: {result: collection} > 2. return single object: {result: object} > The above 2 types will be covered in REST-API.xml +1 - though this will be covered in the Core-API-Server.xml doc, not REST-API.xml http://codereview.appspot.com/154120/diff/4016/3033 File draft/Social-Data.xml (right): http://codereview.appspot.com/154120/diff/4016/3033#newcode683 draft/Social-Data.xml:683: non-empty value for either username or userId, and MAY contain both, in On 2009/12/01 10:37:35, Jacky.Chao.Wang wrote: > userId -> userid I thought we explicitly changed to camelcase userId. Why do you suggest all lowercase userid?
Sign in to reply to this message.
Hi Jon and Lane, How's the progress? I'll try to split the xml schema part out and put them into these 2 files. Thanks, Jacky http://codereview.appspot.com/154120/diff/4016/3033 File draft/Social-Data.xml (right): http://codereview.appspot.com/154120/diff/4016/3033#newcode683 draft/Social-Data.xml:683: non-empty value for either username or userId, and MAY contain both, in According to the document here: http://spreadsheets.google.com/ccc?key=rUzMVUM2azeJAW3EouN1dCQ Both PHP Shindig and Java one is using "userid", and both Poco and OpenSocial spec will use "userid". However, personally I'm fine to use userId instead - please let me know about the decision, thus I could ping Joseph Smarr to modify Poco's definition, and I'll modify Shindig implementation as well. On 2009/12/01 16:50:45, Lane LiaBraaten wrote: > On 2009/12/01 10:37:35, Jacky.Chao.Wang wrote: > > userId -> userid > > I thought we explicitly changed to camelcase userId. Why do you suggest all > lowercase userid?
Sign in to reply to this message.
On Mon, Dec 7, 2009 at 12:45 AM, <Jacky.Chao.Wang@gmail.com> wrote: > Hi Jon and Lane, > > How's the progress? I'll try to split the xml schema part out and put > them into these 2 files. > Please review the XSD I've drafted for the Core-API-Server.xml. The thread is here: https://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thr... Thanks, Lane > > Thanks, > Jacky > > > > http://codereview.appspot.com/154120/diff/4016/3033 > File draft/Social-Data.xml (right): > > http://codereview.appspot.com/154120/diff/4016/3033#newcode683 > draft/Social-Data.xml:683: non-empty value for either username or > userId, and MAY contain both, in > According to the document here: > http://spreadsheets.google.com/ccc?key=rUzMVUM2azeJAW3EouN1dCQ > > Both PHP Shindig and Java one is using "userid", and both Poco and > OpenSocial spec will use "userid". > > However, personally I'm fine to use userId instead - please let me know > about the decision, thus I could ping Joseph Smarr to modify Poco's > definition, and I'll modify Shindig implementation as well. > > > On 2009/12/01 16:50:45, Lane LiaBraaten wrote: > >> On 2009/12/01 10:37:35, Jacky.Chao.Wang wrote: >> > userId -> userid >> > > I thought we explicitly changed to camelcase userId. Why do you >> > suggest all > >> lowercase userid? >> > > http://codereview.appspot.com/154120 >
Sign in to reply to this message.
The following shall be included in the next patch set. http://codereview.appspot.com/154120/diff/4016/3034 File draft/Core-Data.xml (right): http://codereview.appspot.com/154120/diff/4016/3034#newcode130 draft/Core-Data.xml:130: always returned in the "list" field of the result. Lists can either be the On 2009/12/01 10:37:35, Jacky.Chao.Wang wrote: > in the "entry" field? OK http://codereview.appspot.com/154120/diff/4016/3034#newcode134 draft/Core-Data.xml:134: returned. The paging mechanisms described here are based on the OpenSearch OK, and added reference http://codereview.appspot.com/154120/diff/4016/3034#newcode139 draft/Core-Data.xml:139: "result : {" Done http://codereview.appspot.com/154120/diff/4016/3034#newcode288 draft/Core-Data.xml:288: <section title="Rules for mapping JSON to XML" On 2009/12/01 10:37:35, Jacky.Chao.Wang wrote: > Moving the samples mapping from application/json representation to XML > representation and application/atom+xml representation in > "REST-API.xml#dataRepresentations" to here? Not done yet. http://codereview.appspot.com/154120/diff/4016/3033 File draft/Social-Data.xml (right): http://codereview.appspot.com/154120/diff/4016/3033#newcode11 draft/Social-Data.xml:11: <title>OpenSocial Data Specification (draft)</title> On 2009/12/01 10:37:35, Jacky.Chao.Wang wrote: > "OpenSocial Social Data Spec" - counterpart towards "OpenSocial Core Data Spec" > for Core-Data.xml OK http://codereview.appspot.com/154120/diff/4016/3033#newcode376 draft/Social-Data.xml:376: <ttcol align="left">Description</ttcol> On 2009/12/01 10:37:35, Jacky.Chao.Wang wrote: > sort the attributes? :) Done for all types. http://codereview.appspot.com/154120/diff/4016/3033#newcode376 draft/Social-Data.xml:376: <ttcol align="left">Description</ttcol> On 2009/12/01 10:37:35, Jacky.Chao.Wang wrote: > currentLocation: > The field currentLocation is deprecated in 1.0 in favor of the standard location > field, but is included for backwards compatibility. currentLocation will be > fully removed in a future version of the spec. Ok http://codereview.appspot.com/154120/diff/4016/3033#newcode376 draft/Social-Data.xml:376: <ttcol align="left">Description</ttcol> On 2009/12/01 10:37:35, Jacky.Chao.Wang wrote: > hasApp: > Boolean value indicating whether the user has application installed. Since this table has the types, I have typically left out the phrase "Boolean value" for all the descriptions. http://codereview.appspot.com/154120/diff/4016/3033#newcode683 draft/Social-Data.xml:683: non-empty value for either username or userId, and MAY contain both, in I went ahead and did the lower case, since that is the way it is in the current documents. If we need to go back, let me know. http://codereview.appspot.com/154120/diff/4016/3033#newcode748 draft/Social-Data.xml:748: <c>type</c> On 2009/12/01 10:37:35, Jacky.Chao.Wang wrote: > remove "type" since it has been defined in Core-Data.xml. OK, and done on other typically plural field types. http://codereview.appspot.com/154120/diff/4016/3033#newcode944 draft/Social-Data.xml:944: <c>The salary the person receieves from the organization</c> On 2009/12/01 10:37:35, Jacky.Chao.Wang wrote: > organization "." :) OK http://codereview.appspot.com/154120/diff/4016/3033#newcode955 draft/Social-Data.xml:955: <c>type</c> On 2009/12/01 10:37:35, Jacky.Chao.Wang wrote: > remove "type" since it has been defined in Core-Data.xml. OK
Sign in to reply to this message.
Changes due to comments from #8, also rebased to latest version
Sign in to reply to this message.
Notes for patchset 9: All the changes in patchset 8 have been checked into svn. Patchset 9 is simply the delta from 8 to 9.
Sign in to reply to this message.
On 2009/11/24 18:27:48, Jon Weygandt wrote: > On 2009/11/24 17:31:49, Lane LiaBraaten wrote: > > So userId, activityId, etc. are all "Object-Id" (defined as Local-Id / > > Global-Id) - sounds good to me. > > I hope so! it sounds reasonable from reading various descriptions of the fields. We still need to define some special cases: User-ID = "@me" / Object-ID Group-ID = "@self" / "@friends" / "@all" / Object-ID Message-Collection-ID = "@inbox" / "@outbox" / Object-ID In each section we should describe what each of he special values means.
Sign in to reply to this message.
On 2009/12/09 22:19:00, Lane wrote: > On 2009/11/24 18:27:48, Jon Weygandt wrote: > > On 2009/11/24 17:31:49, Lane LiaBraaten wrote: > > > So userId, activityId, etc. are all "Object-Id" (defined as Local-Id / > > > Global-Id) - sounds good to me. > > > > I hope so! it sounds reasonable from reading various descriptions of the > fields. > > We still need to define some special cases: > > User-ID = "@me" / Object-ID > Group-ID = "@self" / "@friends" / "@all" / Object-ID Oops...we already have Group-ID We need to standardize on -ID or -Id. I don't feel strongly for either, but right now we have Object-Id and Group-ID. We should also define Array in Core-Data. We have a Collection object for responses rom the container, but there are lots of places where request accept lists of IDs or Objects. Having one place where we way what an Array is and how it maps between JSON, Atom, and XML would be good. -Lane > Message-Collection-ID = "@inbox" / "@outbox" / Object-ID > > In each section we should describe what each of he special values means.
Sign in to reply to this message.
On 2009/12/09 18:00:17, Jon Weygandt wrote: > Notes for patchset 9: > > All the changes in patchset 8 have been checked into svn. Patchset 9 is simply > the delta from 8 to 9. Thanks for your great job, Jon! The whole doc looks nice to me. Just 2 things: a) JSON->XML->Atom; b) put split XML schemas into Social-Data.xml. I will probably work on item #b, however since I'm not quite familiar with XML, it may take some time + make some bugs.... Thanks! - Jacky
Sign in to reply to this message.
Added new types and applied them. Defined field types for Message.
Sign in to reply to this message.
Per the discussion going on, I have the special types for Person, App, Group and Message Collection. Since most of those definitions did not exist in previous document, I created them. I welcome review of the definitions. Message was without specific types, as it was in V0.9 documents. I used my judgment in applying types, once again I welcome a review. There were a few other places where strings went to a type "URL" and other small changes. If you just want to see the type changes, look at the diff relative to patchset 9.
Sign in to reply to this message.
http://codereview.appspot.com/154120/diff/12001/12003 File draft/Core-Data.xml (right): http://codereview.appspot.com/154120/diff/12001/12003#newcode135 draft/Core-Data.xml:135: <c>@appId represents the application specified in the remove "@appId" http://codereview.appspot.com/154120/diff/12001/12002 File draft/Social-Data.xml (right): http://codereview.appspot.com/154120/diff/12001/12002#newcode295 draft/Social-Data.xml:295: <c>Array <<eref target="./Core-Data.xml#Object-Id">Object-Id</eref>></c> should be of type Message-Collection-ID http://codereview.appspot.com/154120/diff/12001/12002#newcode695 draft/Social-Data.xml:695: <c>string</c> should be of type User-Id (or Person-Id)
Sign in to reply to this message.
On 2009/12/10 19:18:52, Lane LiaBraaten wrote: > http://codereview.appspot.com/154120/diff/12001/12003 > File draft/Core-Data.xml (right): > > http://codereview.appspot.com/154120/diff/12001/12003#newcode135 > draft/Core-Data.xml:135: <c>@appId represents the application specified in the > remove "@appId" > > http://codereview.appspot.com/154120/diff/12001/12002 > File draft/Social-Data.xml (right): > > http://codereview.appspot.com/154120/diff/12001/12002#newcode295 > draft/Social-Data.xml:295: <c>Array <<eref > target="./Core-Data.xml#Object-Id">Object-Id</eref>></c> > should be of type Message-Collection-ID > > http://codereview.appspot.com/154120/diff/12001/12002#newcode695 > draft/Social-Data.xml:695: <c>string</c> > should be of type User-Id (or Person-Id) LGTM +1. Thank you Jon!
Sign in to reply to this message.
Hi All, Any updates? Have them been submitted? :D Cheers, - Jacky On 2009/12/12 11:51:15, Jacky.Chao.Wang wrote: > On 2009/12/10 19:18:52, Lane LiaBraaten wrote: > > http://codereview.appspot.com/154120/diff/12001/12003 > > File draft/Core-Data.xml (right): > > > > http://codereview.appspot.com/154120/diff/12001/12003#newcode135 > > draft/Core-Data.xml:135: <c>@appId represents the application specified in the > > remove "@appId" > > > > http://codereview.appspot.com/154120/diff/12001/12002 > > File draft/Social-Data.xml (right): > > > > http://codereview.appspot.com/154120/diff/12001/12002#newcode295 > > draft/Social-Data.xml:295: <c>Array <<eref > > target="./Core-Data.xml#Object-Id">Object-Id</eref>></c> > > should be of type Message-Collection-ID > > > > http://codereview.appspot.com/154120/diff/12001/12002#newcode695 > > draft/Social-Data.xml:695: <c>string</c> > > should be of type User-Id (or Person-Id) > > LGTM +1. Thank you Jon!
Sign in to reply to this message.
|
