Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (herse.apache.org: domain of ole.ersoy@gmail.com designates
 64.233.166.176 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=BV/Eks5lqfSy/SUB8dIno4oXeQo2CVqpB+zll2i4H3HnV6Ax0sUCPSKTe/g3w7/xOzWwNqraCQh3gU4jh+gnS+vWzwslEBbh897OyjG5tBsJbr1L9Jvhdpo73DFOOo/556fpbnLCjZL1+t9706qnBYImYR1yDT1LrJRtQUoqls0=
Message-ID: <462BE44F.8030403@gmail.com>
Date: Sun, 22 Apr 2007 17:40:15 -0500
From: Ole Ersoy <ole.ersoy@gmail.com>
User-Agent: Thunderbird 1.5.0.10 (X11/20070302)
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [DAS] Type's ObjectClass Entry
References: <462AAD20.2080201@gmail.com>
 <462AB396.30201@stefan-seelmann.de>	 <462AC841.90206@gmail.com>
 <462B2AAD.2080909@stefan-seelmann.de>	 <462B8F89.8010400@gmail.com>
 <a32f6b020704221455v4e2c1b34v347bd154a340dd79@mail.gmail.com>
In-Reply-To: <a32f6b020704221455v4e2c1b34v347bd154a340dd79@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Alex,

Thanks for all the additional material on search
related considerations.  Good stuff.
I'm keeping it in my parking lot, so I can
come back to it once I have the ability to
write and restore datagraphs.

SNIP

> 
>     ============
>     WRITE OPERATION
>     ============
> 
>     The part where I need the additional "metaObjectClass"
>     is during the writing and restoration of
>     metadata.
> 
> 
> So when you use meta you mean meta in the DAS meta data sense and not 
> the meta schema sense in ApacheDS right?

Well - let me approach it like this.  I'll tell you
what I was planning to do, and then we can discuss
the proper terminology for it.

When I define the ObjectClass that corresponds
to each DataObject instances type (Class), I need
to define the Type's simple properties (Which use
the already available "m-must" and "m-may" meta AttributeType
entries.

Then I also need to define members that correspond to 
ComplextProperties.  For instance the employee has a
a complex property reference to a Department.

Does that make sense.  However ApacheDS's current metaObjectClasses
(the ones that are used to define other ObjectClass entries like
Department and Employee) don't have anything like
"m-complexMust" or "m-complexMay" so I was going to define these
on something in an ObjectClass entry maybe called metaSDOObjectClass
and then add this as an "objectClass" attribute when I'm defining
the ObjectClasses for Department and Employee.

I don't have to put this ObjectClass with ADS's metaObjectClasses.
I can make a new schema area for the DAS and add it there.  I think
that's what you are wondering about?

SNIP

> Makes sense this is like the DDL you need to apply to add tables in an 
> RDBMS before adding the records.

Yes
SNIP

> 
> 
> Ok so you're reconstructing the ecore model from the LDAP schema here.  
> It's finally making sense to me now.  Let me know if I am incorrect.

Right On!

SNIP

> 
> 
> Yeah it makes sense to me but I would not start mixing our meta schema 
> stuff with your mechanism for modeling required/optional references to 
> complex objects.  Use something domain specific.  For example create an 
> attribute in Employee called "department" or "departmentId" 

Well - we don't have to mix ADS metaObjectClasses (metaTop, 
metaObjectClass, etc.) with the DAS one.  I can put it in a custom
schema area for the DAS.  Sound ok?

So when defining the ObjectClass for Employee, I would
add all simple properties using the metaObjectClass's
"m-must" and "m-may" attributes.

However, I would also add the ObjectClass metaSDOObjectClass,
enabling me to use "m-complexMust" and "m-ComplexMay" for the
complex properties.  Make sense?  Before you answer,
you may want to have a look
at the example I gave at the bottom.


SNIP

> See what I'm saying? Just stop trying to use the meta.schema terms for 
> this.  It's not worth it first of all and secondly it's not going to 
> work because of collisions and typing issues.  Meaning if you have a 
> Address complex type now for the Employee then you get a collision where 
> you cannot use m-complexMust for it. 

I'm sorry Alex - Maybe I'm missing something.  As far as I can see the 
semantics are the same as for simple properties / attributes that use 
"m-must" and "m-may".

So for instance the Employee could have "m-complexMust" attributes

- Address
- Department
- Parking
- etc.

When constructing the ObjectClass for Employee these would be added
using Attributes like this:

new BasicAttribute("m-complexMust", "com-example-Employee-address".

new BasicAttribute("m-complexMust", "com-example-Employee-department".

new BasicAttribute("m-complexMust", "com-example-Employee-parking".

And the simple properties like name, etc. would be added like this:

new BasicAttribute("m-must", "com-example-Employee-name".

etc.

Does that make sense?

Thanks,
- Ole