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

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

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


Subject: Re: Why 'class' appears in RESTPML URIs


Oh, I see where you're coming from.  The base SPML spec doesn't  
prevent a single PSO from being associated with multiple classes  
(supported schema entities).  In fact, the DSML Profile states  
explicitly that each PSO must belong to "one or more object classes".

Not everything is as flexible as LDAP, and most implementations that I  
have seen "flatten out" LDAP's inheritance structure and expose, say,  
"Person" or "Employee" and "Customer" rather than "inetOrgPerson" or  
some subclass of it), but nothing requires one that you must flatten.

Here's how I imagine it would play out.

Each class that you exposed in your schema for a target should be  
supported as a URI within that target:
- the URI that represents a superclass would contain all instances of  
that superclass.
- a URI that represents a subclass would contain only instances of  
that subclass.

If a given object belonged to more than one class, then that object  
would be reachable through each of those classes:
- A client could search the superclass URI using any attribute that  
the superclass exposes.
    -- NOTE: This would include the "objectclass" attribute.
    -- This allows one to search within the superclass for instances  
of a subclass.
- if a subclass exposes additional attributes, then a client could use  
those attributes when searching the subclass URI.

Exposing the class as a container makes a lot of sense for targets  
where the types of objects are disjoint.
- For LDAP, this might seem a little "inside-out", because LDAP has of  
course an orthogonal notion of containment (the DIT).
- SPML's sweet-spot, though, is representing generically all kinds of  
objects on all kinds of backend targets.

If you don't feel like exposing every structural objectclass in LDAP  
as a supported schema entity (e.g., as an SPML-DSML object-class),
you can still support searching within a generic container or a  
superclass container for instances of a specific LDAP object-class:
- In an extreme case, you could expose only a single class (e.g.,  
"Object").
- As long as class Object exposes the "objectclass" attribute, a  
client can search on it.

In summary, then, I think it's up to the provider to decide which  
classes (supported schema entities) it exposes.

What kind of use-case did you have in mind?

Gary

On Jul 18, 2011, at 2:57 PM, Tom Zeller wrote:

> Would it be possible for an object to be located by more than one  
> class_id ?
>
> In other words, is this analogous to a multi-valued ldap objectclass ?
>
> On Mon, Jul 18, 2011 at 2:53 PM, Gary Cole <gary.cole@oracle.com>  
> wrote:
>> Changing subject to better reflect content.
>>
>> On Jul 18, 2011, at 2:38 PM, Gary Cole wrote:
>>
>>> Excellent question!  We did not discuss that.
>>>
>>> The idea is to represent each object as an instance within some  
>>> class.
>>>  Each class is in effect a namespace within which names (or  
>>> identifiers)
>>> must be unique.
>>>
>>> SPMLv2 specifies that the PSOID must be unique within a target.   
>>> However,
>>> many applications do not expose unique internal identifiers.  For  
>>> these
>>> applications, the only identifier may be name, which may be unique  
>>> only
>>> within type.  (RACF is this way, for example. At the UI level,  
>>> everything is
>>> by name, and names are unique only within type.). For such  
>>> targets, the
>>> PSOID is actually a combination of object-class and name.  To do  
>>> the same
>>> thing RESTfully, the most natural way is to treat the class as a  
>>> namespace.
>>>
>>> Representing each class as a namespace also makes it easier to  
>>> support
>>> SEARCH.  Search is simply a GET on the container; the search  
>>> filter is
>>> specified as request parameters.  Search predicates must refer to  
>>> attributes
>>> that the objects have; the class usually defines these  
>>> attributes.  This
>>> makes it seem even more natural to search on the class-object,  
>>> since the
>>> class-object provides meta-data object for all instances of the  
>>> class.
>>>
>>> Does this make sense?  Would another scheme seem more natural to  
>>> you?
>>>
>>> On Jul 18, 2011, at 1:47 PM, Tom Zeller wrote:
>>>
>>>>> - No one has looked at it yet.
>>>>
>>>> Without implying anything positive or negative, why is "class" in  
>>>> the
>>>> URIs ? What functionality does it provide ?
>>>>
>>>> Apologies for being late to the call if this was already discussed.
>>>>
>>>> TomZ
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this mail list, you must leave the OASIS TC  
>>>> that
>>>> generates this mail.  Follow this link to all your TCs in OASIS at:
>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>>>
>>>
>>
>>



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