On 12/17/2009 01:54 PM, Vincent Massol wrote:
On Dec 17, 2009, at 1:48 PM, Vincent Massol wrote:
Hi devs,
We need to decide if we want to keep the current:
ResourceName, DocumentName, SpaceName, WikiName, AttachmentName
or instead use a variation.
There are 2 things to decide:
- The prefix for the base object (Resource, Item, Model, etc)
- The suffix (Name, Path, Reference, etc)
Proposal
=======
I'd like to propose ModelReference for the base object and then
DocumentReference, SpaceReference, WikiReference, AttachmentReference.
I'm not sure about ModelReference. We also need to think about the
Type, which would be ModelType.
Model isn't such a good name, since a Model doesn't represent an
"object".
So either we keep Resource which isn't too bad (even though I was
feeling it's a bit too generic since we could the notion of Resource
in the REST API too and in other APIs) or find another better name (I
couldn't find one). Item or Node would be the JCR way of naming it.
Thanks
-Vincent
"Reference" is the best name. "Name" is not that good, since it
suggests
only a name, while in reality it will have other properties, like
language and version,
"Model" is too generic. Resource sounds better. How about Entity?
> Note: This is different from Identity which is
unique (a UUID).
> References do not point to unique objects.
>
> Reference makes sense to me since it means what it means... :)
> For example the API: Document getDocument(DocumentReference) is
> pretty clear IMO.
>
> Path is too physical to me. In JCR it's called getPath() but it
> returns a string with a path, for ex "/wiki/space1/space2/document".
> This is not our case. IMO our Reference would transform into a path
> when serialized only.
>
> Name isn't too bad, it would be my second choice. But it doesn't
> show the fact that it's a ... reference... ;)
>
> WDYT?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/