directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: [DAS] Type's ObjectClass Entry
Date Sun, 22 Apr 2007 23:22:03 GMT

On 4/22/07, Ole Ersoy <> wrote:
> 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.

My pleasure.

> >
> >     ============
> >     ============
> >
> >     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.

Buddy I can't be wasting cycles these days dancing around these things.
Otherwise I would write the DAS me self :).  Basically let's stop mixing two
separate aspects of this problem.  I don't want to waste cycles this way but
to spend my time giving you exactly what you need to succeed.

> 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.

This is exactly what I mean.  Why are you creating a metaSDOObjectClass?  Is
this a meta schema object?  Man I am not this mentally nimble.

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?

No I just don't want to be mixing the jargon here because it's totally
confusing me and is unnecessary.  Sorry if this sounds harsh but I have very
little time these days due to various issues.  Trying to make time spent in
from of count :).

> >
> > 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?

I still think you're mixing stuff here together in terms of the concepts.  I
think you're trying to create general objectClasses for representing any DAS
object.  I'm trying to tell you to stay away from that since you can create
custom domain specific objects since you're generating this stuff anyway.
So let's not create any objectClasses with metaXYZ in it or any m-
attributes in it.   Maybe I am missing something you're saying all together

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.


> > 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.

Yes you are missing a lot.

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?

What I am saying is you don't need to do this at all.  I think you're
missing some big concepts.   When you define the employee object class and
need an attribute to reference the department complex object just use the
m-must or m-may attributes.   Say this attribute is called
com-example-Department.  If you create the attributeType definition for this
then you can define the syntax for this complex object reference to be
anything you want.  So you control the type of the object that way not by
defining a m-mayComplex attribute type at the meta level.

That's it. These m-may and m-must attributes work for any kind of attribute
with any kind of syntax you may define.  This m-mustComplex m-mayCOmplex
stuff is absolutely useless.

Sorry about my frustration but I feel like I'm spending a lot of time and my
words are not describing things well enough for you to understand.


View raw message