Subject: [scim] Filter syntax for attributes in extensions

From: Steve Moyer <[email-masked]>
Date: Wed, 9 Oct 2013 09:04:05 -0400 (EDT)

SCIM extensions are now defined using a top level JSON object that has a URN name and sub-attributes as defined by the extension's schema.  The API and schema specifications include one extension for attributes needed for an enterprise user.  When searching for users based on extension attributes, the use of URNs as attribute names leads to ugly filter "clauses".  If we're looking for enterprise users whose manager is "John Smith", one criteria the filter string will include will be:

urn:scim:schemas:extension:enterprise:2.0:User.manager.displayName eq "John Smith"

Is there something we can do to make this more readable?  Can we allow abbreviations for filter attributes so long as they're unambiguous for the producer's schema?  (In this case, manager.displayName might be all we'd need).  I've got some university specific values in an extension and while the lexer/parser has no problem using the longer form, it's a bit ugly for humans that come in contact with it.

Thanks,

Steve

---

From: Phil Hunt <[email-masked]>
Date: Wed, 9 Oct 2013 09:21:20 -0700

My understanding is you only have to use the full uri if displayName is ambiguous. 

Phil

> On Oct 9, 2013, at 6:04, Steve Moyer <[email-masked]> wrote:
> 
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Steve Moyer <[email-masked]>
Date: Wed, 9 Oct 2013 12:53:12 -0400 (EDT)

I know that section 3.2. (Multi-valued Attributes) of the API specification states:

"The attribute's significant value; e.g., the e-mail address, phone number, etc.  Attributes that define a "value" sub-attribute MAY be alternately represented as a collection of primitive types."

But the manager sub-attribute is not a primitive type within the enterprise user extension.  Can you point me to a reference in the specification that describes how attribute names can be shortened?  My current lexer/parser will pass either shortened or full names for attributes, but if we're going to allow shortening other types of attribute names (e.g. if the rule is anything that's not ambiguous is allowed), I'm going to need to decide where to convert synonyms to their optimal forms (in the lexer/parser or in the code that converts the expression tree to a LDAP query).  Either way it's a pretty big change!

Thanks,

Steve

----- Original Message -----
From: "Phil Hunt" <[email-masked]>
To: "Steve Moyer" <[email-masked]>
Cc: [email-masked]
Sent: Wednesday, October 9, 2013 12:21:20 PM
Subject: Re: [scim] Filter syntax for attributes in extensions

Phil