Description for the user id field

[Jon]

In modifying the specification I noticed conflicting descriptions for
the User ID of Person.

From the REST-API: http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/REST-API.html#personFields

"This identifier MUST be unique across this user's entire set of
people, but MAY not be unique across multiple users' data."

From OpenSocial Specification:
http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/OpenSocial-Specification.html#rfc.section.4.1.1.1

"The user ID must only contain alphanumeric (A-Za-z0-9) characters,
underscore(_), dot(.) or dash(-), and must uniquely identify the user
in a container."

One says "may not be unique in the container" the other says "must be
unique", so which is right? One would think unique wrt container, but
someone took the time to add the clause for the REST-API.

Plus, unless someone objects, due to lack of concrete definition, I
propose dropping the sentence "Note that there will likely be a size
limit placed on user IDs to help manage storing IDs in a database."

[Lane LiaBraaten]

Userids must be unique...not sure what that 'may not' clause is trying to accomplish.

Yes, please drop the 'we might do this in the future' clause.  In general, the spec should be in the present tense (E.g. the server responds with..., not 'the server will respond with'), so any prose in future tense should raise a flag.

-Lane

--

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=.

[Jon]

Hope I captured most of the "implied intent" in the change:
http://codereview.appspot.com/154120/diff2/4001:3021/3023
Search for the block starting with "Domain-Name".

I think I could add some words about uniqueness for Local-Id, such as:

option 1) A Local-Id SHALL uniquely specify a single object within the
scope of the implementation.

option 2) Given an object type, a Local-Id SHALL uniquely specify a
single object within the scope of the implementation.

variant) An object SHALL have only one Local-Id. Since Local-Id is a
string, simple equality tests withing the scope of the id shall be
enough to determine if the id refers to the same or different object.

Personally I like 2, but don't think that is very practical and could
break many implementations. So we will probably have to go with 1.

I do think we should try to implement the variant as that would allow
simple processing of the ids w/o having to actually fetch the object
and do more complex comparisons.

Once we decide, I'll also apply the same constraints to Domain-Name,
and by extension to Global-Id.

[Lane LiaBraaten]

How about we go with #1 (unique ID per object type) and RECOMMEND #2 (unique ID across all objects).

-Lane

--

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.

[Jon]

What about the "variant" and id refers to one object, and one object
has one id.

It's really only workable if we make it a MUST.

I would like to make it a MUST. Think about this simple use case. A
gadget developer wants to know if the viewer and owner are the same,
how do they do it? compare IDs? Only works if the mapping is one-to-
one. Otherwise they would have to fetch both viewer and owner's data
and do a deep comparison.

On Nov 25, 9:28 am, Lane LiaBraaten <lliab...@google.com> wrote:
> How about we go with #1 (unique ID per object type) and RECOMMEND #2 (unique
> ID across all objects).
>
> -Lane
>

> > opensocial-and-gadg...@googlegroups.com<opensocial-and-gadgets-spec%2Bunsu...@googlegroups.com>
> > .

[Lane LiaBraaten]

yes - one object has one id.  A developer should be able to check if viewer == owner by comparing their ids.

I thought the scenario we were talking about was more related to if it's okay to have John's user id = 1234, and also have some activity out there with activity id = 1234.

-Lane

To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.

[Jon]

On Nov 25, 11:02 am, Lane LiaBraaten <lliab...@google.com> wrote:
> yes - one object has one id.  A developer should be able to check if viewer
> == owner by comparing their ids.
>
> I thought the scenario we were talking about was more related to if it's
> okay to have John's user id = 1234, and also have some activity out there
> with activity id = 1234.

This was "option 2"

[Lane LiaBraaten]

right, so I think it's okay if this happens, but we should recommend that it doesn't happen. 

[Jon]

With 5 +1 votes, time to commit.

There are some outstanding requests, but I can do them as a delta to
the committed version. Plus it will be easier to review.

I still need to do some research, these are simply bullet points for
now:
*) The Addition of Body-Type for Person
*) An Email type referencing rfc3986
*) A URL type with a LINK_TEXT field

Plus Id type updates per discussion:
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/451fed78b86304f8#