Subject: Re: PaceDates

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 29 Jul 2004 22:15:51 +0200

On Thu, 29 Jul 2004 18:20:36 +1000, Eric Scheid  
<[email-masked]> wrote:

> insert ", including addition, changes, or deletions of child elements of  
> the entry, including namespaced extensions."

I changed it into this:

   The "atom:modified" element is a Date Construct that indicates the time
   that the entry was last modified. "Modification" of an entry includes
   addition, changes, or deletions of child elements of the entry, both
   in and outside of the Atom namespace.

>> The content of an atom:modified element MUST according to RFC 3339 have  
>> a time zone whose value SHOULD be "+00:00" or "Z".
>
> why does RFC 3339 say the timezone should be UTC?

Because UTC dates are a lot more manageable than local ones.

> why not "-00:00"?

That is UTC. The only difference is that the local timezone is unknown. If  
you think the specification text could make this clearer, please feel free  
to suggest what such language might look like.

>> If an atom:entry is re-issued at several different locations,
>> atom:modified MAY be altered to indicate this change in the entry's  
>> state.
>
> huh? So if an entry is posted at msdn.blogs.com, and then some moments  
> later also appears at blogs.msdn.com, it might have a different
> atom:modified? Why?

Not sure why and how that sentence got there, so I removed it.

>> An atom:modified date does only give a slight indication of  
>> modification. If atom:modified has not changed, it is safe to assume
>> that the entry itself has not changed either. However, a change in
>> atom:modified does  not necessarily imply a change in the entry
>> itself.
>
> Where did this come from?

This paragraph is provided by Ken, and he explains it like this:

'modified' can change for pretty much any darn reason local to the system,  
and may not involve any real change to the item. Specifically, that time  
changes whenever the user hits «save» on the item, even if they made no  
changes at all.

It changes if the item is copied from one filesystem to another, without  
remembering to preserve the modification times, or when exported from one  
database and imported into another, if the modified-time is system  
generated.

Does that make sense? Could we put it in any other language to make that  
more easilly understandable?

> btw, is atom:entry/id a MUST?

Yes. At least in the current specification, and all paces on atom:id I've  
read. I don't think anyone wants atom:entr/atom:id optional.

> no mention as to whether this is mutable

If everyone could agree that 'issued' means 'first-issued' just as  
'created' means 'first-created' (I have the view that you can only create  
and issue something once), we can say that 'issued' is immutable, and drop  
'first-issued'. But I don't think people can agree to that.

We should probably, in any case, say whether 'issued' is mutable or not.

> conflict of precedence here ... if no other date constructs are available
> then the entry MUST have first-issued ... and MUST have atom:issued too  
> (see above), and MUST have atom:modified too (see above).

Yes. Luckily, you understand what I'm trying to say:

> I know what you're trying to say: atom:entry MUST contain at least one of
> atom:modified, atom:issued, [...].

Correct.

> I suggest you gather all the date constructs under point 4.13.6, and then
> numbered sub-points for each date element (ie. 4.13.6.1 for modified,
> 4.13.6.2 for issued, etc).

Good idea. Done. Would it be a good idea to group the dates in a <dates>  
element, btw?

>> atom:entry elements SHOULD contain an atom:created element, but MUST NOT
>> contain more than one. If no other Date Construct is available for the
>> atom:entry, atom:created MUST be present.
>
> SHOULD is too strong.

Hm. Okay. Changed to MAY.

>> === 4.13.10 "atom:date" Element ===
>
> I assume you've renamed 'dateline' to 'date', so +1

Yes. As Laurent Le Meur wrote[1], «dateline» isn't really a good term for  
what's really a «display date» or «custom date».

> why the deprecation of 'date'?

Because it's a wildcard date. No one knows what the publisher's mean with  
it, so we should encourage them to move over to the more tightly specified  
dates 'issued', 'created' or 'modified'. They may provide atom:date for as  
long as they want, but I think that the use of such ambiguous elements  
should be discouraged.

>> The content of an atom:date element MUST according to RFC 3339 have a  
>> time zone whose value SHOULD be "+00:00" or "Z". The time zone MAY,
>> however,  be "-00:00" when the time is known to be correct UTC, but the
>> time zone is unknown, or be '+hh:mm' when the time zone is known.
>
> conflict of MUST and MAY here.

It may look like it, but "-00:00" is also a timezone. Not sure how I can  
express this with better language. Please feel free to make suggestions.

> what happened to atom:updated?

Who wants it, really? I know that Dare have written several times that he  
has never seen or heard a use case for it, but if the consensus is that  
this date should be available, then okay. I think that major changes  
should be signified with another mechanism than a date, though.

____
[1] <url: http://www.imc.org/atom-syntax/mail-archive/msg07955.html>

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

---

From: Antone Roundy <[email-masked]>
Date: Thu, 29 Jul 2004 15:07:47 -0600

On Thursday, July 29, 2004, at 02:15  PM, Asbjørn Ulsberg wrote:
> Good idea. Done. Would it be a good idea to group the dates in a 
> <dates> element, btw?

