September 17, 2006
Problems with the ContextObject Model
In my last post, I said that there were too many subtle issues surrounding ContextObjects for me to be completely comfortable with them. In the end, though, I think we can do much to clarify these issues for advanced users, and hide them completely from novices.
After dismissing the Referrer and Resolver Entities as a ding and a toot in that post, let me revive them briefly as a case in point. Unlike the other Entities, I couldn't imagine convenient Q6 interrogative labels for these two. I don't think this is a coincidence. These two Entities serve a significantly different purpose from the remaining Entities that are dedicated to conveying the actual details of the request. Referrers and Resolvers are peculiar to the situation where these details can be decoupled from any particular resolver. The Resolver Entity in particular makes sense as a formalized conceptual model to represent this decoupling, but as far as I know we rarely ever expect them to be manifested in an actual ContextObject Representation. Instead, it is implied that independent intermediaries will generate a link to a local Resolver without regard to using or embellishing Resolver Entities. Referrers suffer from similar issues. Under the circumstances, I think it would have been clearer to create some structure within the ContextObject to segregate these two from the others. Now that I see this in print, though, I have to admit that this is mostly a quibble. Nevertheless, I think it's good for us to be aware of these things. Let's move on to more substantive problems.
ContextObjects are also befuddling because conventional ContextObject Representations often aren't adequate to represent them. I hinted at this in an earlier post. 1) Take data stored in cookies, for example. 2) As another example, a Referrer wouldn't generally fill in a ReferringEntity descriptor when it publishes a ContextObject Representation because that job is deferred to the intermediary that generates the Transport link. Even then, I don't see the need for the intermediary to add in such a descriptor to the links it generates because the Resolver might just as well pull this information from the HTTP 'Referer' header instead. 3) Likewise, a Resolver would be foolish to trust a naked Requester Entity that it finds in a ContextObject Representation. These are too easily spoofed. A more likely scenario is that a client would start with a request to an OpenURL authentication service with the userID and encrypted password descriptors in the Requester Entity. If these pass muster, I can imagine the Resolver storing that userID in a session object and automatically pulling it from there with every subsequent request, regardless of what the client might claim their userID to be in those subsequent ContextObject Representations.
The good news for ContextObjects is that all the problems in this last paragraph evaporate from the OpenURL Object Model POV. The difference is that the preceding analysis assumes the conventional network-level vantage point where ContextObject Representations must be platform- and language-independent and spoofing is a concern, whereas in OOM this isn't the case. OOM applies the OpenURL model at the machine level rather than the network level. Internal to OOM, the ContextObject Representation is always the OOM ContextObject class. The scenarios I listed that are treated with a wink and a nod by conventional ContextObject Representations can be treated with bona fide descriptors once the OOM Transport class has its say in the matter (i.e. pulling data from the network-level ContextObject Representation, cookies, sessions, and headers).
To summarize, it seems that it's not ContextObjects themselves that are the problem so much as it is the ContextObject Representations. In the Q6 model (like in most web applications), the ContextObject Representation is implied in the Transport (=Q6:"How") such that most people wouldn't notice it as a discrete component. I appreciate that the OpenURL committee saw fit to decouple it as an advanced feature, but I don't think we should go out of our way to promote it to beginners.