-
Notifications
You must be signed in to change notification settings - Fork 265
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Normalized [previously canonical] format #1007
Comments
One possiblity so clients can specify they want the info in cannonical way is to use the
|
This pseudo-test harness should be taken into account when implementing this issue (only the part related with canonical model): |
Another posibility for the options parameter would be
|
Better terms has been suggested:
|
The changes mentioned in #1259 will implement this in a different way. Closing. |
Feature/key values01
In order to ease the programming of clients that need a uniform format for attributes, an option could be passed to the GET operations that render that information, so attribute and metadata will be using always an structure with value, type and metadata (in the case of attributes) or value and type (in the case of metadata).
E.g. non-canonical:
would be:
The text was updated successfully, but these errors were encountered: