Further questions on Management wd04

[Ted Ross <tross@redhat.com>]

David, Rob,

Thanks again for the new working draft.  I have some follow-on questions about the QUERY operation:

My main concern is about the "entityTypes" key being optional and it being a list.  This means that zero or more entityTypes can be involved in the query.  This leads to a couple of difficulties:

• Pagination and ordering must be valid over the entire set of entities held within the agent, such that multi-type queries can be paginated.
  
• If there are multiple entity types in the request and the "Attributes" key (now optional) is omitted, how will the requestor know what attributes are being returned?  If there is a single entity type in the request, the requestor could possibly use the results of GET-ATTRIBUTES to interpret the data (though that would require some text in the spec).

Even though the minutes from the last call state that I am happy with the ability to query multiple types, I believe I was referring to the ability to query parent classes to get child class data.

I am satisfied with the text "...restricts the list of Manageable Entities requested to those that implement (directly or indirectly) the given Manageable Entity Type" from the description of "entityTypes".  This means that, if given a single entityType, the agent will return the requested attributes from all entities of that type and of derived types (i.e.  Query the names and depths of all types of queues).

Having a list of entityTypes means I can ask for the names of all queues and links which is arguably meaningless, but I need to implement it anyway to be compliant.  It's like a general-purpose JOIN query (without a selector).

I think QUERY would be much simpler if "entityTypes" was made single (list => string) and was mandatory.  Then there would be a way to interpret "all attributes" (when Attributes is omitted) and pagination would be scoped to a particular type (or sub-tree in the type hierarchy).

-Ted