Subject: PaceDateSubjective

From: Paul Hoffman / IMC <[email-masked]>
Date: Sun, 12 Sep 2004 17:29:57 -0700

Greetings again. The reason I support this element is that we fully 
expect Atom to be used in non-blog environments where the date in the 
contents is much more important than the date the entry is created or 
modified.

I'd also be happier that, if the pace is accepted, the element change 
its name to something less generic, such as atom:content-date or 
atom:date-in-entry or some such.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Tim Bray <[email-masked]>
Date: Sun, 12 Sep 2004 23:00:30 -0700

> atom:date-in-entry or some such.

I can go either way on this one, but if we go for it, I'm fine with 
atom:date.  We've kicked around a half-dozen alternate names, and I 
still think "dateline" was best, but none of them are clearly better 
than the minimal version. -Tim

---

From: Sam Ruby <[email-masked]>
Date: Mon, 13 Sep 2004 02:25:20 -0400

> than the minimal version. -Tim

I'm also fine with atom:date.  In context, this is the enclosing 
atom:entry's date.

Overall, I'm -0 on this element in the core unless we get some 
indication that there is some major provider interested in providing 
this date.

- Sam Ruby

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 13 Sep 2004 05:23:39 -0400

Tim Bray wrote:
> We've kicked around a half-dozen alternate names, and I 
> still think "dateline" was best, but none of them are clearly
> better than the minimal version. -Tim
	Given that this date most closely corresponds to the "dateline"
which is defined in NewsML and given that mapping between NewsML and
Atom is going to be a generally useful thing to do, I suggest that we
use "dateline" as the name for the element.

		bob wyman

---

From: Eric Scheid <[email-masked]>
Date: Mon, 13 Sep 2004 21:53:50 +1000

> I'm also fine with atom:date.  In context, this is the enclosing

+1

---

From: Sam Ruby <[email-masked]>
Date: Mon, 13 Sep 2004 10:58:29 -0400

> use "dateline" as the name for the element.

 From the NewsML functional specification[1]:

     DateLine  A natural-language statement of the date and/or place
               of creation.

     DateLineDate  A logical represenation of the date and/or place of
               creation in ISO8601 Basic Format.

In NewsML for Dummies[1], I can only find one example of dateline being 
used, and it is thus:

   <DateLine>FRANCE (AFP)</DateLine>

It looks to me like DateLineDate is a better match.

- Sam Ruby

[1] 
http://www.newsml.org/IPTC/NewsML/1.2/specification/NewsML_1.2-spec-functionalspec_7.html
[2] http://xml.coverpages.org/NewsMLForDummies.pdf

---

From: Tim Bray <[email-masked]>
Date: Mon, 13 Sep 2004 09:11:14 -0700

> It looks to me like DateLineDate is a better match.

Or more appropriately atom:dateline-date.

I could live with that if people like it, but would prefer atom:date 
-Tim

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 13 Sep 2004 09:26:05 -0700

>indication that there is some major provider interested in providing 

As I said in my earlier message, I'm +1 on this for non-blog uses 
which don't exist yet (and thus would not yet have a "provider"). An 
obvious example would be messages about events in the future, such as 
conference and concert listings. If I'm subscribed to such a feed, I 
could probably care less when someone announced the even, but would 
greatly like to be able to sort on the event date.

--Paul Hoffman, Director

---

From: James Aylett <[email-masked]>
Date: Mon, 13 Sep 2004 17:59:39 +0100

> I could live with that if people like it, but would prefer atom:date 

atom:dateline-date strikes me as considerably more readable and
transparent as to its purpose. I'd probably have to be -1 on this Pace
if we have to use atom:date for it; I'm +1 otherwise.

James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  [email-masked]                               uncertaintydivision.org

---

From: Tim Bray <[email-masked]>
Date: Mon, 13 Sep 2004 10:02:31 -0700

> indication that there is some major provider interested in providing 

I had the impression that this corresponded closely with LiveJournal's 
date idiom... anyone know for sure?  --Tim

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 13 Sep 2004 10:00:06 -0700 (PDT)

> greatly like to be able to sort on the event date.

-1 

I think events need a lot more metadata than a single
date value. I'd rather see a comprehensive extension
that handles dates and use that than have one or two
elements in the core spec that can be overloaded to be
utilized for syndicating events. 

If I wanted to syndicate an event such as a conference
or a concert I'd expect at least three values 

 (location, start time, duration) 

Anything less isn't terribly useful for the common
scenarios for sharing calendar events in the real
world (see Evite or Exchange calendaring).  

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #23
I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks.

__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 13 Sep 2004 10:04:31 -0700

>utilized for syndicating events.

<mumble> <shuffle> Probably agree.

--Paul Hoffman, Director

---

From: Mark Pilgrim <[email-masked]>
Date: Mon, 13 Sep 2004 13:14:37 -0400