I don't see any value in grouping under a <date> element.  Anyone else? 
  If there's no value in it, then let's be less verbose.  I DO like the 
idea of grouping the date elements within the spec--I think it improves 
spec readability.

> Because it's a wildcard date. No one knows what the publisher's mean 
> with it, so we should encourage them to move over to the more tightly 
> specified dates 'issued', 'created' or 'modified'. They may provide 
> atom:date for as long as they want, but I think that the use of such 
> ambiguous elements should be discouraged.

-1.  The subjective date is not only for legacy support--it also 
enables the author to indicate a date related to the CONTENT or MEANING 
of the entry, as opposed to timestamping the events that occurred in 
the process of PUBLISHING the entry.

>>> The content of an atom:date element MUST according to RFC 3339 have 
>>> a time zone whose value SHOULD be "+00:00" or "Z". The time zone >>> MAY,

My impression was that it is MORE accurate to use "-00:00" than 
"+00:00" or "Z" when normalizing from some other timezone to UTC.  
Doesn't "+00:00" or "Z" imply that UTC IS the "origin" timezone?  When 
it is said that "-00:00" means that the origin timezone is unknown, I 
think that means that either the clock of the computer that generated 
the timestamp is set to UTC, thought it may not be located in that 
timezone, or that the timestamp has been normalized to UTC, thus 
discarding the originally known timezone information.  I can't imagine 
that it means "I looked at the clock with the local time and computed 
the UTC time, but I have no clue what timezone I'm in."  If your clock 
reads local time and you can compute UTC, you DO know what timezone 
you're in.

I don't think it's terribly important whether "+00:00", "-00:00" or "Z" 
is used, but if we ARE going to encourage one or two over the other(s), 
then let's be sure we're doing the most correct thing.

---

From: Eric Scheid <[email-masked]>
Date: Fri, 30 Jul 2004 11:34:57 +1000

>  in and outside of the Atom namespace.

+1

> to suggest what such language might look like.

my point is you've SHOULD'd against it.

append: <<, or "-00:00" if the UTC time is known but the local time zone is
unknown (eg. as a centralised hosting service might know)>>

> long as they want, but I think that the use of such ambiguous elements

<summary> is also a wildcard element - it contains arbitrary, subjective,
and mutable content, and no one will know a priori whether it will be a
truncated first paragraph, a hand written summary, a machine written
summary, a bunch of keywords mushed together.

Nonetheless, it's a very useful thing. Ditto 'dateline' aka 'date'. It's
content, and it's valuable.

The medium is not the message, the message is the message. Content is the
reason.

> should be signified with another mechanism than a date, though.

I want it. I asked Brent Simmons (of NNW fame) and he'd love to have it.
Others can see the utility of it. People are hacking current values of
<pubDate> to get the same effect today because they don't have it. 'updated'
would also be used when an entry has major changes made in lieu of munging
'issued', which I thought was a goal of yours.

e.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 30 Jul 2004 20:10:06 +0200

On Thu, 29 Jul 2004 15:07:47 -0600, Antone Roundy <[email-masked]>  
wrote:

> If there's no value in it, then let's be less verbose.

Yes.

> I DO like the idea of grouping the date elements within the spec--I think
> it improves spec readability.

Yes, it does. Do you like the way they're grouped in PaceDates now?

> -1.  The subjective date is not only for legacy support--it also enables  
> the author to indicate a date related to the CONTENT or MEANING of the  
> entry, as opposed to timestamping the events that occurred in the  
> process of PUBLISHING the entry.

I kind of agree that such a date is needed, I'm just not sure how we can  
say that tools SHOULD NOT use this date and instead match their semantics  
with either 'issued', 'modified' or 'created' and use those instead. I'm  
all +1 for having atom:date being totally subjective, however, that's not  
the current practice -- it can be both.

> My impression was that it is MORE accurate to use "-00:00" than "+00:00"  
> or "Z" when normalizing from some other timezone to UTC.

No, I don't think so. If you normalize, you would need to normalise _from_  
something. Thus, you would need to know the original local time.  
Normalizing 2004-30-07T08:41:30+04:00 to 2004-30-07T04:41:30Z is ceirtanly  
data loss, but the original time zone is known, and the date is explicitly  
normalized to UTC, and thus isn't '-00:00' appropriate. I think.

 From RFC 3999:

    If the time in UTC is known, but the offset to local time is unknown,
    this can be represented with an offset of "-00:00".  This differs
    semantically from an offset of "Z" or "+00:00", which imply that UTC
    is the preferred reference point for the specified time.  RFC2822
    [IMAIL-UPDATE] describes a similar convention for email.

> I can't imagine that it means "I looked at the clock with the local time
> and computed the UTC time, but I have no clue what timezone I'm in."

No, that's not what it means. What it could be useful for, is in  
situations when a server is e.g. placed on the moon (e.g. wherever) and  
the user in Taiwan, but the date of the server is (synchronized and  
correct) UTC time. The server knows it's UTC, but have no idea about what  
the user's local offset is.

> If your clock reads local time and you can compute UTC, you DO know
> what timezone you're in.

Yes, but I doubt "-00:00" is intended for humans to provide.

