Subject: Re: Q: modfied vs issued vs created

From: Ken MacLeod <[email-masked]>
Date: 02 Jul 2004 16:09:35 -0500

Jonas Galvez <[email-masked]> writes:

>      0.3 Draft, Section 4.13.8
> 
>      "If atom:created is not present, its content MUST considered to be
>      the same as that of atom:modified."
> 
> I quite don't understand the difference between "issued" and
> "created".  I thought that "created" was the same as "issued", but
> apparently, it is the same as "modified"? Sorry if I'm distracting
> other more important threads, but I just think this point in the
> spec might be confusing for non native english speakers like
> me. Perhaps a special note detailing the actual meaning of these
> elements would clear it.

<issued> is nominally a user-provided value whereas <created> and
<modified> are publishing system provided values.

<issued> can be in the future, for example, to indicate, to a
publishing systems that supports it, that the entry should be
published at a future time.  <created> would still reflect the time
the entry was created.

<created> is logically the first value ever of <modified>, but if it's
missing you can use any current value of <modified>

This topic comes up often enough that it should be clarified in the
spec, particularly as clarifies interoperable behavior for clients and
servers.

  -- Ken

---

From: Antone Roundy <[email-masked]>
Date: Fri, 2 Jul 2004 15:08:29 -0600

On Friday, July 2, 2004, at 02:46  PM, Jonas Galvez wrote:
> I quite don't understand the difference between "issued" and "created".
> I thought that "created" was the same as "issued", but apparently, it
> is the same as "modified"?

Correct me if I'm wrong, but I think created is when the entry was 
first created, even if it wasn't published in the feed at that time.  
Issued is when the entry was first published in the feed.  Modified is 
when the last (non-trivial) change was made to the entry.  (This isn't 
entirely clear even to native English speakers).

While I'm writing, a few more questions for those who've been around 
longer than me.

* Why are the time zone requirements different for issued (time zone 
may be omitted--why allow that?) than created and modified?

* Why SHOULD the time zone be UTC?  If the author's time zone is used, 
that would imply where the author is located.  That could be considered 
overloading the meaning of the element, and it wouldn't be entirely 
reliable (is it the server's time zone or the author's?), but I don't 
see why it would hurt.

* Why are both issued and modified required? How common is it for an 
entry to be modified after it is first issued? I'm sure it's far from 
unheard of, but requiring both in all cases, whether they're the same 
or not, doesn't make sense to me.

---

From: Jonas Galvez <[email-masked]>
Date: Fri, 02 Jul 2004 17:46:58 -0300

I quite don't understand the difference between "issued" and "created".
I thought that "created" was the same as "issued", but apparently, it
is the same as "modified"? Sorry if I'm distracting other more important
threads, but I just think this point in the spec might be confusing for
non native english speakers like me. Perhaps a special note detailing
the actual meaning of these elements would clear it.

\\ jonas galvez
// jonasgalvez.com

---

From: Walter Underwood <[email-masked]>
Date: Fri, 02 Jul 2004 14:52:01 -0700

--On Friday, July 02, 2004 03:08:29 PM -0600 Antone Roundy 
<[email-masked]> wrote:
> reliable (is it the server's time zone or the author's?), but I don't see
> why it would hurt.

There might be some use for a native timezone for the blog, but
making sense of all that is a mess. Maybe I live in Atlanta, use
a blog service hosted in California, I'm in Australia on travel,
and you are reading the blog in Norway. What time is it when I post?
Is summer time in effect (N vs. S hemisphere)? Heck, what day is it?

I'd be willing to make UTC a MUST. A .NET implementation may need
to use UTC anyway, because System.DateTime doesn't have a time zone.
That is the official type for SOAP DateTime, so SOAP protocols
always need to use UTC for safe transfer of data. See:

 http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemDateTimeClassT
opic.asp

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 02 Jul 2004 23:54:57 +0200

