From: "Chris Kaler (Exchange)" <ckaler@Exchange.Microsoft.com>
I disagree that DASL is the right approach. The different "types" of
history are really about semantic interpretation by the store. I don't
believe this can be expressed in DASL short of using an attribute.
I also don't believe that content negotiation is viable. What if the report
was a document that it, itself, could be subject to content negotiation.
It seems, to me at least, that a property attirbute or multiple properties
is still the best way to go. The later means an "explosion" of properties
(n * m).
I share your resistance to the (n*m) property explosion. But
if you use property attributes, what would an "allprop" propfind return?
The property with no attributes specified? In case the property is a
"limit" property, that means the default would be "unlimited" which is
the most expensive form of the property. Or no property?
Note: I happen to think "allprop" is an abomination that should be put
out of its misery. So I am not suggesting that problems with allprop
should have much weight, but until allprop is expunged from the spec,
we do have to deal with its implications.
If we end up concluding that a DASL/propfind approach does not work,
I'd suggest that we define a "history" resource, and define headers
for querying against it. This avoids both the property explosion and
the allprop problems.
Cheers,
Geoff