On Mon, 13 Sep 2004 09:26:05 -0700, Paul Hoffman / IMC <[email-masked]> wrote:
> As I said in my earlier message, I'm +1 on this for ... uses which don't exist yet

I find this statement deeply troubling.

-- 
Cheers,
-Mark

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 13 Sep 2004 20:56:24 +0200

> date idiom... anyone know for sure?  --Tim

That's my impression as well. I'm still -0 on this element, as it means  
absolutely nothing to me, but it doesn't hurt me to have it in the core  
either.

-- 
Asbjørn Ulsberg    -=|=-     http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 13 Sep 2004 21:08:10 +0200

-1 here as well.

> date value.

Indeed.

> I'd rather see a comprehensive extension that handles dates and
> use that than have one or two elements in the core spec that
> can be overloaded to be utilized for syndicating events.

Absolutely.

>  (location, start time, duration)

Yep. The same values are useful for playlists too, btw.

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

---

From: Walter Underwood <[email-masked]>
Date: Mon, 13 Sep 2004 12:46:58 -0700

> date idiom... anyone know for sure?  --Tim

I don't think that is right. The LiveJournal dates are missing
time zones. That makes them unsynchronized, not subjective.
Big difference.

XML Schema dateTime gives explicit rules for comparing dates with
and without time zones. Atom should specify XML Schema dateTime,
with a SHOULD for a time zone. That takes care of LiveJournal.

  http://www.w3.org/TR/xmlschema-2/#dateTime

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Sam Ruby <[email-masked]>
Date: Mon, 13 Sep 2004 16:48:45 -0400

> date idiom... anyone know for sure?  --Tim

The question really comes down to one of accuracy[1] and choices.  Let's 
start with Blogger, and then move onto LiveJournal.

  - - -

Blogger has three dates.  PostDate (user modifiable), LastChanged (for 
any reason), and DateCreated (immutable).

Now take a look at atom:updated[2].  Which one of the three dates should 
Blogger put in there?  We can probably safely eliminate DateCreated. 
But there are pros and cons to using each of the others as atom:updated. 
  LastChanged doesn't capture the intent of the change, and PostDate 