On Fri, 2 Jul 2004 15:08:29 -0600, Antone Roundy <[email-masked]>  
wrote:

> Correct me if I'm wrong, but I think created is when the entry was first  
> created, even if it wasn't published in the feed at that time.  Issued  
> is when the entry was first published in the feed.

Not necessarily «in the feed», imho. <issued> indicates when the resource  
was first publicly available, either the first-class representation of it  
is an HTML document, PDF file, or an Atom entry. In large parts, I think  
one can assume that the Atom entry is considered a second-class  
representation of a resource, rather than the resource itself.  
Nonetheless, <issued> indicates when this resource (no matter what or  
where that resource is) was first made publicly available.

> Modified is when the last (non-trivial) change was made to the entry.

Correct. This is how I've explained the difference in numerous e-mails  
earlier:

The difference beetween 'issued' and 'created' is that an article can be  
created, edited for six years, and then published to a public web site.  
'created' is then the initial creation date, and 'issued' is the date of  
when the article was publicly available (created + six years in this case).

If you've ever used Movable Type, it has this feature. You create an entry  
(the 'created' date gets set), edit it for a couple of days, and then save  
it with the status «publish» (the 'issued' date gets set).

> * Why are the time zone requirements different for issued (time zone may  
> be omitted--why allow that?) than created and modified?

Dunno.

> * Why SHOULD the time zone be UTC?

Because UTC dates is a lot simpler to work with. Working forth and back  
with different time zones is a real mess if you don't keep your tounge  
straight. Storing the date as UTC and then rather just convert it to a  
local date on display, is much cleaner.

> If the author's time zone is used, that would imply where the author
> is located.

I don't find that very useful. GeoURL[1] or Bizg[2] are better solutions  
for locating feeds (or authors), imho.

> * Why are both issued and modified required?

Because they are interesting pieces of information. If you never modify  
the entry, it's no fuzz, is it? Just keep the <modified> element  
unchanged. If you never keep a local copy for updates before you make it  
publicly available, then <created> and <issued> will most likely always be  
the same. If you never modify the entry either, all three dates will stay  
the same. Does that hurt?

> How common is it for an entry to be modified after it is first issued?

Seeing how often I get rather old entries at the top of my subscription  
lists in my aggregator, I'd say rather often.

____
[1] <url: http://geourl.org/>
[2] <url: http://www.blizg.com/>

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

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 2 Jul 2004 15:28:41 -0700

At 5:46 PM -0300 7/2/04, Jonas Galvez wrote:
>Sorry if I'm distracting other more important
>non native english speakers like me.

Please don't apologize. If the spec is unclear on this (and as a 
native speaker of English, even I have a hard time keeping the three 
straight), it's perfectly reasonable to ask for clarification.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Jonas Galvez <[email-masked]>
Date: Fri, 02 Jul 2004 20:00:50 -0300

Ken MacLeod wrote:
 > <created> is logically the first value ever of <modified>, but if
 > it's missing you can use any current value of <modified>
 >
 > spec, particularly as clarifies interoperable behavior for clients
 > and servers.

Asbjørn Ulsberg wrote:
 > This has been explained on numerous occasions, but I'll do it again:
 > The difference between 'issued' and 'created' is that an article can
 > be created, edited for six years, and then published to a public web
 > site. 'created' is then the initial creation date, and 'issued' is
 > the date of when the article was publicly available (created + six
 > years in this case).

 > straight), it's perfectly reasonable to ask for clarification.

Thanks all, it makes sense to me now.

I think this explanation should definitely go into the spec.

\\ jonas galvez
// jonasgalvez.com

---

From: Beecher Greenman <[email-masked]>
Date: Fri, 09 Jul 2004 08:06:49 -0400

> I think this explanation should definitely go into the spec.
+1 on that. I had the same questions myself once, and from the 
explanation given to me then it seems that this confuses a lot of 
people. However, I have one more question: does issuing an entry count 
as a modification in and of itself?

