[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: >= (greater or equal) and <= (lower or equal) operators in

Pierangelo Masarati writes:
>>>> I would love to and I'm about to throw in the towel and "break" this
>>>> standard schema by adding this (and other) rules. A broken or
>>>> difficult standard is of no use.
>>> Then just design your own, or propose a draft for standard emendation,
>>> but don't hijack others, or you'll run into interoperability problems,
>>> sooner or later.
>> True, but sometimes the attributes are needed for another application
>> which expects a particular attribute name like uidNumber (e.g. PAM, I
>> think).  Then you'd have to store that other attribute in _addition_
>> to uidNumber.
>> Or you could make your own schema with the same attribute names, object
>> class names etc. as the Pam schema, but with your own OIDs and with the
>> matching rules you want.  That's 'formally' OK - unless the RFC2307
>> attribute names are registered with IANA - and a bit cleaner than
>> modifying the original schema, but still rather ugly, I guess.
> Or one could design a new attribute that inherits from the old one
> PLUS the ordering match; inheritance wwould let the new attribute be a
> valid replacement for the old one without even hanging a line of code
> (except where writes occur, of course) and add the new feature (an
> mess everything up, of course).

Depends on how the attribute is used.  If you then add the new attribute
instead of the old one, searches for both the old and the new attribute
would succeed.  However, the old attribute will not be present in search
results, and old applications that expect to receive the old attribute
will not recognize the new one.