> then let's be sure we're doing the most correct thing.

Absolutely.

---

From: Antone Roundy <[email-masked]>
Date: Fri, 30 Jul 2004 12:40:36 -0600

Yes.

>> enables the author to indicate a date related to the CONTENT or 
>> MEANING of the entry, as opposed to timestamping the events that 
>> occurred in the process of PUBLISHING the entry.
>
> I kind of agree that such a date is needed, I'm just not sure how we 
> can say that tools SHOULD NOT use this date and instead match their 
> semantics with either 'issued', 'modified' or 'created' and use those 
> instead. I'm all +1 for having atom:date being totally subjective, 
> however, that's not the current practice -- it can be both.
>
The point is that if the date a tool is publishing actually fits into 
issued, modified, created, or whatever objective dates end up in the 
spec, they should put it on those elements rather than in the 
subjective element (at least not ONLY in the subjective date element).  
I really don't think we need to prompt anyone to do that.  If we say 
"these are the date elements, and this is what belongs in each", then 
developers who see a date element that specifically fits what they have 
available are going to use it without us saying "if the date you're 
publishing fits this description of the atom:issued, you SHOULD NOT put 
it in atom:date".

Given that there are entirely legitimate uses for atom:date, any 
language that implies that its use should be avoided is, I think, 
inappropriate and unnecessary.  We can encourage the use of the other 
date elements without discouraging the use of atom:date.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 30 Jul 2004 22:55:25 +0200

On Fri, 30 Jul 2004 11:34:57 +1000, Eric Scheid  
<[email-masked]> wrote:

>> That is UTC. The only difference is that the local timezone is unknown.  
>> If you think the specification text could make this clearer, please  
>> feel free to suggest what such language might look like.
>

Okay.

> append: <<, or "-00:00" if the UTC time is known but the local time zone  
> is unknown (eg. as a centralised hosting service might know)>>

Done. Tell me if it's appended or implemented incorrectly.

> <summary is also a wildcard element - it contains arbitrary, subjective,  
> and mutable content, and no one will know a priori whether
> it will be a truncated first paragraph, a hand written summary, a
> machine written summary, a bunch of keywords mushed together.

That's different, since the content of <summary won't be parsed and
_understood_ in any way by a tool.

> content, and it's valuable.

I can agree to atom:date being a 100% author-provided, subjective,
human-eye-intended date, but don't know how that can be specified to
cater for the current practice at the same time.

>> Who wants it, really? I know that Dare have written several times that  
>> he has never seen or heard a use case for it, but if the consensus is
>> that this date should be available, then okay. I think that major
>> changes should be signified with another mechanism than a date, though.
>

Okay. I feel that this is such a far stretch after a more professional
publishing model that I don't understand why the course isn't followed
completely. If you want the perks of a professional publishing model,
why don't you just conform to one? 'Updated' is a shortcut to some of
the benefits of a professional, revisioned publishing model, but leaves
so many things «out in the blue» that it's still a hobby-publishing
model.

(I'm sorry if the word «hobby» is offending -- my intention is not to
offend anyone, it's just used to separate the two models.)

What happens when people wants another little piece of the professional
publishing model? And another piece? Should it be implemented into Atom
piece by piece, or should we instead just slam the stake in the ground
and create a really clear separation between the «hobby» and the
«professional» model?

> <pubDate to get the same effect today because they don't have it.

Atom doesn't have <pubDate>. If PaceDates gets consensus and is rolled
into the specification, Atom will have the equivalent 'date', which can,
but SHOULD NOT, be used for this purpose. 'modified' should. If the
changes you have made are so uninteresting that the entry is not worth
seeing again, don't change modified. If it is, change modified.

If you want a way to separate minor from major changes, apply a
professional publishing model with revisioning. Then you get version
control as a bonus.

> 'updated' would also be used when an entry has major changes made in
> lieu of munging 'issued', which I thought was a goal of yours.

'issued' will in any case never mean 'first-issued' in a hobby
publishing model, which is why I have suggested 'first-issued' to be
used. I'm beginning to think that 'first-issued' should be withdrawn,
however, and rather have 'issued' change semantics depending on what
profile the feed conforms to.

The feed conforms to Atom Core when no profile is specified. If one or
more are specified, it conforms to them. A profile can change the
semantics of existing elements (although not so much that it makes them
backwards incompatible) and introduce new elements. Ken's suggestion on
how to apply a profile to a feed, is this:

<feed version="1.0">
   <profile xmlns="http://purl.org/atom/ns#professional-publishing" />
   [...]
</feed>

A nice thing about this mechanism is that the 'profile' element would
reside in the non-core Atom namespace. When provided, it says that «This
feed conforms to the profile "Professional Publishing"», which e.g. will
change the semantic of atom:issued to be «The issuance of this
particular revision of a resource» and atom:id to require a  revision-
supportive URI scheme.

This is only an example, but I hope it gives you an idea of how it
might work. The point of not just applying the "Professional Publishing"
namespace to the whole Atom feed, is because everything SHOULD (or MUST)
be backwards compatible with Atom Core, and thus won't not understanding
this profile break clients (badly).