could capture some other intent (but generally doesn't).

So Blogger has a choice to make.  One thing that they could do is to 
write code and change the user interface so as to allow users to 
indicate whether a change is significant or not.  Or they could simply 
update the documentation on the existing PostDate to capture how it will 
be interpreted by syndication consumers.  Or they could simply shove 
LastChange into atom:updated meaning that syndication users of consumer 
tools that implement the atom specification correctly will draw 
attention to every typo correction.  Or Blogger could invent an entirely 
new date which corresponds exactly to atom's semantics.

I think we can safely rule out the last option in the short term.

I would argue that Blogger would get the best results in the short term 
if they were to put PostDate into atom:updated, and to clearly document 
that that is what they are doing.  This is due to the way the defaults 
for this field are handled in Blogger today.  PostDate's initial default 
corresponds closely to DateCreated.  The default on a modification is to 
NOT change the PostDate.  This means that a user would have to take an 
explicit action to indicate that a change is signficant.  That is goodness.

  - - -

IIRC, LiveJournal has the same three dates as Blogger, with one 
important difference.  Their equivalent of PostDate can not reliably be 
associated with a time zone, and RFC 3339 requires a time zone.  So 
LiveJournal initially have less choices.  For the short term, this means 
that they will likely pick either their equivalent of DateCreated 
(basically assuming that most changes are typo fixes), or LastChanged 
(basically assuming that every change merits attention).

  - - -

Now let's me introduce my world view.  While I do think that Atom is 
important, and I do think that all reputable blogging tools will invest 
time into coding up correct a template as possible given their current 
underlying data models, I do NOT believe that may tools will invest 
significant time into updating their user interfaces simply because the 
Atom spec tells them that they should.  Given the significant 
engineering that they have put into their user interfaces, any change 
would require signficant user input, prototyping, and human factors 
feedback.

If Blogger were to initially pick PostDate, and users were to find it 
troublesome to have to manually edit each field of this date when they 
wanted to indicate that this change warrants attention, then I could see 
Blogger eventually making "reset the PostDate to now" a one click operation.

If LiveJournal were to initially pick either LastUpdated or LastChanged, 
and this were to inspire significant user input, then I could see them 
updating their UI and/or possibly track time zones for PostDate and to 
make it easy for users to reset.

Now for the really interesting part.  Taking NetNewsWire and RssBandit 
as examples: the former picks up every change to pubDate, the latter 
captures the first pubDate it sees.  Which one is "right"?  I would 
argue that this fundamentally is a data quality issue.  If atom:updated 
turns out to become heavily polluted with indications of typos, I can 
see NetNewsWire adopting RssBandit's current approach.  If atom:updated 
is rarely updated; but when it is, it generally represents a significant 
change, then I could see RssBandit adopting NetNewsWire's approach.

  - - -

Bottom line: I think that there are significant limits to the amount of 
social engineering that we can accomplish as spec writers.  I do think 
that if the mythical implementers guide that Paul keeps referring to 
were to ever materialize, we can hope to encourage people to err on the 
side of caution and assume that most changes are typos.  We can do that 
by stating that it should take an explicit user action to draw attention 
to a change.  However, we should be realistic, and even that may take a 
product release cycle or three to converge onto.

- Sam Ruby

[1]<http://www.imc.org/atom-syntax/mail-archive/msg08457.html>
[2]<http://ietf.levkowetz.com/tools/rfcmarkup/rfcmarkup.cgi?url=http://ietf.levkowetz.com/drafts/atompub/format/draft-ietf-atompub-format-02.txt#page-17>

---

From: Eric Scheid <[email-masked]>
Date: Tue, 14 Sep 2004 08:15:34 +1000

> could capture some other intent (but generally doesn't).

I would suggest that in the absence of a facility for marking an edit as a
major change vs a minor edit, atom:update should probably not change at all,
which would mean atom:update would be loaded with the value of
blogger:DateCreated.

e.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 14 Sep 2004 08:48:54 +1000

> which would mean atom:update would be loaded with the value of

further thinking...

consider these two entries, retrieved at different times from the same feed:

    <entry>
        <id>http://example.com/1</id>
        <updated>2004-09-14T07:34:00+10:00</updated>
        <content>200 words [...]</content>
    <entry>

    <entry>
        <id>http://example.com/1</id>
        <updated>2004-09-14T09:00:00+10:00</updated>
        <content>100 words [...]</content>
    <entry>

does anyone care to venture a guess as to which is the more up to date
entry? Which one should be dropped, which one should be displayed?

If blogger were to stuff the date value of blogger:DatePosted into
atom:updated, then there will come times when blogger:DatePosted (and thus
atom:updated) goes backwards. This is broken.

Blogger has a choice: firstly, either develop a facility for marking an edit
as a major update, or maintain the status quo. In the former, they would now
have a blogger:DateUpdated to do the right thing with.

If they don't provide a facility for editorially marking an edit as major,
then they can either (a) insert the same unchanging value into atom:updated,
or (b) insert some changing value, thus marking every edit as an update,
polluting and diluting atom:updated.

With (a) they would need to insert a date value which has some close
correlation to when it was first published. DateCreated works for that. If
DateCreated is actually several days/weeks ago (meaning the post sat in the
draft queue for a while), and is then published with that ancient date in
atom:updated, then that can quite rightly be interpreted as meaning "here is
a post, no major edits have been signalled since [foo]". I say quite
rightly, because the publishing system doesn't provide the facility for
signalling any major edits.

e.

---

From: Martin Duerst <[email-masked]>
Date: Tue, 14 Sep 2004 10:21:03 +0900

>if we have to use atom:date for it; I'm +1 otherwise.

I concur being -1 (or even -2) on this if it's called atom:date.
Given that we have so much discussion about different dates,
calling one of them simply 'date' seems a very bad idead.

Regards,   Martin.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 14 Sep 2004 08:02:14 +0200

> time zones. That makes them unsynchronized, not subjective.

Isn't the LJ date fully alterable by the user as well? If so, how do you  
know when it's not altered? Can we ever assume that the user have not  
altered the date (in which case it isn't subjective) or always altered it  
(in which case it's subjective)? No we can't, so we need to move it into  
the most correct category of 'subjective' and 'objective', and since it's  
mutable, it should go into the 'subjective' category.

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 14 Sep 2004 13:58:56 +0100

> calling one of them simply 'date' seems a very bad idead.

I agree with Martin, and will go one step further - given the nature 
of the discussions on dates here, we should not allow any Atom 
element to be called atom:date.

cheers
Bill

---

From: Antone Roundy <[email-masked]>
Date: Tue, 14 Sep 2004 08:35:22 -0600

On Tuesday, September 14, 2004, at 06:58  AM, Bill de hÓra wrote:
> of the discussions on dates here, we should not allow any Atom element 
> to be called atom:date.
>
Just in case anyone was wondering, I, the author of the proposal, don't 
particularly care what the name of the element ends up as.  I picked 
"date" because it was generic, but I have no attachment to it, and am 
happy to defer to those who object to using that name.

---

From: David Powell <[email-masked]>
Date: Tue, 14 Sep 2004 16:28:12 +0100

> happy to defer to those who object to using that name.

I'm +1 to it because for the cases when people want to use it there is no
alternative in dcterms.  It seems natural to let the author of an article
express a date that they want associated with it.

As for the name of the element I think that atom:date is too vague.

atom:content-date is ok, but people (ok, morons), could confuse "the date of the
content" with atom:modified or something.

How about atom:title-date?  Or atom:about-date?

-- 
Dave

---

From: Tim Bray <[email-masked]>
Date: Tue, 14 Sep 2004 09:02:42 -0700

We have several -1's to this based on it's being called atom:date.  I'm 
going to, for the purpose of this Pace, observe that we clearly do 
*not* have consensus on the name atom:date.  The only proposal that got 
more than zero positive feedbacks was my "dateline-date".  So for the 
moment, let's rename this "atom:dateline-date" (Antone, want to fix the 
Pace?) and go back to the date's semantics.

On which subject, I just glanced through the archive quickly and while 
there's some support for dateline-date, there's also a strongly-argued 
-1 from Dare Obasanjo, see 
http://imc.org/atom-syntax/mail-archive/msg09859.html, that got a 
couple of echoes.

Not making any final calls yet, but at the moment this thing is not 
treading a smooth path towards consensus; those who really want it need 
to address at least Dare's issues. -Tim

[Personal-position disclosure on this one: I don't care, either way, 
whatever.]

---

From: Eric Scheid <[email-masked]>
Date: Wed, 15 Sep 2004 02:41:22 +1000

On 15/9/04 2:02 AM, "Tim Bray" <[email-masked]> wrote:

> Not making any final calls yet, but at the moment this thing is not treading a
> smooth path towards consensus; those who really want it need to address at
> least Dare's issues.
> 

http://imc.org/atom-syntax/mail-archive/msg09859.html

addressing Dare's concern: I think Paul's example (to which Dare responded)
was just one possible use of DateSubjective.

> If I wanted to syndicate an event such as a conference or a concert I'd expect
> at least three values
> 

I'd want a link to a vCalendar resource personally. Meanwhile I can think of
similar types of feeds where a publisher would want to associate a
subjective date to the content, regardless of publishing deadlines.

For example, I would be interested in a feed which listed upcoming birthdays
of famous persons or anniversaries of other historical events, or even a
listing of upcoming international holidays. I want to know before hand, that
way I can organise a keg for the party (any excuse ;-)

Other uses of DateSubjective might be following the diary of the
great-great-...-great-grandson of Samuel Pepys, following along with his
adventures in Luna Colony One in the 22nd century.

Back to concert listings though ... if the Grand Old Theatre on Main Street
wanted to provide a list of upcoming concerts, they'd only need to a
<title>, <content>, and a <dateline-date> ... which as we all remember is a
date+time construct. I already know the location.

e.

---

From: Walter Underwood <[email-masked]>
Date: Tue, 14 Sep 2004 09:58:55 -0700

--On Tuesday, September 14, 2004 09:02:42 AM -0700 Tim Bray 
<[email-masked]> wrote:
> going to, for the purpose of this Pace, observe that we clearly do *not*
> have consensus on the name atom:date.  The only proposal that got more
> than zero positive feedbacks was my "dateline-date".  So for the moment,
> let's rename this "atom:dateline-date" (Antone, want to fix the Pace?)
> and go back to the date's semantics.

For the record, I think atom:date is probably the best choice, and
I think that dateline-date is very wrong. Datelines are natural language
expressions of dates, but the PACE requires a machine-readable date.
Using "dateline" means it must be free syntax with date semantics.
Coupling "dateline" with a restricted syntax is a misuse of the term
and makes the format harder to understand.

I also think that "subjective" is entirely wrong terminology.
These dates might not be machine-generated, but they aren't
just a whim. Is the date for a press release subjective?
"Authoritative" is a better term, because this date is chosen
by the author.

In most cases, this will be the best date to display for an entry.
"atom:date" is right and proper for that.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: James Aylett <[email-masked]>
Date: Tue, 14 Sep 2004 18:04:49 +0100

On Tue, Sep 14, 2004 at 09:02:42AM -0700, Tim Bray wrote:

> I just glanced through the archive quickly and while there's some
> support for dateline-date, there's also a strongly-argued -1 from
> Dare Obasanjo, see

I can't be certain whether Dare is arguing against PaceDateSubjective,
or just against the idea that it would enable event-like usage of
Atom. I'm inclined to agree that it would cause Bad Things if
PaceDateSubjective were endorsed for doing poor-man's events; but I
still think a dateline (or otherwise subjective) date has uses
sufficient to warrant its inclusion in core.

Dare, can you clarify whether you're against the Pace in general or
just against its use for events?

James

---

From: James Aylett <[email-masked]>
Date: Tue, 14 Sep 2004 18:09:08 +0100

> "Authoritative" is a better term, because this date is chosen

Agreed; besides the name of the Pace, it's just the abstract which
uses the word 'subjective'. A better abstract might be 'Define a date
which the publisher wishes to associate with the contents of the
entry' (taken from the proposed spec text).

James

---

From: Antone Roundy <[email-masked]>
Date: Tue, 14 Sep 2004 11:30:00 -0600

On Tuesday, September 14, 2004, at 10:02  AM, Tim Bray wrote:
> We have several -1's to this based on it's being called atom:date.  
> I'm going to, for the purpose of this Pace, observe that we clearly do 
> *not* have consensus on the name atom:date.  The only proposal that 
> got more than zero positive feedbacks was my "dateline-date".
While I'm here, I'll give positive feedback for dateline-date and 
about-date.  about-date has a more obvious meaning, but it might be too 
narrow.  It's perfect for a journal entry about September 14, but, for 
example, is the September issue of Discovery magazine "about" 
September, or is a 2004 Corolla "about" 2004?  Not really.  So, 
dateline is probably a better match.

> So for the moment, let's rename this "atom:dateline-date" (Antone, 
> want to fix the Pace?)
I've changed it to dateline-date.

> treading a smooth path towards consensus; those who really want it 
> need to address at least Dare's issues.

Hmm, okay, what are the potential uses for dateline-date?  Are they 
sufficiently well handled by a single date element?  Could they all be 
handled by a single extension with more elements?

a) specify the date or period of a future event
b) specify the date or period about which a journal entry or other 
historical account speaks
c) specify the date or period about which a forecast (weather, etc.) of 
some possible future event speaks
d) specify the date or period to which an entry is assigned for some 
possibly arbitrary reason (the July issue of X, etc.)