Suppose that an article is created on April 1. It is modified on April 2 
and then sits around for a week. It is finally published on April 8, but 
no changes made to the text. Are <atom:issued> and <atom:modified> both 
April 8, or is <atom:modified> still April 2, since that is when the 
last change was made to the content?

- Beecher Greenman

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 09 Jul 2004 14:59:01 +0200

On Fri, 09 Jul 2004 08:06:49 -0400, Beecher Greenman  
<[email-masked]> wrote:

> +1 on that.

Yup: <url: http://intertwingly.net/wiki/pie/PaceEntryDates>

> does issuing an entry count as a modification in and of itself?

I hope not. I would at least not see it as a modification. This should  
probably also be noted in the pace, so I've edited it so it does.

> Are <atom:issued> and <atom:modified> both April 8, or is
> <atom:modified> still April 2, since that is when the last change
> was made to the content?

'atom:modified' should reflect the last change to the _content_ of the  
entry, and the dates of the entry is not a part of the content. Imho. This  
should be clear, as well as what should happen with 'atom:issued' when an  
article is re-issued. I think an article should retain the original  
'issued' date for the whole lifetime of an entry, and never change.

---

From: Mark Pilgrim <[email-masked]>
Date: Fri, 9 Jul 2004 10:42:57 -0400

> Yup: <url: http://intertwingly.net/wiki/pie/PaceEntryDates>

Current Atom pre-draft says that atom:modified and atom:created MUST
include a timezone, and atom:issued MAY include a timezone.

As of today, PaceEntryDates says that atom:modified and atom:created
SHOULD include a timezone, and atom:issued MUST include a timezone.

In other words, this Pace completely redefines which timezones are
optional and which are required.  Was that intentional?  Did I miss a
meeting?

-- 
Cheers,
-Mark

---

From: "Roger B." <[email-masked]>
Date: Fri, 9 Jul 2004 10:13:15 -0500

> probably also be noted in the pace, so I've edited it so it does.

Asbjørn: Bad idea. The issued date is generally going to be set within the
context of an entry editor, just like keywords or any other metadata. And
when the user hits "Submit", the modified date is likely to change, just as
it would if the summary, category, or any other user-defined info was
touched.

> entry, and the dates of the entry is not a part of the content.

From the user's perspective, the issued date is most certainly part of the
content.

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

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 09 Jul 2004 17:29:48 +0200

> include a timezone, and atom:issued MAY include a timezone.

+1.

> optional and which are required.  Was that intentional?  Did I miss a

I dunno.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 09 Jul 2004 17:40:54 +0200

On Fri, 9 Jul 2004 10:13:15 -0500, Roger B. <[email-masked]>  
wrote:

> Bad idea. The issued date is generally going to be set within the context
> of an entry editor, just like keywords or any other metadata. And when
> the user hits "Submit", the modified date is likely to change, just as it
> would if the summary, category, or any other user-defined info was  
> touched.

But what is the purpose of having 'issued' in the format at all, if it's  
basically just some random string, formatted as a W3CDTF?

> From the user's perspective, the issued date is most certainly part of  
> the content.

That would depend on the user, apparently. If Atom is going to fulfill  
more than just some wierd blog tools' needs, the perceptance of what  
'issued' is needs to change. Having worked on some major CMS's over the  
last few years, 'issued' is _not_ a random string entered by the user, and  
it is extremely important for the context and meaning of an article when  
it was initially created and/or issued to the public.

An example I just wrote on #atom:

For a twenty year old article about «The next big thing: CD's!» which have  
been re-issued ten times the last few years because of domain and URI  
restructuring, it might have the dates: <issued>2002-08-03</issued> and  
<modified>2004-03-18</modified>. (It might not even have <modified>.) Ok,  
nice to know when the article was last modified, but who the heck writes  
about «The next big thing: CD's» in 2002?!

---

From: "Bill Kearney" <[email-masked]>
Date: Fri, 9 Jul 2004 15:21:10 -0400

