- From: Babich, Alan <ABabich@filenet.com>
- Date: Wed, 22 Jul 1998 13:25:00 -0700
- To: "'Yaron Goland'" <yarong@microsoft.com>, w3c-dist-auth@w3.org
> If the client copies the resource to a server which doesn't > know about the > system date property then the property will be dead. That is, the > destination server will not uphold the expectation that the > retrieved value > will equal the current system date. Rather the server will act like a > notepad, recording the value of the property when it was > copied and not > changing it after that point. OK. So I misunderstood dead properties, because I only concentrated on section 3.1. A datetime property, originally live (a), could possibly be copied to another collection and become dead, but its datatype would apparently have to be preserved, because you could retrieve the value of the dead copy of the property. Right? But maybe not. Maybe string-izing it and saving it as a string is sufficient to act like a notepad? If datatype must be preserved on a copy, dead properties are not necessarily strings -- apparently they can theoretically be practically any datatype. Right? Since the dead property's name is exactly the same, but its semantics changed (the dead copy of the current date no longer tracks the date), I am somewhat uncomfortable. It doesn't seem like it is exactly the same property. If the datatype can change on a dead copy (say, from a datetime to a string), then I'm even more uncomfortable. Can live (b) properties (e.g., Age In Years) become dead on a copy? If the datatype has to be preserved on a copy, then I would say no. If not, then yes? Alan Babich
Received on Wednesday, 22 July 1998 16:29:14 UTC