It's impossible to ignore the possibility that any of these uses may 
span a period of time rather than just a single instant or even a 
single day.  Depending on the significance of that period, the starting 
date may very well not be a sufficient representation of it.  So a more 
comprehensive set of elements could certainly be useful.

On the other hand, in many cases, I think it would be sufficient to 
mention just a single date: the date and start time of a one day event 
(especially if it's always at the same place, and "everyone" knows it), 
a journal entry covering one day, the weather forcast for September 
16th, and if you're not thinking too rigerously, the October issue of X 
magazine.  While I think many people will have good uses for a single 
up-to-the-publisher date, I wouldn't be heartbroken if it were 
relegated to an extension.  I'd be more disappointed if it took three 
years for the extension to appear.

A few quick thoughts on what an extension might include:

1) start date/time
2) end date/time
3) location (plain text or using some more precise system)
4) meta-event id (rather than one entry covering a gazillion 
sub-events, have a separate entry for each sub-event, and some sort of 
meta-event id to tie them all together).

and getting more esoteric:

5) cost (could need multiple costs for different ages, etc.)
6) age requirements
etc.

Okay, no need to ramble on longer.  Our charter states:

> Extension development is not included in this charter. The working
> group will consider the need to either close or to modify the charter
> and document extensions once the core document set has been approved
> by the IESG.