> about «The next big thing: CD's» in 2002?!

Hmmm, an edge case argument masquerading as important?

In the context of the entry being edited it well seems likely the dates matter.
But in a feed, well, why would this item be in a feed?  Just because something
changed doesn't mean it's automagically going to need to be republished. Of
course that raises the question of how the entry editing activities should
affect publishing status.  Being that the item didn't change 'enough' to merit
republishing in a feed, well, that raises the question of how does a system
decide what is or isn't to be included?    If the feed is news-like then it
seems pretty lame to bother annoying the audience with such trivialities.  If
the data was used for some sort of data synchronization tool then it might.
Seems pretty application specific however and may well be beyond the scope of
what this generation of Atom expect to clarify.

-Bill Kearney

---

From: Graham <[email-masked]>
Date: Fri, 9 Jul 2004 15:31:13 -0400

> optional and which are required.  Was that intentional?  Did I miss a

Yes. The pre-draft contains lots of nonsense and internal conflicts 
(see the rationale), and doesn't seem to have been thought through as a 
system, but as three separate elements. PaceEntryDates attempts to 
rectify this.

Graham

---

From: Eric Scheid <[email-masked]>
Date: Sat, 10 Jul 2004 15:09:46 +1000

> last change was made to the content?

(1) Did the author re-read what they last wrote a week ago, checking for
anything that might have changed in the last week, and finding none
published it? If so, then <modified> = <issued>.

(2) Did the author not bother re-reading what they wrote, and simply punched
the publish button? ... <modified> != <issued>

(3) Did the author write what they wrote, and left it for a week thinking
they'll re-word it once they cool off a bit, but one week later when
re-reading it they feel just as steamed up? <modified> = <issued>

(4) Did the author write what they did, waited a week, found that they have
in fact cooled off, but none the less still want to put on the record just
how steamed they were 7 days ago? <modified> != <issued>

(5) Same as (4), but while re-reading it noticed some inconsequential
spelling/syntax error which they fix, but otherwise feel as they did in (4)?
<modified> != <issued>

Now before someone gets upset, lets look at each of them from the
perspective of the recipient (which is really what counts, right?) ...

(1) here is something as of today, and it is up to date too.
(2) here is something as of today, but it might be out of date
(3) here is something as of today, and it is accurate as of today too.
(4) here is something as of today, reflecting a situation of 7 days past.
(5) Same as (4), who cares if a spelling error was fixed today.

No, this behaviour is not programmable, at least not until AI arrives and
our blog tools come with an ESP module.

e.

---

From: "Roger B." <[email-masked]>
Date: Mon, 12 Jul 2004 10:18:29 -0500

> basically just some random string, formatted as a W3CDTF?

Asbjørn: The "published date" is the date that the author wants attached to
her entry. That date controls when and where the entry shows up in her blog
and feed. It is also the date that aggregators will want to use for sorting
in most instances. In short, it's the most important date available, and the
one users most want to control.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 12 Jul 2004 18:28:02 +0200

On Mon, 12 Jul 2004 10:18:29 -0500, Roger B. <[email-masked]>  
wrote:

> Asbjørn: The "published date" is the date that the author wants attached  
> to her entry.

Okay. Fine so far.

> That date controls when and where the entry shows up in her blog and  
> feed.

Shouldn't that be 'available'[1] in Dublin Core terms?

> It is also the date that aggregators will want to use for sorting in most
> instances.

It might be used for sorting, but the sorting will be the most rediculous  
thing you've ever seen when the date:

   - Is without timezone information
   - Is randomly user-specified
   - Can change any time anyone wants

> In short, it's the most important date available, and the one users most
> want to control.

The most important date is something the user _should not_ be able to  
control. Of course, they do what they want in the end, but the most  
reliable and «trustworthy» dates are those provided by the tools, not by  
the user.

____
[1] <url: http://dublincore.org/documents/dcmi-terms/#available>