Re: API Server Specs (issue163096)

[weitze...@gmail.com]

In the CORE-API-SERVER, the text reads (line 142):
"The protocol defines Activity, Person, Group, and AppData resources.
Most operations consist of retrieving (GET), updating (PUT), creating
(POST or PUT), or destroying (DELETE) these resources. It also specifies
an optional partial update feature which avoids sending large resources
over the wire to update just one field."

Since these are social concepts, shouldn't this be in the
SOCIAL-API-SERVER or am I confused and wandering aimlessly looking for
wood?


http://codereview.appspot.com/163096

[Lane LiaBraaten]

I've taken that line out...you're not wandering :)

[api.ll...@gmail.com]

Hi Folks,

I just uploaded a new patch set with a completed draft of the
Social-API-Server spec. There are lots are missing/wrong links right
now so don't worry about them, but the content is ready for your review.

Core:
http://www.opensocial.org/Technical-Resources/draft/Core-API-Server.xml
Status:
http://www.opensocial.org/Technical-Resources/draft/Social-API-Server.xml

You can also view what's left of the REST spec (the RPC spec has been
completely assimilated...mwahahaha). Most of the content has been moved
to the *-API-Server and *-Data specs, but there is some stuff left that
I want to make sure get's covered in the *-Data specs.

http://www.opensocial.org/Technical-Resources/draft/REST-API.xml

If you have specific feedback it's best to use the code review tool and
leave me comments inline. If you have general feedback that's fine
too...just post it on the list.

Thanks,
Lane

http://codereview.appspot.com/163096

[Jacky.C...@gmail.com]

Thanks for your great effort!!

