Alex,
Alex Karasulu wrote:
SNIP
Well if you just check the attributeType of the attribute in the m-may
or m-must list you can discern this easily. It's just an additional
lookup and the proper way to go. Use the type of the attribute to
understand what to do with the attribute. This is how LDAP works.
Yes - I considered this initially. Me still thinks that using
the "m-ComplexMay" and "m-ComplexMust" is cleaner semantically
and will perform better. Me thinks
clearer semantics improves the ability of
others to improve the implementation.
SNIP
No it's not about minor differences. You're just not comprehending how
LDAP schema is to be used. This is the whole reason why those smart
peeps in the ITU and IETF defined a attributeType. It's something
fundamental to LDAP and you're just not using it with your approach.
Plus you're mixing a bunch of things together.
Oh - Sorry - Yes we are still defining AttributeType entries,
for "m-ComplexMay" and "m-ComplexMust" ObjectClass attribute.
We are also defining corresponding syntaxes.
How about this. I'll try it out. If I'm missing something. I'll
get smacked. Then I'll rework it your way. I just think it's a simpler
design with "m-complexMay" and "m-complexMust".
Man I'm not interested in smacking you I'm just trying to save you time
and give you the answers to your question.
Hehe - Come on - One Goodd Smack! :-) Kidding. I know - I meant I'll
get smacked
by the approach, since stuff that does not work, just does not work.
Incidentally the SDO JSR takes your approach. They define everything as
a Type. So no EAttribute and EReference. They are both just Type. I
still like the additional semantics behind EAttribute and EReference, so
I'll give it a shot. Maybe I'll get burnt, and then you can tell me "I
told you so!" :-)
That's up to you and I don't care if I am right really. I'm just
responding to your questions. You don't have to take my advice if you
don't want to. But man are you stubborn :).
Hehe. Yeah, when I think I have a fairly good grip on why something
should go a certain way I tend to go with it, unless someone presents
a simple verifiable reason why it should be different. And I do this
with everyone. I know you are extremely sharp on this stuff.
In this case I think the two approaches are very close. I think from
ADSs point of view, it will look the same.
I'll just push it through and we'll see what happens. I think once the
code is in place it's a lot easier to discuss because we have
concrete sequences to work through, plus I'm going to rewrite all the
design recipes in the Design Guide once everything is in place, so
that I backup why certain things were done a certain way. This provides
a good context for discussions on improvement on each piece of the DAS.
My original motivation for asking this question was to find out whether
there was something in place already, outside of "m-must" and "m-may"
that I could use and whether there were any totally clear show stoppers
for "m-complexMay" and "m-complexMust".
Sorry if this absorbed more of it's fair share of everyone's
consideration. Originally I thought it was going to be a quicky :-)
Thanks again,
- Ole
