- From: Rotan Hanrahan <rotan.hanrahan@mobileaware.com>
- Date: Mon, 25 Feb 2008 18:29:28 -0500
- To: <public-ddwg@w3.org>
- Message-ID: <D5306DC72D165F488F56A9E43F2045D3017E2CE8@FTO.mobileaware.com>
(Possible final comment on this from me for a few hours, as it's getting late.) Again with thanks to Jo for prompting this thought, there is yet another approach. The implementation-side interface for an instance of evidence is not visible in the Simple API because it is implementation specific. Yet it is important that the retrieval contract is established when passing such an instance as a parameter. How can this contract be guaranteed by the Simple API? There is a way. Each implementation of the SimpleService class could also provide a factory that creates evidence objects. The factory can thus ensure that whatever is produced will adhere to the retrieval contract. The external developer merely obtains a blank evidence object via the factory and populates it with evidentiary information. (Or this raw info could be given as data to the factory method.) The object produced by the factory should still adhere to a visible external contract for populating it with data. We could call this interface "Evidence" and it should have a put method. (The object could also implement additional population methods but those would be on a per-implementation basis. Always room for a bit of improvement.) Now, on the way back in, as a parameter in a getPropertyValue method, this same evidence object would also have to implement the back-end retrieval contract. We don't have to provide any details about what is in this contract. For me, I'm happy to look at this hidden retrieval contract as the one called Admissible. This interface doesn't even have to be mentioned in the Simple API definition. It's only known to the implementation of the factory and the query methods. The external developer doesn't need to know about it. So we may have a solution to this issue if we use a factory method in the SimpleService to create evidence objects. And now I'm disconnecting... ---Rotan.
Received on Monday, 25 February 2008 23:29:48 UTC