By way of summary: when purging an object from a 3.0 repository, triples
that contain empty literals (i.e. "") are not deleted. For example, add
an object with an empty label, delete the object, the triple for the
label remains.

Originally, I treated this as a problem of failing to delete triples. 
Having thought about this some more, I think the problem is in fact that 
we are creating triples that we oughtn't.

According to the FOXML schematron, the object label is optional. The 
FOXML serializer omits the attribute entirely from the serialization if 
the object label is null or empty. So, I'm now inclined to conclude that 
the problem is that the Resource Index shouldn't have indexed this 
property to begin with. Unfortunately, there's some further 
inconsistency in our code around this. For example, the FOXML 
deserializer will render an absent (i.e. null) object label as an empty 
string.

So I think the thing here is to try and be consistent. I do think an 
empty object label should be treated as a null, as that seems to support 
the case of desiring to remove an object label but not forcing users to 
have to pass in the existing object label on a modify operation when the 
label is not the property that wants changing (I'm going to restrain 
myself from picking on this aspect of the API for at least the duration 
of this email).

BUT, before I make changes to DefaultManagement and DefaultDOManager to 
store an empty object label as null, I'd like to know if there's some 
other reason to keep things as they are that I'm not considering.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Fedora-commons-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers

Reply via email to