Redundancy of dimensions?

[zeginis]

At the structure of the table format are defined the "free_dimensions", the "locked_dimensions" and the "all_dimensions".

Do we need to define the "all_dimensions"?
Is there cases that "free_dimensions" + "locked_dimensions" != "all_dimensions" ?

[RickMoynihan]

You're absolutely right - we can certainly change this, though the redundancy was deliberate.

I'm pretty much on the fence about this, but the reasoning was to provide a single stable place for applications to look for a list of all the dimensions. For example most applications will want to resolve dimension labels and will therefore need to either check free_dimension and failing that locked_dimensions, or merge the two together into all_dimension_values anyway.

It is also a little more explicit about how to get all_dimensions if you're not knowledgeable of cubes.

I appreciate it's not exactly a big helping hand doing this, but I felt that as most applications will need to do this already we might as well help them a bit. The redundancy of transmission here didn't bother me too much...

One other option that might be nicer is providing free_dimensions and locked_dimensions as @sets of their prefixed identifiers. The big downside to this approach is that @sets aren't first class in JSON so applications wishing to interpret free/locked dimensions would have to find them by a linear search on an array rather than an associative object lookup.

I'm beginning to think you're right though and that we shouldn't denormalise them, as we don't denormalise other things...

What do you think?

[zeginis]

• The format should contain the free_dimension and the loked_dimensions in order to justify how the slice was created from the original cube
• If applications need all the dimensions they can use the API call GET /dimensions
• I don't understand how the @set option works

I am thinking that we may need to include somehow a link at the original cube. This will enable applications to switch between slices. I added a relevan issue #15