OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

amqp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Fwd: [Fwd: [management] Name and Identity - too much?]


From Alan Conway...


-------- Forwarded Message --------
Subject: [Fwd: [management] Name and Identity - too much?]
Date: Tue, 25 Nov 2014 09:39:55 -0500
From: Alan Conway <aconway@redhat.com>
To: Ted Ross <tross@redhat.com>





--- Begin Message ---
[Tried to send this last week but not properly subscribed...]

I have an issue with: name and identity in the current spec:

  The user MUST supply unique name, system MUST supply unique identity.

This raises some problems:
- It is redundant to require 2 unique identifiers for each management
entity.
- It imposes unreasonable complexity on the user to require unique names
for every entity type.

Providing unique names is not trivial for the user, since more than one
user may independently create entities. It needs some form of central ID
management, UUIDs, application namespaces or other technique. Many
entity types have no need for an additional key attribute beyond the
system-generated "identity" so the effort of generating one is wasted.
Conversely some applications might may need more than one
application-defined searchable key for some entity types.

Proposal:
1. Drop the special "name" attribute, keep "identity" as presently
specified.
2. Add attribute-based query, allow the user to query based on whatever
attributes they wish.

Attribute-based query could be an extension to the QUERY operation or a
new operation. 

The simplest possible query is simply an attribute name X and a string
value V, meaning find any entity who's attribute X == V. That would be
sufficient to replace the current "name" attribute, but already more
flexible (User can locate objects by "partNo", "upcCode" or whatever
they wants, and can query by more than one attributes.)

Obviously we could extend this to more complex query expressions
allowing multi-attribute queries etc. If we
can settle on one that suits everybody that would be ideal. Another
possibility is to introduce a "query-type" attribute on the query
operation, where all MUST implement the simple name/value query, but MAY
use query-type to indicate an extension query languages or future
specifications MAY define more sophisticated queries.

Cheers,
Alan.


--- End Message ---


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]