I think this has come up before, but since I'm not likely to go hunting 
for the old message, does anyone know of an existing XML format for 
specifying such things?  (Preferably one that's not too complex for 
simple cases, and would work for all the uses mentioned above).

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 14 Sep 2004 10:28:35 -0700

Before we go too far on naming this item, it is worthwhile to point 
out that there have been two objections (Dare and MarkP), and my 
agreement with Dare that maybe this isn't sufficient to be actually 
useful. To repeat what he said:

-----

-----

I am particularly concerned with his second sentence, which precisely 
hits on one of the things that Atom is supposed to do better than 
RSSv<=2.

So, I am explicitly removing my support for this (however it is 
named), give it a -1, and promise to help work on the extension that 
covers it better.

--Paul Hoffman, Director

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 14 Sep 2004 10:40:12 -0700

At 2:41 AM +1000 9/15/04, Eric Scheid wrote:
>I'd want a link to a vCalendar resource personally.

Or something like it. (The vCalendar spec has a wide lattitude of 
implementation problems.)

>  Meanwhile I can think of

Sure, but is that sufficient? In specific, if we have a single 
subjective date, what will people do who need a date *range*? My 
guess is that they'll fudge our date in various non-interoperable 
ways.

>date+time construct. I already know the location.

That was my first thought, but from an architectural standpoint, we 
should either give rich metadata about people and/or events in the 
content, or none. Just giving a single date opens us up to lots of 
kludging, particularly if someone (like me) later proposes an 
extension that covers this well.

You proposed above that you would want a vCalendar resource. If there 
was a widely-adopted extension for that, how would it interact with 
atom:date-dateline? My guess is: poorly. We shouldn't be doing this 
part-way, and I don't think we have enough demand to do it fully in 
the core spec.

Right now, this is the first proposal for metadata about things in 
the content, and I think we should mark that kind of metadata 
off-limits to the Atom core, and encourage extensions.

--Paul Hoffman, Director

---

From: Eric Scheid <[email-masked]>
Date: Wed, 15 Sep 2004 04:05:47 +1000

> implementation problems.)

I know, I've hit a few of them :-(