Just my 2 cents:
- for the JSON / XML / ATOM mapping part, we need to move it to
Core-Data.xml, which is modifying by Jon (cc'ed Jon in).
- for the xml schemas for person/activity/..., it might be great to be
broke down to small pieces.
- let's submit an alpha version after all the big changes are done -
then we could do the second iteration on small changes - there should be
many small bugs we need to fix, and the whole OpenSocial community could
help a hand on reviewing the draft.

Great Job, Lane!

Thanks,
- Jacky


http://codereview.appspot.com/163096/diff/3007/3011
File Core-API-Server.xml (right):

http://codereview.appspot.com/163096/diff/3007/3011#newcode351
Core-API-Server.xml:351: <list style="symbols">
You may like to replace the following part with:

<texttable>
<ttcol align="left">Json Query Object</ttcol>
<ttcol align="left">URL Parameter</ttcol>
<c>{ "field" : "value" }</c><c>field=value</c>
<c>{ "field" : [1,2,3,4,5]}</c><c>field=1,2,3,4,5</c>
<c>{ "field" : "12" }</c><c>field='12'</c>
<c>{ "field" :
[identifier,anotheridentifier]}</c><c>field=identifier,anotheridentifier</c>
<c>{ "field" : ["value","another
value"]}</c><c>field=value,"another value"</c>
<c>{ "field" : ['value','another
value']}</c><c>field=value,'another value'</c>
<c>{ "field" : { "nested" : "value" }}</c><c>field.nested=value</c>
<c>{ "field" : [{ "nested1" : "value1" }, { "nested2" : "value2"
}]}</c><c>field(0).nested1=value1&amp;field(1).nested2=value2</c>
</texttable>

http://codereview.appspot.com/163096/diff/3007/3011#newcode1817
Core-API-Server.xml:1817: &lt;xs:element name="isFiltered"
type="xs:boolean" /&gt;
filtered

http://codereview.appspot.com/163096/diff/3007/3011#newcode1818
Core-API-Server.xml:1818: &lt;xs:element name="isSorted"
type="xs:boolean" /&gt;
sorted

http://codereview.appspot.com/163096/diff/3007/3011#newcode1819
Core-API-Server.xml:1819: &lt;xs:element name="isUpdatedSince"
type="xs:boolean" /&gt;
updatedSince

http://codereview.appspot.com/163096/diff/3007/3010
File Social-API-Server.xml (right):

http://codereview.appspot.com/163096/diff/3007/3010#newcode1406
Social-API-Server.xml:1406: &lt;xs:element minOccurs="0" name="nickname"
type="xs:string" /&gt;
add after:
&lt;xs:element minOccurs="0" name="note" type="xs:string" /&gt;

http://codereview.appspot.com/163096/diff/3007/3010#newcode1466
Social-API-Server.xml:1466: &lt;xs:element minOccurs="0"
name="extendedAddress" type="xs:string" /&gt;
remove

http://codereview.appspot.com/163096/diff/3007/3010#newcode1470
Social-API-Server.xml:1470: &lt;xs:element minOccurs="0" name="poBox"
type="xs:string" /&gt;
remove

http://codereview.appspot.com/163096/diff/3007/3010#newcode1492
Social-API-Server.xml:1492: &lt;xs:element minOccurs="0" name="endDate"
type="xs:dateTime" /&gt;
add
&lt;xs:element minOccurs="0" name="location" type="xs:string" /&gt;

http://codereview.appspot.com/163096/diff/3007/3010#newcode1505
Social-API-Server.xml:1505: &lt;xs:element minOccurs="0"
name="additionalName" type="xs:string" /&gt;
remove

http://codereview.appspot.com/163096/diff/3007/3010#newcode1510
Social-API-Server.xml:1510: &lt;xs:element minOccurs="0"
name="formatted" type="xs:string" /&gt;
add
&lt;xs:element minOccurs="0" name="middleName" type="xs:string" /&gt;

http://codereview.appspot.com/163096/diff/3007/3010#newcode1732
Social-API-Server.xml:1732: &lt;/xs:schema&gt;
Still think that it might be a good way to break the above big xml down
into small pieces and insert them into the Social-Data.xml...

http://codereview.appspot.com/163096

[Jacky.C...@gmail.com]

http://codereview.appspot.com/163096/diff/3007/3011
File Core-API-Server.xml (right):

http://codereview.appspot.com/163096/diff/3007/3011#newcode967
Core-API-Server.xml:967: <t>The actual content included in the
response.</t>
As we've discussed in the Core-Data.xml part, the "core-data" only
describes the definition of "collection" and "entry", yet leave the
discussion on "what should be return, collection, entry, or error
message" here.

Your point in group's thread is a good example actually:

==========
A Core API Server will always return a <response> element, which will
have
one of three things in it:
1) an <entry> element, which could contain anything
2) a collection, which has a group of elements like <startIndex> and
<isSorted>, followed by a number of <entry> elements for the items in
the
collection (or no <entry> elements if the collection is empty)
3) a <invalidationKeys> element, which contains at least one
<invalidationKey> element.
==========

http://codereview.appspot.com/163096

[Jon]

Regarding JSON/XML/ATOM mapping: Agreed, we should have it somewhere.
Does it already exist? I saw Jacky's comment on the Core-Data and
started looking but have not yet found it. Or at least it is not
obvious to me.

Jon

[Lane LiaBraaten]

http://www.opensocial.org/Technical-Resources/draft/Core-Data.xml#JSON-to-XML

We need to add Atom.  There are lots of examples in the old REST spec - some of which may be useful in the Social-Data spec.  Where the general mapping rule apply I think we can skip the example, but in cases where we're doing some ad hoc mappings (mostly in the Atom representations) it'll be good to have examples.

-Lane 

Jon

--

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-an...@googlegroups.com.
To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.

[api.ll...@gmail.com]

Thanks for the review Jacky!

http://codereview.appspot.com/163096/diff/3007/3011
File Core-API-Server.xml (right):

http://codereview.appspot.com/163096/diff/3007/3011#newcode351
Core-API-Server.xml:351: <list style="symbols">

On 2009/12/09 13:09:18, Jacky.Chao.Wang wrote:
> You may like to replace the following part with:

> <texttable>
> <ttcol align="left">Json Query Object</ttcol>
> <ttcol align="left">URL Parameter</ttcol>
> <c>{ "field" : "value" }</c><c>field=value</c>
> <c>{ "field" : [1,2,3,4,5]}</c><c>field=1,2,3,4,5</c>
> <c>{ "field" : "12" }</c><c>field='12'</c>
> <c>{ "field" :

[identifier,anotheridentifier]}</c><c>field=identifier,anotheridentifier</c>
> <c>{ "field" : ["value","another
value"]}</c><c>field=value,"another
> value"</c>
> <c>{ "field" : ['value','another
value']}</c><c>field=value,'another
> value'</c>
> <c>{ "field" : { "nested" : "value"
}}</c><c>field.nested=value</c>
> <c>{ "field" : [{ "nested1" : "value1" }, { "nested2" : "value2"
> }]}</c><c>field(0).nested1=value1&amp;field(1).nested2=value2</c>
> </texttable>

Much better. Thanks!

http://codereview.appspot.com/163096/diff/3007/3011#newcode967
Core-API-Server.xml:967: <t>The actual content included in the
response.</t>

On 2009/12/09 13:25:34, Jacky.Chao.Wang wrote:
> As we've discussed in the Core-Data.xml part, the "core-data" only
describes the
> definition of "collection" and "entry", yet leave the discussion on
"what should
> be return, collection, entry, or error message" here.

> Your point in group's thread is a good example actually:

> ==========
> A Core API Server will always return a <response> element, which will
have
> one of three things in it:
> 1) an <entry> element, which could contain anything
> 2) a collection, which has a group of elements like <startIndex> and
> <isSorted>, followed by a number of <entry> elements for the items in
the
> collection (or no <entry> elements if the collection is empty)
> 3) a <invalidationKeys> element, which contains at least one
> <invalidationKey> element.
> ==========

This is covered by the individual server, which defines the
Return-Object for each method. For example,
Social-API-Server.xml#People-Service-GetPerson defines Return-Object =
Person. I'e added some text to clarify this.

However, this doesn't account for the root <response> tags, so I've
added that to Core-API-Server.xml#REST-Response.

Similarly, Core-API-Server.xml#RPC-Response defines the root response
structure in JSON (e.g. { "id" : "myrequest", "result" : <Some-Object> }

http://codereview.appspot.com/163096/diff/3007/3011#newcode1817
Core-API-Server.xml:1817: &lt;xs:element name="isFiltered"
type="xs:boolean" /&gt;

On 2009/12/09 13:09:18, Jacky.Chao.Wang wrote:
> filtered

Done.

http://codereview.appspot.com/163096/diff/3007/3011#newcode1818
Core-API-Server.xml:1818: &lt;xs:element name="isSorted"
type="xs:boolean" /&gt;

On 2009/12/09 13:09:18, Jacky.Chao.Wang wrote:
> sorted

Done.

http://codereview.appspot.com/163096/diff/3007/3011#newcode1819
Core-API-Server.xml:1819: &lt;xs:element name="isUpdatedSince"
type="xs:boolean" /&gt;

On 2009/12/09 13:09:18, Jacky.Chao.Wang wrote:
> updatedSince

Done.

http://codereview.appspot.com/163096/diff/3007/3010
File Social-API-Server.xml (right):

http://codereview.appspot.com/163096/diff/3007/3010#newcode1406
Social-API-Server.xml:1406: &lt;xs:element minOccurs="0" name="nickname"
type="xs:string" /&gt;

On 2009/12/09 13:09:18, Jacky.Chao.Wang wrote:
> add after:
> &lt;xs:element minOccurs="0" name="note" type="xs:string" /&gt;

Done.

http://codereview.appspot.com/163096/diff/3007/3010#newcode1466
Social-API-Server.xml:1466: &lt;xs:element minOccurs="0"
name="extendedAddress" type="xs:string" /&gt;

On 2009/12/09 13:09:18, Jacky.Chao.Wang wrote:
> remove

Done.

http://codereview.appspot.com/163096/diff/3007/3010#newcode1470
Social-API-Server.xml:1470: &lt;xs:element minOccurs="0" name="poBox"
type="xs:string" /&gt;

On 2009/12/09 13:09:18, Jacky.Chao.Wang wrote:
> remove

Done.

http://codereview.appspot.com/163096/diff/3007/3010#newcode1492
Social-API-Server.xml:1492: &lt;xs:element minOccurs="0" name="endDate"
type="xs:dateTime" /&gt;

On 2009/12/09 13:09:18, Jacky.Chao.Wang wrote:
> add
> &lt;xs:element minOccurs="0" name="location" type="xs:string" /&gt;

Done.

http://codereview.appspot.com/163096/diff/3007/3010#newcode1505
Social-API-Server.xml:1505: &lt;xs:element minOccurs="0"
name="additionalName" type="xs:string" /&gt;

On 2009/12/09 13:09:18, Jacky.Chao.Wang wrote:
> remove

Done.

http://codereview.appspot.com/163096/diff/3007/3010#newcode1510
Social-API-Server.xml:1510: &lt;xs:element minOccurs="0"
name="formatted" type="xs:string" /&gt;

On 2009/12/09 13:09:18, Jacky.Chao.Wang wrote:
> add
> &lt;xs:element minOccurs="0" name="middleName" type="xs:string" /&gt;

Done.

http://codereview.appspot.com/163096/diff/3007/3010#newcode1732
Social-API-Server.xml:1732: &lt;/xs:schema&gt;

On 2009/12/09 13:09:18, Jacky.Chao.Wang wrote:
> Still think that it might be a good way to break the above big xml
down into
> small pieces and insert them into the Social-Data.xml...

Agreed. I'll work with Jon to make this happen.

http://codereview.appspot.com/163096

[api.ll...@gmail.com]

Just uploaded a new patch with all the links fixed. Pull out the
fine-toothed comb and let me know if you find any tangles.

Thanks,
Lane

http://codereview.appspot.com/163096

[snoo...@gmail.com]

In the Social API Server specification there are empty headings for
creating people and lists of fields. Those are not things that have been
in previous OpenSocial specifications, except as examples intended "to
show how additional operations that a container may want to support can
be defined within this framework" [1]

I don't think provisioning of new users and creating of friendships is
really something we want Gadget developers to do and even if we do want
such a thing, don't we have a lot to do to standardize the relationship
creation flow, relationship types, etc.?

I think we should strike these headings from the document:

4.1.4 Retrieve a list of deleted friends
4.1.5 Create a Person
4.1.6 Update a Person
4.1.7 Delete a Person
4.1.8 Create a list of Friends
4.1.9 Update a list of Friends
4.1.10 Delete a list of Friends

Am I off base here in saying the above are new capabilities and thus
should not be included in 1.0?

For groups we currently have these also empty headings:

4.2 Groups
4.2.1 Create a list of Groups
4.2.2 Retrieve a list of Groups
4.2.3 Update a list of Groups
4.2.4 Delete a list of Groups

We never had Group creation or update in any previous version of the
specs (as far as I know). So, when I propose the Group changes, I'll
believe I will be changing these headings to something more like this:

4.2 Groups
4.2.2 Retrieve a list of Groups
4.2.4 Retrieve a Groups

Sound OK?

- Dave


[1]
http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/RPC-Protocol.html#rfc.section.3.6



http://codereview.appspot.com/163096

[Lane LiaBraaten]

It's fuzzy -- but that's precisely why I wanted to spent this iteration clarifying stuff. Just moving all this content into a single file and being explicit has made it possible to discover these kind of issues, now we can decide what to do about them.

I also realized about halfway through drafting this response that I hadn't checked in the latest API-Server docs.  Now they're in:

SVN:http://code.google.com/p/opensocial-resources/source/browse/spec/draft/Social-API-Server.xml

Preview:http://www.opensocial.org/Technical-Resources/draft/Social-API-Server.xml

On Fri, Dec 11, 2009 at 12:26 PM, <snoo...@gmail.com> wrote:

In the Social API Server specification there are empty headings for
creating people and lists of fields. Those are not things that have been
in previous OpenSocial specifications, except as examples intended "to
show how additional operations that a container may want to support can
be defined within this framework" [1]

The v0.9 RPC spec defines create, update, delete methods for the each service (except messages, which only has 'send' :/ ).  The v0.9 REST spec has an overarching statement that says it uses GET, POST, PUT, DELETE, but noting specific per service.

What does each method do?  Which are required?  Unclear.

I think it's a good idea to define CRUD operations methods for all services.  If containers want to support these operations, we should encourage them to do so in a standard way.  

It seems reasonable to also say that get operations are required and create, update, delete are optional.   In the current draft, I've made the activities and messages services special cases where create is required as well.  Thoughts?

I don't think provisioning of new users and creating of friendships is
really something we want Gadget developers to do and even if we do want
such a thing, don't we have a lot to do to standardize the relationship
creation flow, relationship types, etc.?

Someone wanted it, cuz it's in v0.9 :/  I don't think it hurts to define these methods and call them optional.

http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/REST-API.html#rfc.section.7.1

Friends MAY be added by POSTing to the appropriate collection (e.g., /people/{guid}/@friends). Containers MAY require a dual opt-in process before the friend record appears in the collection, and in this case SHOULD return a 202 Accepted response, indicating that the request is 'in flight' and may or may not be ultimately successful. 

The RPC definition is even better..complete with typo.

http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/RPC-Protocol.html#rfc.section.9.2.2

Support creating opensocial.Activity objects as the targets of a relationship with the specified user, this is a generalization of many use cases including invitation, contact creation etc.

icky...this is why I keep asking for content reviews!!! 

I think we should strike these headings from the document:

4.1.4 Retrieve a list of deleted friends

agreed (though it is in the v0.9 REST spec - see the URI examples in PeopleService).

I'd be happy to axe @supportedFields as well (in favor of "@all").

 

4.1.5 Create a Person
4.1.6 Update a Person
4.1.7 Delete a Person

I'd like to keep these as optional

 

4.1.8 Create a list of Friends
4.1.9 Update a list of Friends
4.1.10 Delete a list of Friends

These last three are already gone.

Am I off base here in saying the above are new capabilities and thus
should not be included in 1.0?

Not off base.  Lots of stuff in v0.9 is a matter of interpretation.  Let's try to save our future selves from this ambiguity!

For groups we currently have these also empty headings:

4.2 Groups
4.2.1 Create a list of Groups
4.2.2 Retrieve a list of Groups
4.2.3 Update a list of Groups
4.2.4 Delete a list of Groups

We never had Group creation or update in any previous version of the
specs (as far as I know). So, when I propose the Group changes, I'll
believe I will be changing these headings to something more like this:

4.2 Groups
4.2.2 Retrieve a list of Groups
4.2.4 Retrieve a Groups

Sound OK?

I have a slight preference for defining the create, update, delete operations and marking them as MAY (though they should operate on a single group, not a list of groups).

- Dave


[1]
http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/RPC-Protocol.html#rfc.section.3.6

http://codereview.appspot.com/163096

[Dave]

On Fri, Dec 11, 2009 at 9:53 PM, Lane LiaBraaten <api.ll...@gmail.com> wrote:
> It's fuzzy -- but that's precisely why I wanted to spent this iteration
> clarifying stuff. Just moving all this content into a single file and being
> explicit has made it possible to discover these kind of issues, now we can
> decide what to do about them.

Yes. You've done a great job breaking things up, by the way.

> Someone wanted it, cuz it's in v0.9 :/  I don't think it hurts to define
> these methods and call them optional.
> http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/REST-API.html#rfc.section.7.1
> Friends MAY be added by POSTing to the appropriate collection (e.g.,
> /people/{guid}/@friends). Containers MAY require a dual opt-in process
> before the friend record appears in the collection, and in this case SHOULD
> return a 202 Accepted response, indicating that the request is 'in flight'

That's essentially what we implemented in SocialSite and I think it
works reasonably well. But, are we sure we want to elevate it from
(what appeared to me to be an) example to optional spec language? I
don't have a strong opinion here, I'm just making the point.

If we do that in the Social Server API, shouldn't we also do the same
in the JavaScript API? I think it's somewhat confusing when the
various flavors of the Social API do not have 100% parity.

Anyways... I'm not going to touch the people stuff now, but I will
take a shot at full CRUD for groups as you suggest.

Thanks,
- Dave

[Jacky.C...@gmail.com]

On 2009/12/11 20:26:16, snoopdave wrote:
> In the Social API Server specification there are empty headings for
creating
> people and lists of fields. Those are not things that have been in
previous
> OpenSocial specifications, except as examples intended "to show how
additional
> operations that a container may want to support can be defined within
this
> framework" [1]

> I don't think provisioning of new users and creating of friendships is
really
> something we want Gadget developers to do and even if we do want such
a thing,
> don't we have a lot to do to standardize the relationship creation
flow,
> relationship types, etc.?

> I think we should strike these headings from the document:

> 4.1.4 Retrieve a list of deleted friends

> 4.1.5 Create a Person
> 4.1.6 Update a Person
> 4.1.7 Delete a Person

> 4.1.8 Create a list of Friends
> 4.1.9 Update a list of Friends
> 4.1.10 Delete a list of Friends

> Am I off base here in saying the above are new capabilities and thus
should not
> be included in 1.0?

> For groups we currently have these also empty headings:

> 4.2 Groups
> 4.2.1 Create a list of Groups
> 4.2.2 Retrieve a list of Groups
> 4.2.3 Update a list of Groups
> 4.2.4 Delete a list of Groups

> We never had Group creation or update in any previous version of the
specs (as
> far as I know). So, when I propose the Group changes, I'll believe I
will be
> changing these headings to something more like this:

> 4.2 Groups
> 4.2.2 Retrieve a list of Groups
> 4.2.4 Retrieve a Groups

> Sound OK?

> - Dave


> [1]

http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/RPC-Protocol.html#rfc.section.3.6

LGTM +1. Thank you Lane!

http://codereview.appspot.com/163096

[Lane LiaBraaten]

On Fri, Dec 11, 2009 at 7:18 PM, Dave <snoo...@gmail.com> wrote:

On Fri, Dec 11, 2009 at 9:53 PM, Lane LiaBraaten <api.ll...@gmail.com> wrote:
> It's fuzzy -- but that's precisely why I wanted to spent this iteration
> clarifying stuff. Just moving all this content into a single file and being
> explicit has made it possible to discover these kind of issues, now we can
> decide what to do about them.

Yes. You've done a great job breaking things up, by the way.

> Someone wanted it, cuz it's in v0.9 :/  I don't think it hurts to define
> these methods and call them optional.
> http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/REST-API.html#rfc.section.7.1
> Friends MAY be added by POSTing to the appropriate collection (e.g.,
> /people/{guid}/@friends). Containers MAY require a dual opt-in process
> before the friend record appears in the collection, and in this case SHOULD
> return a 202 Accepted response, indicating that the request is 'in flight'

That's essentially what we implemented in SocialSite and I think it
works reasonably well. But, are we sure we want to elevate it from
(what appeared to me to be an) example to optional spec language? I
don't have a strong opinion here, I'm just making the point.

Sounds like we have two containers that have implemented it (SocialSite, orkut), so I think it's good to keep the language.

Anyone else have an opinion on this one?

Yeah...parity is good.  Now that the initial drafts of the Gadget and API Server specs are out I'll make a pass and make sure the service methods match up for the osapi and REST/RPC APIs.

-Lane

Anyways... I'm not going to touch the people stuff now, but I will
take a shot at full CRUD for groups as you suggest.

Thanks,
- Dave

[Jacky.C...@gmail.com]

Hi All,

Any updates? Have them been submitted? :D

Cheers,
- Jacky

On 2009/12/12 11:51:49, Jacky.Chao.Wang wrote:
> On 2009/12/11 20:26:16, snoopdave wrote:
> > In the Social API Server specification there are empty headings for
creating
> > people and lists of fields. Those are not things that have been in
previous
> > OpenSocial specifications, except as examples intended "to show how
additional
> > operations that a container may want to support can be defined
within this
> > framework" [1]
> >
> > I don't think provisioning of new users and creating of friendships
is really
> > something we want Gadget developers to do and even if we do want
such a thing,
> > don't we have a lot to do to standardize the relationship creation
flow,
> > relationship types, etc.?
> >

> > I think we should strike these headings from the document:
> >
> > 4.1.4 Retrieve a list of deleted friends

> > 4.1.5 Create a Person
> > 4.1.6 Update a Person
> > 4.1.7 Delete a Person

> > 4.1.8 Create a list of Friends
> > 4.1.9 Update a list of Friends
> > 4.1.10 Delete a list of Friends
> >

> > Am I off base here in saying the above are new capabilities and thus
should
> not
> > be included in 1.0?
> >

> > For groups we currently have these also empty headings:
> >
> > 4.2 Groups
> > 4.2.1 Create a list of Groups
> > 4.2.2 Retrieve a list of Groups
> > 4.2.3 Update a list of Groups
> > 4.2.4 Delete a list of Groups
> >
> > We never had Group creation or update in any previous version of the
specs (as
> > far as I know). So, when I propose the Group changes, I'll believe I
will be
> > changing these headings to something more like this:
> >
> > 4.2 Groups
> > 4.2.2 Retrieve a list of Groups
> > 4.2.4 Retrieve a Groups
> >
> > Sound OK?
> >