search

HydraCG / Specifications

Specifications created by the Hydra W3C Community Group
Other
139 stars 25 forks source link

Rename readonly/writeonly to readable/writeable #14

Closed lanthaler closed 9 years ago

lanthaler commented 10 years ago

We currently have two properties in the Hydra vocabulary which I'm not entirely happy with yet: hydra:readonly and hydra:writeonly. I think more and more that renaming them to hydra:readable and hydra:writeable would make them easier to work with.

The reason why I gave them this name in the first place was because I thought that it is only necessary to explicitly set them if a property is either readonly or writeonly but that's not entirely true due to the open world assumption Hydra is based on. If it's not set, you can't assume it is set to false. You have to accept that you don't know what value it has.

The advantage of renaming them would be that the inconsistency which is cause if something is marked as both read- and writeonly would be eliminated and programming against them would become easier. Apart from introducing a breaking change (which is still quite cheap at this point in time) I don't see any downside of the change but maybe I miss something.

elf-pavlik commented 10 years ago

:+1: on changing to readable/writeable

nice to see that you keep open-world assumption in mind :smile:

mikehaertl commented 10 years ago

I'm quite new to this spec and have to agree that this was my first thought when reading the specs: "What happens if both readonly and writeonly are set?".

So :+1: for a change.

lanthaler commented 10 years ago

Thanks @mikehaertl for sharing your opinion. I saw you already joined the Community Group. We typically keep all our discussion on the mailing list and not in the issues. Thus, all feedback/proposals/etc. should normally be send to public-hydra@w3.org

lanthaler commented 10 years ago

PROPOSAL: Rename readonly/writeonly to readable/writeable. In general, try to describe why something should be documented from the client's perspective and how it is supposed to be interpreted if it isn't specified. For example, a client is free to try to send any property, but if writable=false it will know that the server will ignore it.

gkellogg commented 10 years ago

+1

If readable and writable both set to false, its similar to having cardinality set to 0, or removing the class from the domain of the property. When listing supportedProperties of a class, these can safely be excluded (although the constraint that sets readable and writable to false may remain).

lanthaler commented 10 years ago

Call for consensus: http://lists.w3.org/Archives/Public/public-hydra/2014Jul/0082.html

lanthaler commented 10 years ago

RESOLVED: Rename readonly/writeonly to readable/writeable.