On 12/10/2014 08:21 AM, Brian Stansberry wrote:
On 12/10/14, 3:59 AM, Emmanuel Hugonnet wrote:
> Maybe we should also group attributes by their attribute group names instead of
displaying them per natural sorting ?
This is what I meant by
"4) Low level management API
The output of read-resource and read-resource-description is modified
such that attributes are sorted by group name and then by attribute name."
I used the verb "sorted" though because I have no intent of modifying
the output structure by creating a level for the attribute group. That
would be an incompatible change in the output format and would obscure
the distinction between an attribute group and a complex attribute.
FWIW I think this is a good distinction and a good approach.
> Is aliasing to be supported ? What if I want to change the
attribute group name ?
Heiko, I don't think Emmanuel is talking about users changing this. We
use aliasing in other contexts as a mechanism for maintaining
compatibility. If something is poorly named (e.g. a bad resource address
name) we can fix it in a later release but also register an alias under
the old name to provide compatibility.
I don't see how aliasing could work here. Only thing I can imagine is
using it in the ls -l output, such that the same attribute can appear >
1 times, if it is associated with more than 1 group. I suppose a console
could do a similar thing, but I don't at all regard maintaining that
kind of compatibility in UI layout to be a requirement.
I'm not sure how much we regard consistency in the ls -l output across
releases as being a requirement. I think of that as being an output
format for humans, not machines.
Aliasing is an example of a reason for allowing an attribute to belong
to more than one group. There may be others. Perhaps as an aid to querying?
I still feel strongly that we should look to real resource versioning as
the proper solution here, though I realize there has not been a
satisfactory resolution to this discussion. But the longer we don't
come to a resolution, the more (arguably questionable) tricks we have to
pull to manage compatibility.