Subject: Re: Date Options Survey

From: "Arve Bersvendsen" <[email-masked]>
Date: Sun, 25 Jul 2004 13:14:05 +0200

* Roger Benningfield:
> If an MT user puts mutable dates in issued and you put immutable dates in
> issued, how is the consumption of your feed compromised by the consumption
> of the MT user's feed? 

What if you track millions of feeds, and want to do something potentially
useful to them, and every generator out there assigns their own meaning to
it?  If you knew that MT assigned one meaning, where the date was only a
fancified version of 'Created'. For LJ, this date was always equal to
'modified', for JournURL, this was actually 'first-issued' (read: immutable).
Add 10 to 15 generators down the line using one of the already mentioned
dates.

You'd end up having to write a generator-sniffing mess to do anything useful
with the data.

---

From: Sam Ruby <[email-masked]>
Date: Sun, 25 Jul 2004 12:48:09 -0400

> You'd end up having to write a generator-sniffing mess to do anything useful

Arve, I believe that Roger is asking a question based on what he has 
directly observed with existing blogging tools and existing formats.  I 
believe it to be a valid question.

It is hoped that a format that is  cleanly and thoroughly specified, and 
containing elements for concepts that correspond to what people already 
is doing anyway, would improve situations.

- Sam Ruby

---

From: "Roger B." <[email-masked]>
Date: Sun, 25 Jul 2004 13:13:21 -0500

> it?  

Arve: See, this is where I think we're having a fundamental disconnect.
That's not a "what if"... that's the way it is.

I produce all kinds of feeds. A single entry can show up in a dozen
different places, targeted at different needs. If I'm forced to provide an
issued date, then that date will be pulled from different fields depending
upon context. In a blog feed, the closest thing I have is the entry's
"published" date. In a forum feed, the closest date would be "created".
Right there, in a single app, you've got two potential origins for data that
ends up in a single element.

When I insert a date into an element, I'm not promising you that the date
came from an internal field with a spec that exactly matches Atom's. I am
asserting that you should use it for the purposes described in the spec.
That's it, and nothing more. The harder it is for me to make accurate
assertions, the harder it will be for consuming applications to satisfy
their users.

Note that this is not an argument in favor of allowing mutable dates in
"issued". If folks need "issued" to be immutable, hey, no problem. But if
you require that I provide such an element, see above for details.

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 25 Jul 2004 21:28:39 +0200

On Sun, 25 Jul 2004 13:13:21 -0500, Roger B. <[email-masked]>  
wrote:

> different places, targeted at different needs. If I'm forced to provide  
> an issued date, then that date will be pulled from different fields  
> depending upon context.

The tools you use might not stamp the resources they issue with the time  
of issuance, but is there a good reason why these tools will _never_ do  
it? Absolutely all tools on the planet need to issue the resource to put  
it onto the web. That's how it gets there. If it's not issued, it's not on  
the web. If it issues stuff, why is it impossible to give that action a  
timestamp which goes with the issued resource?

> In a blog feed, the closest thing I have is the entry's "published" date.
> In a forum feed, the closest date would be "created".

Both forum posts and blog entries are issued.

> assertions, the harder it will be for consuming applications to satisfy

So, if it is harder than today to give accurate metadata about your  
entries, _consumers_ will suffer? I don't understand this. If anything,  
it's the consumers, and not the publishers, who gain on having high  
quality data in the feeds.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»