However, having a link to a vCalendar resource, flaky as it may be, is still
"good enough" for me to drag and drop into iCal or MS Entourage. It works
sufficiently well with already implemented software. Running code trumps
theory ;-)

> Sure, but is that sufficient?

for lots of things, yes (IMHO).

> In specific, if we have a single

if the elements in core don't provide enough granularity or detail, then
that is when extensions come in.

> extension that covers this well.

Kludging will certainly occur if atom:date-subjective is a MUST. If it's
optional, then it can be left out if extensions get used.

> atom:date-dateline?

actually, I'd want a *link* to a vCalendar resource. it would look something
like:

    <link rel='alternate' type='application/vCalendar' href=... />

> My guess is: poorly.

My philosophy is that if an atom:entry contains meta-data, and also links to
some other resource, then if that resource is used then that resource is
authoritative and the meta-data in atom:entry is advisory. Just like how
link/@type is.

> We shouldn't be doing this

atom:date-subjective can be used for things other than events though.

> off-limits to the Atom core, and encourage extensions.

It's very close to core, and without it some will be tempted to fudge other
core elements to get the same result (eg. putting atom:date-subjective
values into atom:updated).

e.

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 14 Sep 2004 13:00:10 -0700 (PDT)

--- James Aylett <[email-masked]> wrote:
> Atom. 
...
> just against its use for events?

I'm ambivalent on having a subjective date in the
core. I think the equivalent of dcterms:available and
an updated date should be what's in the core. I can
understand that there is a need to have a date field
that maps to the behavior of existing blog tools but
it doesn't mean I like. So I'm -0 on having a
subjective date. 

I definitely am against using or endorsing it as a
mechanism for syndicating events. 

=====

		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 14 Sep 2004 23:47:23 +0200

On Tue, 14 Sep 2004 09:02:42 -0700, Tim Bray <[email-masked]> wrote:

> The only proposal that got more than zero positive feedbacks was my
> "dateline-date".

Just a note, but the word «dateline» isn't really what we're looking for,  
imho. Laurent Le Meur explained it quite well here:

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

   Sorry but it would be a mess to use a name (Dateline) universally
   known in the news industry, and *warp* its meaning in Atom = a news-
   related initiative.

   A dateline appears at the beginning of a story like:
   "PARIS, July 25 (AFP) - American Lance Armstrong became the first
   six-time winner of the Tour de France after completing the final 20th
   stage of the race into Paris here Sunday." The dateline goes up to
   the hyphen!

   Dateline obey to strict editorial rules (you name the country only
   when you send a story to people who don't know where a city is
   situated), identify the location and date logically associated with
   the content (ie origin of the story, a subjective notion), and are
   *human friendly*, so an ISO profile is not recommended for it.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 14 Sep 2004 23:55:32 +0200

> I also think that "subjective" is entirely wrong terminology.

That would, if so, be the feelings you put into the word «subjective», not  
what «subjective» means. Because the meaning of «subjective» fits this  
element perfectly. It's provided by a human, coloured with this or her  
personal meaning on what date fits the entry best. It's clearly not  
objective, so how can it not be subjective?

> just a whim.

Saying that it is subjective doesn't mean they are a whim. They can mean  
something to lots of people. That they don't mean anything to my  
aggregator shouldn't put you off on them being «subjective».

> "Authoritative" is a better term, because this date is chosen by the
> author.

«Authorative» might do. Although I'd say that's subjective too, to some  
extent. :-)

> "atom:date" is right and proper for that.

Yes, probably. I'm still -0 on the whole element.

---

From: Tim Bray <[email-masked]>
Date: Tue, 14 Sep 2004 15:18:23 -0700

On Sep 14, 2004, at 2:47 PM, Asbjørn Ulsberg wrote:

> Just a note, but the word «dateline» isn't really what we're looking 
> for, imho. Laurent Le Meur explained it quite well here:

Right, and I read all that stuff, and thus suggested "dateline-date" 
not "dateline".  Please discuss the actual suggestion, not something 
different. -Tim

---

From: Walter Underwood <[email-masked]>
Date: Tue, 14 Sep 2004 15:59:18 -0700

--On Tuesday, September 14, 2004 11:55:32 PM +0200 Asbjørn Ulsberg 
<[email-masked]> wrote:
> That would, if so, be the feelings you put into the word «subjective»,
> not what «subjective» means. Because the meaning of «subjective» fits
> this element perfectly. It's provided by a human, coloured with this or
> her personal meaning on what date fits the entry best. It's clearly not

If the date comes from a publishing system at the New York Times, does
that make it "objective"? If a human sets the clock on a computer,
does that make machine-generated dates "subjective"?

The objective/subjective split is just not a useful perspective for this.
We're talking about the function of the date in the protocol, not the
intent of any intelligent or automatic source of dates.

The Dublin Core definition for "Date" is clear enough, I think, and
refers to the resource, not people or machines:

  Definition: A date associated with an event in the life cycle of the 
