should a Resource's "version" properties be optional when model's maxversions=1 ?

[duglin]

Pro: hides the version attributes from the serialization (stickyversionid, defaultversionid, defaultversionurl) Con: if they ever need a url to the version they would need to query the versions collection to get it, it would no longer be available as a property of the Resource.

@deissnerk

[deissnerk]

Perhaps we need to make up our minds, if retrieving the default version should be just like retrieving any other version, or if it should always require special handling by the client. Right now, some special handling is required, as also the id field reflects the resource id and not the version id.

[duglin]

I wonder if we need to find a better wording for what "the Resource" is, rather than just "it's the default version". It's sort of an alias. This concept isn't unique, even git has it... branch names remain the same while the underlying file it points to changes. Same as a Resource's id. The only diff is that with git the branch name doesn't appear as part of the underlying data. So, maybe we just need to find the best wording to describe it, but saying "it's the default version" might not be accurate enough.

You said "some special handling is required"... I'd like to explore that some more. If a client doesn't wish to know about versioning at all and ignores all version related attributes on the Resource's metadata, what special processing do they do? Ideally, none because they should be able to read or write the Resource and have those changes reflected on the current "default version" w/o really knowing about the indirection. What special processing did you have in mind?

[duglin]

On the 7/16 call we decided that for consistency we'll always have/show them on the Resource.