Hmmm good question. I guess this leads to another question. Should we allow the user to create entries which have attribute values that are syntactically incorrect? And what does this do with respect to expected behavior for this Server side attribute verses a user side analog?
Originally I liked this idea. But after some time I started thinking this is not such a good idea. I think we should avoid adding too much functionality into this. Containment is the objective not syntax checking. We simply need a minimal amount of schema checking to prevent certain anomalies on the server side. However we should leave this function to the proper service whose role is explicitly dedicated towards fullfiling this function which it centralizes while considering all aspects. For example schema checking will be done by parts of the schema service which must consider a slew of aspects associated with this:
o concurrent changes to schema during checks (aka locking)
o configuration of schema checking: we might want to disable or relax certain syntaxes
The list goes on but I have to take off here. I hope you see what I mean here .. I don't want to have to be considering all these aspects and duplicating such functionality here in the Entry/Attribute API which is really there for composition of entries.
Further back on the issue of what users will expect in terms of behavior; we will have a divergence in behavior from the client and server versions of the API. We already have some divergence but this will be wider in that it will feel like the server is checking the user while things are being done. Where do we stop with schema checks then? If the answer is apply all schema checks then how do we deal with situations where the entry is inconsistent during composition but will be consistent at the end? For example you have an inetOrgPerson that requires sn and cn attributes. The user adds the objectClass attribute with the inetOrgPerson value into the Entry. If we have schema checks enabled then this user action will trigger a violation error. Likewise if they add sn or cn before they add the objectClass attribute since these attributes will not be in the must may list yet. So I think we open a Pandora's box if we try to overload too much functionality into this Entry/Attribute API whose primary purpose is with respect to managing entry composition.
I know we have to rely a bit on schema to do it right on the server side but let's keep this to a minimum to avoid anomalies.
just a quick Q :
we have many methods 'add' in this class. Should we always check that
the added value is syntaxically correct ? The current version does not
check this :
public boolean add( String val )
return values.add( new ServerStringValue( attributeType, val ) );
I suggest that we should write this method this way :
public boolean add( String val ) throws
if ( attributeType.getSyntax().isHumanReadable() )
return values.add( new ServerStringValue( attributeType, val
throw new InvalidAttributeValueException();