I think @gobengo 's patch is probably the correct way to deal with this issue. It adds support for xsd:anyURI, but does not remove Object as a potential range. That will allow the correct use (a type id) in this property, but not make unusable any existing implementations that use Object instead.

I propose merging @gobengo 's patch.

(Discussed on today's SWIGCG call)
+1 I think it's standard procedure to do what Ben's proposing in cases where document/code/schemata are accidentally more constrictive than (or don't match) spec requirements, i.e. allow intended behavior (in this case, anyURI but ideally valid types only) but not break implementations already built with unintended behavior (in this case, putting in a whole object).

I would also recommend renaming this issue and leaving it open in case a new version of AP spec gets chartered down the road, as the unintended behavior should be deprecated in future spec and removed from future Context.