Ole,

On 4/22/07, Ole Ersoy <ole.ersoy@gmail.com> 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.

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.


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 gmail.com 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 thoh.

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.  

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. 

Alex