resource.

  Comment: Typically, Date will be associated with the creation or 
availability
  of the resource. Recommended best practice for encoding the date value is
  defined in a profile of ISO 8601 [W3CDTF] and follows the YYYY-MM-DD 
format.

http://www.dublincore.org/documents/dcmi-terms/

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Antone Roundy <[email-masked]>
Date: Tue, 14 Sep 2004 17:22:35 -0600

> I also think that "subjective" is entirely wrong terminology.
Since the word "subjective" doesn't appear anywhere in the proposed 
spec text, I don't think there's much point debating this.  I used the 
word "subjective" because it was the word we'd been using on the 
mailing list to distinguish this kind of date from all the other dates 
we'd been considering.  In the interest of moving on to discussion of 
more important questions, I've changed the abstract to "Define a Date 
Construct to hold a publisher-selected date which need not be tied to 
an event in the publishing process."  If having the word "subjective" 
in the title of the proposal bothers you, just think of it as a random 
string of letters rather than a word.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 15 Sep 2004 07:00:43 +0200

On Tue, 14 Sep 2004 15:18:23 -0700, Tim Bray <[email-masked]> wrote:

>> for, imho.
> Right, and I read all that stuff, and thus suggested "dateline-date" not  
> "dateline".  Please discuss the actual suggestion, not something  
> different.

Since «dateline» doesn't fit very well, I don't feel that «dateline-date»  
fits any better. If it's called «dateline-date», I'll be -1 on the  
element. If it's «date», I'll be -0.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 15 Sep 2004 07:13:36 +0200

On Tue, 14 Sep 2004 15:59:18 -0700, Walter Underwood <[email-masked]>  
wrote:

> that make it "objective"?

If a publishing system provides the subjective date, I'd say it's almost a  
bug. Publishing systems should provide objective dates, like Eric Scheid's  
'atom:modified', while the users of the publishing system should provide  
the subjective ones.

> If a human sets the clock on a computer, does that make machine-generated
> dates "subjective"?

If he does that to hack himself around a limitation in his software; yes.  
It's untestable, but very logical. This is just about the idea of where  
and what the date comes from, and what it represents. If the idea is that  
this element can be provided by both tools and authors, the word  
«subjective» doesn't fit very well. As I said in my previous e-mail,  
«authorative» is probably a better word than «subjective» for the meaning  
this element really has.

> The objective/subjective split is just not a useful perspective for this.

I agree.

> intent of any intelligent or automatic source of dates.

I don't think we should lay protocol-centric meaning into this element --  
it's a part of the format. Not to say that the element won't be useful in  
tools in more protocol-centric ways than e.g. the data inside <content>,  
but protocol elements should be in the protocol specification, while  
all-purpose-elements should be in the format specification. That's at  
least a distinction I find useful.

>   Definition: A date associated with an event in the life cycle of the  

The problem with this description, is that the proposed usage of  
PaceDateSubjective isn't anywhere near an «event in the life cycle of the  
resource». The date is going to be set any time the author feels like it,  
and isn't tied to any event.

I still agree on using the word «date», though, since we've agreed (I  
think) that the dates in the Atom namespace isn't a blueprint copy of the  
Dublin Core elements.

---

From: Sam Ruby <[email-masked]>
Date: Wed, 15 Sep 2004 08:50:25 -0400

Dare Obasanjo wrote:
> 
> I think the equivalent of dcterms:available and
> an updated date should be what's in the core.

Just to make sure I understand you correctly, you would support 
something like PaceDateElement where:

  * The name of the element was changed to a name like "published".
  * Instead of saying creation or availability, clarifying this
    to say initial creation or first availability.
  * The verbage and example relating to changes in this value
    on update were removed.

Note: I'm intentionally widening your proposal as publishing systems 
that statically render and then push out updates to a server may not 
aways be able to precisely predict when the data is going to become 
available, and I would assert that in such circumstances, the difference 
is not all that meaningful.

- Sam Ruby

---

From: Mark Pilgrim <[email-masked]>
Date: Wed, 15 Sep 2004 09:20:03 -0400

> element. If it's «date», I'll be -0.

Why don't we call it "echo"?

-- 
Cheers,
-Mark

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 15 Sep 2004 07:09:00 -0700 (PDT)

>   * The verbage and example relating to changes in

That sounds about right. 

=====

---

From: Sam Ruby <[email-masked]>
Date: Wed, 15 Sep 2004 11:21:56 -0400

Paul Hoffman / IMC wrote:
> hits on one of the things that Atom is supposed to do better than RSSv<=2.
> 
> So, I am explicitly removing my support for this (however it is named), 
> give it a -1, and promise to help work on the extension that covers it 
> better.

I've gone from -0 to -1 on this proposal.  From my perspective, an 
inability to agree on a name is symptomatic of a larger issue: namely 
that there are multiple differing and potentially incompatible opinions 
on how this element should be used; and this is compounded by the fact 
that some of these potential usages are unspecified or unknown.

