> PaceDateModified2 deliberately doesn't prohibit this, nor does this > prevent the proposal from fulfilling its goal to provide a temporal > ordering for entry instances.
Dave: I'm pretty much +0 on PDM2, as I've mentioned previously. Your modifications to the concept address my "this will break stuff" concerns with the original formulation, so I'm okay with however it works out. But I have a question, and I'm asking you specifically because you seem to be approaching your argument in a reasonable tone and fashion. My apologies if I'm pestering. Near as I can tell, folks have modification dates. In my case, that is a date that is updated every time the user clicks "save". In Tim's case, that is a date that he chooses. In other apps, that may be a date that matches when a new comment was added to a blog entry. Nothing in the spec is going to change these realities. And none of these approaches are *wrong*, or invalid. We each get to define "change" in our own apps, so we can approach atom:modified's MUST clause as we see fit. For all practical purposes, it doesn't matter whether folks use atom:updated or atom:modified. You're going to get the same date. With that in mind, what are the actual benefits of atom:modified over atom:updated? The end result will always be identical, unless I'm missing a crucial, well-hidden point. Please note that it has not escaped me that this cuts both ways. Why fight for atom:updated over atom:modified when it is beyond the scope of the Atom spec to define the nature of change in the universe? Hey, if Tim doesn't consider a typo a real modification, then it just isn't. Period. It's his writing, his app, and he defines the rules and the terms. The more I look at this, the more I see people fighting over phantoms. -- Roger Benningfield