It is one thing for a spec to be used in novel and unpredictable ways. 
It is quite another to propose something as a standard in the hopes that 
this will happen.

- Sam Ruby

---

From: Eric Scheid <[email-masked]>
Date: Thu, 16 Sep 2004 01:47:49 +1000

On 16/9/04 1:21 AM, "Sam Ruby" <[email-masked]> wrote:

> From my perspective, an inability to agree on a name is symptomatic of a
> larger issue: namely that there are multiple differing and potentially
> incompatible opinions on how this element should be used;
> 

Sometimes symptoms are misleading.

I'm not so sure we're disagreeing on the meaning. One of the reasons we're
having trouble picking a good name is because all the good ones are already
taken, and some of those external definitions are not as well understood as
could be. 

I'm +0 for <date>, -0 for <dateline-date>, and +1 for <content-date>. The
latter seems to be a very accurate name for something described as
"indicating a date and time which the publisher wishes to associate with the
contents of the entry".

Has there been actual recent disagreement with that *description* in this
long thread? Not disagreements as to the appropriateness for this meta-data
item, not disagreements as to whether an elaborate event calendaring
protocol should be shoe-horned into it, not anxiety as to how a date-range
would be handled by an element which is *defined* to be a date/time stamp
... 

Does anyone have an actual concise problem with:

    "indicating a date and time which the publisher
     wishes to associate with the contents of the entry"

noting especially that

    "atom:entry elements MAY contain"

which means it's entirely optional and thus doesn't demand that some bogus
value be put into it just to fill that empty space.

e.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 15 Sep 2004 17:52:12 +0200

> Why don't we call it "echo"?

Funny. If so, I'd still be -0.

---

From: Antone Roundy <[email-masked]>
Date: Wed, 15 Sep 2004 09:57:35 -0600

On Wednesday, September 15, 2004, at 09:21  AM, Sam Ruby wrote:
> that there are multiple differing and potentially incompatible 
> opinions on how this element should be used; and this is compounded by 
> the fact that some of these potential usages are unspecified or 
> unknown.
>
> It is quite another to propose something as a standard in the hopes 
> that this will happen.
>
I'm ready to call this one dead.  I think the arguments against it are 
strong enough, and are not based on misunderstandings, so I can't 
imagine the opposition going away.  Let's move on, and anyone who'd 
like to work on an extension for this sort of thing, let's decide how 
to go about it.  Paul has said he'd participate[1], and I would be 
interested too.  We'd need a mailing list (I could set up an extremely 
simple one, but not one with archives or anything fancy).  And we'd 
have to decide whether to get started now or wait till Atom reaches 1.0 
(I'd be willing to start now).

Antone

[1] http://www.imc.org/atom-syntax/mail-archive/msg09898.html

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 15 Sep 2004 18:37:18 +0200

On Thu, 16 Sep 2004 01:47:49 +1000, Eric Scheid  
<[email-masked]> wrote:

> I'm +0 for <date>, -0 for <dateline-date>, and +1 for <content-date>.

'content-date' was a good proposal. I'd possibly be +0 on that one. Maybe  
even +1.

---

From: Sam Ruby <[email-masked]>
Date: Wed, 15 Sep 2004 12:36:31 -0400

>>  * The verbage and example relating to changes in

OK, I've now written PaceDatePublished.  I don't plan on scheduling it 
for discussion unless it gets the prerequisite three supporters.

- Sam Ruby

---

From: [email-masked] (John Panzer)
Date: Wed, 15 Sep 2004 09:56:22 -0700

Antone Roundy wrote:

> have to decide whether to get started now or wait till Atom reaches 
> 1.0 (I'd be willing to start now).

If there is going to be a group working on an extension for this, I 
believe there is someone in my organization who would be interested in 
participating either now or later (who doesn't have the bandwidth to 
participate on this list[1]).

-John
http://journals.aol.com/panzerjohn/abstractioneer

[1] But then again, who does?

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 15 Sep 2004 23:31:23 +0200

> for discussion unless it gets the prerequisite three supporters.

What date value do you expect the different blogging tools to insert into  
this element? Since all tools give the author full opportunity to mutate  
the date at any given time, it will often not represent «published» or  
anything near it.

Therefore, I'm -2 on this element, particularly since it's required. It  
will be filled with extreme amounts of false and bad data, which is the  
situation we have with <pubDate> and dc:date today. Nothing improves by  
requiring the element.

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 15 Sep 2004 15:19:47 -0700 (PDT)

> the date at any given time, it will often not

I dunno, maybe they could use the current date? Or is
there some platform out there that doesn't have the
equivalent of DateTime.Now? 

They can keep the user entered date on the weblog but
they should use the creation date as the publishing
date for the Atom feed. 

=====

_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com