Subject: Work Queue Rotation #9

From: Tim Bray <[email-masked]>
Date: Tue, 21 Sep 2004 14:44:13 -0700

Atom Public Issues list: 
http://www.intertwingly.net/wiki/pie/AtomPubIssuesList

As always, possibly this is wrong, if so say so.

Current issues:

PaceDateSubjective - clearly no consensus.  My leaning is to mark it 
for closure, unless someone wants to argue that it deserves another 
chance.

PaceExtensabilityAndVersioning, PaceAltExtensibilityAndVersioning, 
PaceExtensionNamespace - none of these have consensus.  We're having a 
useful discussion and generally making progress on a shared 
understanding of the trade-offs (don't stop!), but I don't think that 
at the moment we have a Pace before us that really has a chance.  Maybe 
such a Pace can be made by revising one of these, so it's back to 
Revisit rather than Closed.  -Tim

---

From: Eric Scheid <[email-masked]>
Date: Wed, 22 Sep 2004 08:47:10 +1000

> for closure, unless someone wants to argue that it deserves another

I'll give it a try ...

The concept of the element is very simple and straight-forward: a date
related to the content, not the publishing process.

It's an observable fact that people do publish (e.g.) blogs which are date
oriented, but not tied to the actual objective publishing date. With or
without DateSubjective, those needs will remain. There is no Dublin Core
equivalent. The element is optional.

Put that together and without it people will try meeting their need for a
subjective content-related date with the available date elements, which only
ends up polluting and corrupting those other date elements. Junk data won't
need to be put into DateSubjective because it is optional, and even so it
doesn't hurt to put the created or issued date in there, as that is very
appropriate for a huge percentage of current use.

There is some talk of shunting DateSubjective off to usage specific name
spaced extensions, which doesn't really work because while solving one
specific use case scenario it leaves all the others unsolved, until someone
(a) defines a new module for some other purpose, and (b) aggregator
developers build in support for that new module; and there will always be
use case scenarios for which no module is written/supported. It wouldn't
really be sensible to use the date-commence element from a
conference-schedule namespaced extension if I were publishing a feed of
birthdays, for example.

For more complex use cases (eg. publishing a schedule of events, including
start and stop dates, duration times, location, etc), there is still the
avenue of defining a suitable extension module, remembering too that
DateSubjective is optional and thus conflicts of use can be neatly
sidestepped.

There is lack of clear consensus over what to call the thing, although I
thought people were coming round to calling it 'content-date'. Certainly
other nominated names have their own problems, such as prior usage elsewhere
('dateline-date') or too generic and thus endangering Atom ('date'). I don't
recall off the top of my head any objections to calling it 'content-date'.

e.

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 21 Sep 2004 16:17:38 -0700 (PDT)

> related to the content, not the publishing process.

I find that neither simple nor straighforward. Exactly
what is an application supposed to do with a date with
such an ambiguous and vague definition? 

> without DateSubjective, those needs will remain.

What needs are these? Can you give an example of a
NEED for this date. A user-defined date value that is
somewhat related to the content in some website
specific manner doesn't seem like a construct that
promotes interop nor should it be in the core Atom
spec. 

=====
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 is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

---

From: Eric Scheid <[email-masked]>
Date: Wed, 22 Sep 2004 10:07:05 +1000

On 22/9/04 9:17 AM, "Dare Obasanjo" <[email-masked]> wrote:

> I find that neither simple nor straighforward. Exactly what is an application
> supposed to do with a date with such an ambiguous and vague definition?

It's no less vague or ambiguous than the <title> element (and with fewer
syntax/format complications to boot), and application developers seem to be
able to handle that without their heads exploding.

It's a date element: you can display it, you can columnize it, and you can
sort on it. You might even want to let people search on it. I know I'd find
it interesting to be able to ask "what things are being written about
November 3rd" (as distinct from what just happened to be published on that
day).

It's an optional element. If there is no clear date associated with the
content then don't publish it. If there is a clear date associated with the
entry, do publish it.

> What needs are these? Can you give an example of a NEED for this date.

    a feed of upcoming birthdays
    samuel pepys' diary
    his great^n grandson's diary from the future
    a travel diary, published after the fact
    a simple list of upcoming events at some venue
    a feed of 'on this day' blather
    a series of essays regarding September 11
    a feed of deadlines for a project

for each of theses, can you provide pointers to an appropriate alternative
to DateSubjective? 

> doesn't seem like a construct that promotes interop
> nor should it be in the core Atom spec.

Without it, people *will* munge the other date elements to suit their
purposes. That damages interop considerably.

e.

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 21 Sep 2004 17:39:32 -0700 (PDT)

> able to handle that without their heads exploding.

You're joking right? Since you are starting from such
a ridiculous premise I doubt I'll be able to have a
rationale discussion about this with you. 

As an aggregator author it is quite clear what I do
with the title of an entry. On the other hand what the
heck am I supposed to do with 'a date that is somehow
related to the content in some unspecified way'? How
the heck do I combine multiple instances of this kind
of date with arbitrary semantics from different feeds
in an aggregated feed? 

=====

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

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 21 Sep 2004 17:44:13 -0700 (PDT)

>     a feed of deadlines for a project

Amazing. So for each these use cases the semantics of
the date element is different. How exactly are
applications supposed to do anything sensible with
this date besides display it as content? I'm not even
sure what human readable label can be applied to this
date that describes it with uniform semantics. You
claim this field can be displayed in a column of an
aggregator UI, can you tell me what this column should
be named that will always give consistent semantics to
end users? 

These use cases seem to describe content not a date
field. 

=====

__________________________________
Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now. 
http://messenger.yahoo.com

---

From: Eric Scheid <[email-masked]>
Date: Wed, 22 Sep 2004 11:47:54 +1000

On 22/9/04 10:39 AM, "Dare Obasanjo" <[email-masked]> wrote:

>>> I find that neither simple nor straighforward. Exactly what is an
>>> application supposed to do with a date with such an ambiguous and vague
>>> definition?
>>> 
> You're joking right? Since you are starting from such a ridiculous premise I
> doubt I'll be able to have a rationale discussion about this with you.

OK, I see you have trouble seeing the forest for the trees (that's an idiom
referring to ability to abstract, just to be clear, not a reference to an
arboreal irrelevance). I'll try another tack since you are having such a
hard time.

You claim the definition is "ambiguous and vague" ... if it is as you say
then that would mean there would be differing and conflicting
interpretations. Please provide two conflicting interpretations.

> As an aggregator author it is quite clear what I do with the title of an
> entry. On the other hand what the heck am I supposed to do with 'a date that
> is somehow related to the content in some unspecified way'? How the heck do I
> combine multiple instances of this kind of date with arbitrary semantics from
> different feeds in an aggregated feed?

Try this for starters:
    Display the date with the entry. If you provide a columnized listing for
entries (a la 3 pane aggregators), then let people sort by that column. If
you provide a facility for search, let them search on that field. Let the
user interpret the date according to the context.

What do you do with <pubDate>?
What do you do with <category>?

Neither of those two are highly detailed.

> the date element is different.

Really? For each of these cases the semantic is "here is some date-specific
content, and here is that date in machine-readable form".

> How exactly are applications supposed to do anything
> sensible with this date besides display it as content?

Let the user interpret the date according to the context. If I went off and
wrote a module for birthdays and a module for events and a module for
project deadlines, thus satisfying your demand for narrowly defined
semantics, I'm betting you wouldn't be writing code to support each of those
semantics.

I'm betting that a lot of generic "here's some feeds for your reading
pleasure" applications will simply want to *display* the content, not do
anything fancy with it.

I know I don't want to be wrestling some some bloated kitchen-sink
application when I just want to read my feeds. I also know that when I'm
reading my feeds I want to see the information provided by those feeds,
rather than writing whiny emails to the application author to get them to
support yet another vague extension module for content-date.

> I'm not even

How about "date" or "content date". Is that so hard? Is this UI point
*really* that important? Take a look at this [1] feed in an aggregator that
displays <category>. I've shown screenshots to a dozen people in the film
industry that don't know anything about about RSS, and they all understood
what was happening. Despite the ill-fitting label.

[1] http://www.if.com.au/inproduction/feature-rss.xml

I also showed them feeds where that "category" (ahem) was instead in a
<film:status> element. Surprisingly, I couldn't find an aggregator
application that displayed that element for my users.

> These use cases seem to describe content not a date

Well, that would be because the content-date field is defined in context of
the content. Each use case is a description of a feed of content where there
is a clear example of a content related date being available.

But I think I understand you need a bit of help interpreting them, so lets

>>     a feed of upcoming birthdays

Say I have an extensive circle of friends and acquaintances (hey, it might
happen), and I understand the social power that can be gained by recognising
that tomorrow is someone or other's birthday. I want that social power
because I'm an evil overlord intent on taking over the world. Thus, I want
to be able to be fed a continuing stream of notices that someone or other's
birthday is coming up soon, and not in some vague way like "sometime next
week" but more specific, like 3-Oct-2004. It would be real handy if that
date is in some machine readable form because I could then write a script
that reads that particular feed and injects them into my shopping planner
application (I live to shop).

Funnily enough I wouldn't take some travel diary feed and inject that into
my shopping planner application, that would be just plain silly. I also
wouldn't expect my generic feed aggregator/reader to go all kitchen-sink on
me an provide all the functions of my shopping planner application.

I would expect my generic feed aggregator/reader to at least *display* the
date. It's a low cost way for me to be aware of upcoming birthdays.

e.

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 21 Sep 2004 19:18:48 -0700 (PDT)

> interpretations. Please provide two conflicting

Don't you read your own words? See
http://www.imc.org/atom-syntax/mail-archive/msg10054.html

You want two conflicting examples? Here goes... In
some cases it is the date when the events described in
the content occured (e.g. birthdays, diaries, etc) in
others it is a date which the content talks about
(september 11th essays). 

> user interpret the date according to the context.

That sounds silly. If I have an aggregated feed of the
various feeds above (something that is extremely
trivial to do in 3 pane aggregators by clicking a tree
node) why would I sort deadlines for events, a travel
diary written after the fact, and essays around
September 11th by this field. The resulting sorted
list would be mostly garbage.  

> What do you do with <pubDate>?

pubDate has uniform semantics. Its the publication
date. Why is this difficult for you to understand. 

> What do you do with <category>?

Category is a label that provides a way to group
topics in a particular feed. It is another field that
works well in the context of a single feed but falls
apart in an aggregated feed since there is no
universal system for describing categories. 

> How about "date" or "content date". Is that so hard?

Because it isn't the date. So if I have
publication-date, modified-date and content-date am I
expected to display all 3 or guess and pick one of
them and make it the 'date' that I show the user.
Sounds like an interoperability problem. 

I can already see the questions "Dare, how come when I
view the Samuel Pepys' diary in SharpReader it shows
one date but another in RSS Bandit?" 

=====

---

From: "Roger B." <[email-masked]>
Date: Tue, 21 Sep 2004 23:18:43 -0500

> On the other hand what the heck am I supposed to do with 'a 
> date that is somehow related to the content in some unspecified way'?

Dare: The same thing I'd do with it... dump it into the DB column than you
currently use for pubDate. In some cases, that will cause new items to fall
to the bottom of a sort and out of sight, but such occasional difficulties
are precisely why the world's fine aggregator authors allow us to sort on
more than one field... we can use read/unread, for example.

I'm not personally married to DateSubjective... as long as there's a date in
the core that matches up to the little date you see displayed next to every
blog entry, I don't care about the specifics. But DateSubjective would
certainly fill that need, and a number of others.

--
Roger Benningfield

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 21 Sep 2004 21:41:31 -0700 (PDT)

--- "Roger B." <[email-masked]> wrote:
> currently use for pubDate.

DateSubjective will just be one of at least 3 dates.
At the very least updated/modified and
publication-date/available will also be in Atom. Am I
expected to keep 3 fields or choose subjective-date
over published/available when they both exist?

I am surprised by the fact that some people people
have the nerve to claim RSS is underspecified then
basically argue for a field whose value is 'whatever
the user wants it to be'. 
 
> certainly fill that need, and a number of others.

If Atom adds this date and people still claim that the
goal of Atom is to be a well specified and rigorously
defined then that truly will be hypocrisy at its
finest.  

I've voted my -1 on this so I guess I'm done here. 

=====

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

---

From: Tim Bray <[email-masked]>
Date: Tue, 21 Sep 2004 22:02:39 -0700

> over published/available when they both exist?

Don't be too sure.  We just barely got Updated done, and I didn't think 
that DateSubjective or date-dateline or whatever was that 
controversial.  Whatever you think about this one, don't make up your 
mind based on an assumption that we'll get "publication-date/available" 
(whichever one that was) done. -Tim

---

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

> others it is a date which the content talks about

So in one case we are talking about some significant event and the date in
question goes into the content-date field; and in the second case we are
talking about some significant event and the date in question goes into the
content-date field.

Tell me again how they are two conflicting interpretations? I can't see the
difference, not at all.

> list would be mostly garbage.

Why are you aggregating essays about 9/11, deadlines for events, and a
travel diary into one pile? Garbage in, garbage out.

Meanwhile though in another application (iCal) I have entries for birthdays,
reminders to pay bills, meetings scheduled, project deadlines, opening
nights for new cinema releases, and a bunch of "on this day" notes. I can
view these entries in a list view, and I can sort by the date field. I can
see that this Friday is going to be one hell of a busy day, including
squeezing some time in between meetings to pay some important bills, plus
I'll have some trivia to share over the water cooler, and I know what movie
I might just go see after work. All this regardless of when those entries
were published or updated or modified.

e.

---

From: Sam Ruby <[email-masked]>
Date: Wed, 22 Sep 2004 04:34:32 -0400

> certainly fill that need, and a number of others.

At the moment, there already is one date in Atom... <updated>.

If there were a second date, which one would be the "little date you see 
displayed next to every blog entry"?

If there is a need for a second date, would PaceDatePublished be a 
better fit?

- Sam Ruby

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 22 Sep 2004 04:07:39 -0700 (PDT)

> (whichever one that was) done. -Tim

If Atom ships with SubjectiveDate and Updated but no
available/Publication-Date then all the statements
that people like you, Mark Pilgrim and Sam Ruby have
been making about how much more well specified and
rigorously defined Atom will be over RSS would have
been one big joke. 

This field is a big leap backwards from what exists in
RSS today especially if it is the only other date to
make it into Atom. 

=====

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

---

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

> travel diary into one pile? Garbage in, garbage out.

I hope the Atom working group will be sure to explain
this to the folks at Technorati, PubSub, and Feedster
which allow me to subscribe to an Atom feed of search
results over RSS/Atom feeds. 

Thanks for clarifying that their entire reason for
being is broken. 

I am actually now very amused by this entire
discussion. If PaceDateSubjective can be any semantics
that the publisher wants then Feedster and PubSub can
replace the value of subjective-date in the items they
show in the searches with whatever they find more
amenable (e.g. date that Feedster/Technorati found the
item) and will still be completely spec compliant.
Assholes are going to have fun with this field. 

=====

__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

---

From: James Aylett <[email-masked]>
Date: Wed, 22 Sep 2004 12:39:50 +0100

> displayed next to every blog entry"?

That should be up to the user. I personally don't give a damn when in
time something was updated. Most feeds I read don't update previous
entries very much, and when they do I don't usually bother to read
them (because they're usually typos and so forth - so unless I was
particularly interested in a given article/post, I'm not going to care
about updates). I don't, absolutely do not want to sort on updated. So
I want a second date in there, definitely, and that's the one I want
to see.

The exception to this is something like the BBC's site, where news
stories are continually updated as they develop. There I'd rather sort
by updated, because it puts all the changes at the top.

So it should be up to the user, and ideally configurable
per-feed. (And if a particular UA chooses for its users, it just gets
a self-selecting user set; it's not like that's a problem, given the
choice in number of possible aggregators around.)

> If there is a need for a second date, would PaceDatePublished be a 

I don't know, but I suspect that the vast, vast majority of feeds do
not have a substantively different published date to the proposed
content date. So most people (particularly personal blogs) won't
notice the difference.

The difference becomes apparent in things like:

 * retrospective articles [1]
 * announcements of events (eg: W3C events feed, which is for me at
   least almost completely useless because I can only sort by updated
   in my current aggregator; published would be no better)

[1] I have an idea that the BBC might offer specialist feeds for big
news groups, such as Israel/Palestine. Sometimes they write
retrospective supporting articles to new stories (we used to get them
all the time in newspapers in the UK; history and background sidebars)
which go into more detail about specific previous events. Having the
content date there would be useful, because although you'd generally
want to sort on published (when a new article becomes available -
note, not updated, because again it might just be minor adjustments
rather than major new information), but to get an overview of the
history you could sort on content date, and work from oldest event
covered to most recent - or just skip through easily to find out why
everyone is talking about 1967 so much.

I guess that actually argues for having updated, published AND content
dates. This isn't going to make me popular, I can tell :-). I'd
probably rather have published than content date, because even when
they're distinct, published is quite a bit more useful to me. I agree
with Dare that not having published in Atom would be a step backwards
(I disagree with him that letting content date in would be a bad
thing, but I'm willing to let PaceDateSubjective drop to reach
agreement - it isn't that important to me, and it's certainly not as
important as published).

James

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

---

From: Sam Ruby <[email-masked]>
Date: Wed, 22 Sep 2004 08:07:55 -0400

> I want a second date in there, definitely, and that's the one I want

I'd just like to note in passing that the definition of atom:updated is 
different that atom:modified:

    The "atom:updated" element is a Date construct indicating the most
    recent instant in time when a change to the entry was made that the
    publisher wishes to bring to the attention of subscribers.  For
    example, such changes might not include minor adjustments like
    spelling and grammatical corrections.

    atom:entry elements MUST contain exactly one atom:updated element.

    Publishers MAY change the value of this element over time.
    Processors MAY present entries sorted using this value.  Processors
    MAY choose not to present entries until the instant in time specified
    in the atom:updated element has passed.

>    in my current aggregator; published would be no better)

While events seem deceptively simple, a lot of people have tried with 
only mixed success to model them in an interoperable fashion.

I am of the opinion that the best thing that can be done at this point 
is to leverage the ability to link to arbitrary resources.

As an example: if the 61st IETF - Washington, DC, USA (November 7-12, 
2004) had a tangible rfc2445 text/calendar representation on the web, 
everybody could link to it.  Technorati could provide a means to query 
who had linked to a given event.  Aggregators could provide an "add to 
calendar" menu item.

- Sam Ruby

---

From: James Aylett <[email-masked]>
Date: Wed, 22 Sep 2004 13:19:40 +0100

> Thanks for clarifying that their entire reason for

Certainly it's useful to aggregate things from arbitrary sources. I do
it all the time; however I don't necessarily expect to get the same
consistency of interaction as when I'm dealing with a single feed. For
one thing, some feeds have categories and some don't, so if I'm
grouping by category in a feed, that may not work usefully across
several feeds. Dates pose similar problems, even now, with optional
dates and optional extensions in RSS.

The more slightly different types of data you aggregate, the fewer
operations are available to you.

> If PaceDateSubjective can be any semantics that the publisher wants
> then Feedster and PubSub can replace the value of subjective-date in
> the items they show in the searches with whatever they find more
> amenable (e.g. date that Feedster/Technorati found the item) and
> will still be completely spec compliant.

PubSub could replace the title with what they wanted and it would
still be completely spec compliant. Not true to what the author
intended, but certainly true to what the publisher of the PubSub feed
intended.

Anyway, I don't agree that PDS can be "any semantics that the
publisher wants". I don't really see what's ambiguous about saying
that it's "the date of the subject of the entry". The only word that
is even slightly ambiguous there (as I see it) is 'subject'. There's a
potential problem with a wide-ranging entry, because that might not
have an explicit subject; my feeling is that PDS is an optional feed
that will be of most use in specialist cases (news sites, event
listings) rather than personal blogs.

> Assholes are going to have fun with this field.

Assholes are going to have fun with any field they like; they're
assholes. Want to be screwy? Always put in an <title> with a single
space in it. That's spec compliant, but not exactly useful. Some
people will consider it annoying, some an artistic use of the freedom
of the spec (:-). People who don't like how a feed works will ignore
that feed; if it's of important data, someone else will create a feed,
and everyone is happy again.

James

---

From: James Aylett <[email-masked]>
Date: Wed, 22 Sep 2004 13:27:34 +0100

>    in the atom:updated element has passed.

Oops, you're right. Erm ... I still don't want to sort by updated. I'd
still rather sort by published, because even substantive changes don't
interest me all that much; I read too many things to care if someone
has changed a little. (This is on a bit more reflection :-)

Again, exceptions abound. And with updated I can of course only read
substantive changes to feeds I follow that closely. I still want
published, at a minimum, and I still think content date has good uses.

> only mixed success to model them in an interoperable fashion.

I'm not wanting to model them; I'm wanting to talk about them. I don't
have to have an XML representation of an event to be able to write an
article saying "Announcing the 2004 WitchCon", and later another
article saying "The Guest List for 2004 WitchCon". But it would be
useful, to me at least, to see such articles displayed in order of
when the event will take place. (Probably with a marker in the feed
display showing where now() is.)

> who had linked to a given event.  Aggregators could provide an "add to 

I agree that being able to link with some semantics ("I'm linking to a
FOO with respect to this entry") is (a) good, (b) better, in the short
term, than trying to have an Atom extension to do the same thing
inline to the feed.

However not everything will have a text/calendar representation on the
web, and even those that do won't always be used (because it'll take a
while for someone to figure out the discovery required to make the
interface quick enough for lazy people :-). And even in the case where
an entry about an event is linked to its text/calendar representation,
you don't necessarily want to fetch that representation just to figure
out the order to display all such entries if you care about the order
their cited events occur in. So +1 on using linking like this, but I
still like content dates.

James

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 22 Sep 2004 05:36:04 -0700 (PDT)

> only mixed success to model them in an interoperable

Really? It seems that iCalendar and vCalendar are
supported by the various major calendaring/PiM tools
across a variety of platforms. 

What major lack of interoperability issues exist in
this space? 

> is to leverage the ability to link to arbitrary

I do think it is the simplest and most likely to
quickly gain widespread support. I'm not sure I agree
it is the best since the event data is now opaque to
RSS/Atom consumers. :) 

=====

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 22 Sep 2004 05:41:44 -0700 (PDT)

--- James Aylett <[email-masked]> wrote:
> that it's "the date of the subject of the entry".

I don't see that quote at
http://www.intertwingly.net/wiki/pie/PaceDateSubjective
Instead I see a description that is basically any
semantics that the publisher wants. Is there a
previous or more updated version of PaceDateSubjective
that we are discussing? 

=====

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 22 Sep 2004 05:59:14 -0700 (PDT)

> display showing where now() is.)

The last time this came up I mentioned that I don't
think the way to represent events in Atom should be to
try and sneak as much event-specific metadata into the
core as possible. The right way to do this is to
define an events module and then pick which ones are
relevant to teh entry and use those. 

In the examples you've given I don't see why an
<event:start-date>  element on the entry doesn't work.
That way you can also do things like add
<event:location> & <event:duration> and more savvy
aggregators can do smart things like add it to your
Outlook calendar if needed. 

=====

---

From: Sam Ruby <[email-masked]>
Date: Wed, 22 Sep 2004 08:59:11 -0400

> What major lack of interoperability issues exist in

This happened to be a topic at FOO camp.  Note: everything I am saying 
here is second hand.

Apparently timezones and recurring events, and events with a duration 
that span multiple days pose interoperability problems.  The following 
was also referenced:

   http://www.scheduleworld.com/outlookInteroperability.html

People seem to like scheduling things on dates like "the Tuesday after 
the first Monday in November".

> it is the best since the event data is now opaque to

They are only opaque in the sense that dates are opaque... you need the 
value itself is structured and needs to be parsed.  Something worth 
watching, particularly as it is already largely consistent with the 
current Atom Protocol:

   http://greenbytes.de/tech/webdav/draft-dusseault-caldav-01.html

Net: these people are in the best position to define something that is 
interoperable.  And they are well aware of the value of an XML based 
grammar.

- Sam Ruby

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 22 Sep 2004 06:12:23 -0700 (PDT)

> watching, particularly as it is already largely

It seems you misunderstand. As James points out, if I
want to do something like 'sort all events by date' in
my aggregator that means it'll have to fetch the
iCalendar/vCalendar files for every entry in the feed
then know how to parse out the date using your
approach. 

=====

---

From: James Aylett <[email-masked]>
Date: Wed, 22 Sep 2004 14:38:18 +0100

On Wed, Sep 22, 2004 at 05:59:14AM -0700, Dare Obasanjo wrote:

[Events]
> relevant to teh entry and use those. 

I agree. If PaceDateSubjective were /only/ useful for events, I
wouldn't support it. I don't even think its main use should be thought
of in terms of events. However the semantics that I understand it to
possess mean that you could get use out of it for entries that are
about events. It doesn't preclude putting a proper event structure in
place, be that embedding rdfCal, or linking to text/calendar, or
having an event: namespace that is document-like XML (as opposed to
RDF). But that event structure won't go into core, where I'm still not
convinced it isn't appropriate to put a content date in.

But I'm not convinced we need it either. I could certainly live
without it.

> In the examples you've given I don't see why an <event:start-date>
> element on the entry doesn't work.  That way you can also do things
> like add <event:location> & <event:duration> and more savvy
> aggregators can do smart things like add it to your Outlook calendar
> if needed.

If this were primarily about events, I'd agree. And although you
/could/ use event:start-date in place of a content date for
retrospectives, the semantics (in my mind at least) are slightly
different. I don't want to declare an event for the third Arab-Israeli
war; if nothing else, I doubt that most news publishing systems would
bother to support this for some time, because they don't care about
events. But I can see them having a date field to tag a timeline,
because automated timelines within groups of articles isn't uncommon.

Okay, so I don't have to declare a complete event, but I'm wary of the
idea of having entries with an event:start-date but no event:end-ddate
or event:duration.

(And who wants a six day event in 1967 added to their Outlook
calendar? Or even be prompted for it?)

James

---

From: James Aylett <[email-masked]>
Date: Wed, 22 Sep 2004 14:44:44 +0100

On Wed, Sep 22, 2004 at 05:41:44AM -0700, Dare Obasanjo wrote:

> > Anyway, I don't agree that PDS can be "any semantics
> > that the publisher wants". I don't really see what's
> > ambiguous about saying

No, but I'm unhappy with the wording in the abstract and proposal (in
fact, I suggested changes to the abstract to bring them in line with
the above, which was before there was camera-ready copy in the
proposal). The first bullet in the rationale is closer to what I'm
saying - although I've just realised that I'm being somewhat more
restrictive. I think being more loose here does exactly what you say,
ie makes the element useless.

The proposal muddies the waters further by mentioning automobile model
years and magazine edition months without explaining what the relevant
entry would be about. An article about a particular issue of Playboy
could sensibly use PDS; I disagree strongly with the idea that an
article /within/ a particular issue of Playboy could sensibly use
PDS. (It doesn't actually strike me as anything terribly important to
communicate within Atom, but if I'm wrong it's specific and weird
enough that an extension could be written.)

(Sorry, hadn't noticed the camera-ready proposal go up. It's not
nearly tight enough for me to be happy with it.)

James

---

From: Brett Lindsley <[email-masked]>
Date: Wed, 22 Sep 2004 08:54:17 -0500

It would seem that events generally refer to something that *will* take 
place
whereas PaceDateSubjective generally refers to something that *has* taken
place. I can see being useful for situations where PaceDateSubjective refers
to the actual date the content occured (such as pictures of 9/11) that are
now recently published. This is a more generalized view of the linked 
content
other than the "blog centric" view.  Brett Lindsley, Motorola Labs.

---

From: "Roger B." <[email-masked]>
Date: Wed, 22 Sep 2004 11:51:12 -0500

> If there is a need for a second date, would PaceDatePublished be a

Sam: IMO, yes... but I'm trying to approach these things with a spirit of
compromise. The little date next to a blog entry can be initially set or
changed by a human and we've got folks around here who feel very strongly
that anything named "published" cannot be subject to end-user control.

So DateSubjective strikes me as a useful work-around. Sure, I'd rather have
something that's spec'd as "the date the entry was published", and leave the
definition of "published" up to each content producer... but I'm not willing
to argue about it for another six months. And I foresee much arguing around
DatePublished.

OTOH, I suppose one could argue that I need to have more faith in the
process. :D 

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

---

From: "Roger B." <[email-masked]>
Date: Wed, 22 Sep 2004 12:41:36 -0500

> But I can see them having a date field to tag a timeline...

James: For the record, I want to say that "timeline" is probably the best
description I've yet seen for the date in question.

Someone keeping a diary doesn't care about "published", "modified", or
whatever else... she cares about the timeline of her life. It doesn't matter
that Entry #1234 was entered into the system four days after Entry #1233.
What matters is that Entry #1234 describes the events of her birthday party
on 2004-08-10, and Entry #1233 describes her hangover on 2004-08-11. (Said
hangover being the reason she couldn't post about her party for a few days.)

When I got back from my Florida vacation, it took me several months to go
through hours of occasionally mis- or unlabeled DV tape, extract stills, and
begin posting entries to my travelblog. As a result, one day I was posting
an entry about what I did on 2003-03-18, and the next day I would find a
cache of footage from 2003-03-12. And the next day, poof, there was the
missing footage from 2003-03-14!

Details of the publishing process are immaterial in such cases. If I go back
and page my way through my vacation memories, I want things ordered
according to when they happened... not when I happened to be sitting in
front of a computer writing about them. And I'm not going to waste anyone's
time crafting sort-proof text descriptions like "okay, this took place two
days after my last entry, but four days before the entry before that." The
date of the event is the date that goes into my blog, and thus into
<pubDate> in my existing RSS feed.

Call that date what you will... "subjective", "published", "timeline", or
whatever. Atom needs a spot for it.

---

From: Graham <[email-masked]>
Date: Wed, 22 Sep 2004 19:04:45 +0100

On 22 Sep 2004, at 6:41 pm, Roger B. wrote:

> As a result, one day I was posting

So DateSubjective is the date the entry is about? This is a world away 
from the dateline-style uses Tim et al were suggesting before. I think 
there is room for a non-specific subjective date that loosely describes 
when the entry was written (like newspaper datelines do). I don't think 
that storing the date an entry discusses is useful or practical.

(btw I think "automobile model years" is a US specific phenomena - not 
a good example)

Graham

---

From: "Roger B." <[email-masked]>
Date: Wed, 22 Sep 2004 14:41:41 -0500

> So DateSubjective is the date the entry is about?

Graham: That's one way of looking at it. Another is that DateSubjective is
the date I would have posted something, if the technology hadn't gotten in
the way. 

For example, if my Canon camcorder could spit out stills, package them up,
and post them to my blog from right there on the beach, I would... but it
can't, so the process is delayed until I can get back to my desktop, my
Firewire, and so on. I could fill my blog with placeholder posts via
cellphone, and then go back to edit-in the real content later, but that
would be a waste of everyone's time. Far better to just insert posts into
appropriate points in the timeline as they are assembled.

> I don't think

It's a function that users have demanded from me when wearing my Publisher
Hat (I still get complaints that old versions of the app have fixed dates),
and I've never encountered a problem when consuming similar feeds while
wearing my Aggregator Hat. So from where I'm standing, it's beyond useful
and practical... it's a necessity.

--
Roger Benningfield

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 22 Sep 2004 13:05:49 -0700 (PDT)

> technology hadn't gotten in

I don't see how we can have a rational discussion of
this Pace if everyone keeps making up their own
semantics of what the date field means. Then again,
the current Pace says the semantics is whatever the
publisher wants so I guess the confusion on this
thread is a preview of the confusion that will occur
in the wild when
PaceItMeansAnythingYouWantItToMeanDate makes it into
the Atom spec. 

> and practical... it's a necessity.

If you feel it is a necessity then write up a Pace and
get your 3 supporters.   

=====

---

From: Graham <[email-masked]>
Date: Wed, 22 Sep 2004 21:07:06 +0100

> the date I would have posted something, if the technology hadn't 

The proposal is that the date will normally just be displayed alongside 
the content, like the title, right? If the stills/video are the 
content, fair enough. But if you add a caption when you post it, say 
"Me in Florida last week", then that will display like this:

   ** 16/9/2004 **
   ** Me in Florida last week **
   [Picture]

 From this, when was the picture taken?

> Hat (I still get complaints that old versions of the app have fixed 
> dates)

That's fine - I think there's an opening for a subjective date that 
provides context to the entry. DateSubjective as written doesn't do 
that.

Graham

---

From: "Bob Wyman" <[email-masked]>
Date: Wed, 22 Sep 2004 18:09:32 -0400

Dare Obasanjo wrote:
>> Why are you aggregating essays about 9/11, deadlines
>> for events, and a travel diary into one pile? 
>> Garbage in, garbage out.
> results over RSS/Atom feeds. Thanks for clarifying 
> that their entire reason for being is broken. 
	Errr... I think PubSub still has a reason for being... Please don't
tell me you have a good argument to justify our demise. It would be very
inconvenient if you were right.
	Dare is right that there isn't much that we can do with a subjective
date in a cross-feed environment. Since the date is subjective, it has
blog-local semantics and that drastically diminishes its utility for either
collation or selection. We already have enough trouble with the folk that
can't seem to get clued into the fact that the year is not 1970.
	I'd really like to see a "first published" date which was defined in
some rigorous way so that I could yell and scream at people who didn't get
it right. i.e. Once an atom:id is associated with a "first published" date,
that date should never change. Also, the "first published" date should never
be in the future, etc.
	There are lots of other dates I'd like to see (i.e.
date-this-entry-is-about, date-we-PubSub-found-this-entry,
date-to-embargo-this-entry-until, date-to-delete-this-entry, etc.) but most
of them can be done as extensions and don't need to be dealt with now. What
we need now, to go with Updated is Published.

		bob wyman

---

From: Tim Bray <[email-masked]>
Date: Wed, 22 Sep 2004 15:16:23 -0700

> If you feel it is a necessity then write up a Pace and

Yes, please do; there have been some compelling arguments in favor of 
this kind of function, but the Pace as currently written has apparently 
immovable opposition (not just Dare), so we need a candidate 
replacement.  -Tim

---

From: Sam Ruby <[email-masked]>
Date: Wed, 22 Sep 2004 18:25:07 -0400

> we need now, to go with Updated is Published.

While I'm waiting for this chatter to die down, you can influence which 
Date proposal I schedule next by adding your name as a supporter to one 
or more of the following:

   http://www.intertwingly.net/wiki/pie/PaceDateUpdated2
   http://www.intertwingly.net/wiki/pie/PaceDateModified
   http://www.intertwingly.net/wiki/pie/PaceDatePublished

In the event of a tie, I will take them in the order they were initially 
created (i.e, the order listed above).

- Sam Ruby

---

From: Graham <[email-masked]>
Date: Wed, 22 Sep 2004 23:44:59 +0100

On 22 Sep 2004, at 11:25 pm, Sam Ruby wrote:

> While I'm waiting for this chatter to die down, you can influence 
> which Date proposal I schedule next by adding your name as a supporter 
> to one or more of the following:
>

I'm in on that one. The idea's great but it doesn't make sense unless 
it's optional.

(the wording of this pace is atrocious as usual, but we're sorting all 
that out later, right?)

Graham

---

From: Tim Bray <[email-masked]>
Date: Wed, 22 Sep 2004 16:00:36 -0700

>   http://www.intertwingly.net/wiki/pie/PaceDatePublished

Fine on the other two, but is PaceDateUpdated2 really still relevant 
now that we've approved PaceDateUpdated?  Eric Scheid, Asbjørn Ulsberg, 
and Graham Parks are listed as supporters... any of you guys want to 
either un-support or say a word why the WG should invest time in this? 
-Tim

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 22 Sep 2004 16:01:49 -0700 (PDT)

--- Graham <[email-masked]> wrote:
> I'm in on that one. The idea's great but it doesn't

Why are you in? If I remember correctly
http://www.intertwingly.net/wiki/pie/PaceDateUpdated
is already accepted for incorporation into the spec
and is better written. 

=====

---

From: Sam Ruby <[email-masked]>
Date: Wed, 22 Sep 2004 19:04:46 -0400

> (the wording of this pace is atrocious as usual, but we're sorting all 

If you feel that way, I would recommend improving the wording, as lact 
of clarity seems to be contributing to the demise of PaceDateSubjective.

I would also recommend either making it clear whether this is in 
addition to, or intended as a replacement of, the current atom:updated 
element.

- Sam Ruby

---

From: Sam Ruby <[email-masked]>
Date: Wed, 22 Sep 2004 19:07:58 -0400

> is already accepted for incorporation into the spec

Not only has it been accepted for incorporation, it has been 
incorporated into draft-ietf-atompub-format-02.  Check out section 5.6:

http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-02.txt

- Sam Ruby

---

From: Graham <[email-masked]>
Date: Thu, 23 Sep 2004 00:41:37 +0100

> addition to, or intended as a replacement of, the current atom:updated 

Essentially I want to keep atom:updated but make it optional, such that 
it's only included when publishers have the information about updates, 
and have thought it through. You +1'ed this before:

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

I'm not really bothered about the definitions - both specs include 
well-intentioned nonsense.

Graham

---

From: "Roger B." <[email-masked]>
Date: Wed, 22 Sep 2004 20:14:24 -0500

>  From this, when was the picture taken?

Graham: One would have to assume that the author wouldn't date it one way
and write another. And if they *do*, then the assumption has to be that she
knew what she was doing, and was looking for whatever effect this creates.

> provides context to the entry. DateSubjective as written doesn't do

It looks like it does from here. But as I said earlier, I'm not losing any
sleep over DateSubjective. As written, DatePublished would work, since the
"lifecycle of an entry" is left to the publisher to define. 

I'm skeptical about DatePublished surviving the process as-is, though. So
DateSubjective seems like something worth defending, at least momentarily.

---

From: Graham <[email-masked]>
Date: Thu, 23 Sep 2004 02:38:12 +0100

> knew what she was doing, and was looking for whatever effect this 

No. The Pace doesn't say anything about that - you're projecting that 
onto it. When it comes down to it, the Pace doesn't really say anything 
at all about how this date works or what it's used for. If it is the 
case that it can be used for basically anything, it needs to say that 
(which I don't think it does). And it needs more examples than the one 
and two-halves it has.

Close PaceSubjective, put the concept back on the pile.

Graham

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 22 Sep 2004 20:23:32 -0700

Hi again. I'm seeing discussion pro and con of paces other than 
PaceDateSubjective in the PaceDateSubjective thread. Good list 
hygiene says...

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Eric Scheid <[email-masked]>
Date: Thu, 23 Sep 2004 13:25:51 +1000

>  http://www.intertwingly.net/wiki/pie/PaceDateUpdated2

PaceDateUpdated2 was a revision of PaceDateUpdated. About the only spec
relevant difference was making the element optional.

If there is no +1 for optionality I'm happy to withdraw this pace.

e.

---

From: Eric Scheid <[email-masked]>
Date: Thu, 23 Sep 2004 17:22:56 +1000

> immovable opposition (not just Dare), so we need a candidate

I'm writing a replacement pace, so if you're interested then please send me
an off-list email.

e.

---

From: Danny Ayers <[email-masked]>
Date: Thu, 23 Sep 2004 12:29:31 +0200

> These use cases seem to describe content not a date

These all refer to dates, so a "Date" field might be suitable for all
of them, they all have the same semantics on that level. To make them
more useful you can add more detail. If your reader doesn't understand
these semantics, it can always fall back on displaying them as
additional content. But I think it would be wrong to back-engineer the
limited model used by many (not all) applications onto the
specification.

Regular HTML web pages provide human-readable content.

RSS 2.0 feeds give partial separation of human-readable content and
machine-readable description of that content.

RSS 1.0 feeds allow more fine-grained description.

I would suggest that Atom can do the same as RSS 1.0 by providing a
generic date and then using an extension mechanism to further qualify
it.

If you had the common, top level term "Date" you can further qualify
 
> >     a feed of upcoming birthdays
type: event
subtype: birthday

> >     samuel pepys' diary
type: entry date
subtype: created

> >     his great^n grandson's diary from the future
type: entry date
subtype: publication date (?)

> >     a travel diary, published after the fact
type: entry
subtype: event (maybe)

> >     a simple list of upcoming events at some venue
type: event
subtype: geo-located

> >     a feed of 'on this day' blather
type: entry
subtype: event (maybe)

> >     a series of essays regarding September 11
type: entry
subtype: publication date (?)

> >     a feed of deadlines for a project
type: event
subtype: task

If I had time I'm sure I could find terms in existing RDF vocabularies
that would fit each of these descriptions reasonably well. But that's
not really the point, beyond suggesting that there are deployed
precedents. In general, there is benefit in making it possible to
express explicit data of this kind in the feed. If you merge useful
information back into the content at the point of generation, then all
kinds of applications (e.g. passing events into your personal calendar
app) become a lot harder. Pushing unrecognised data at the client side
into the content for simple readers is a relative no-brainer.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Walter Underwood <[email-masked]>
Date: Thu, 23 Sep 2004 08:04:55 -0700

>> >     a feed of deadlines for a project

Some of these are primarily categories. "September 11" could
be replaced with a non-date term, like "WTC Terrorist Attack".

Others are structured content, like calendar events.

Remove those and it makes more sense.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Graham Parks <[email-masked]>
Date: Thu, 23 Sep 2004 08:24:38 -0700

> be named that will always give consistent semantics to

+1

(also, displaying it even without a label would often produce nonsense if some of the use cases suggested on this thread were followed. The semantics need to be narrowed down to at least say it may be displayed alongside the content)

Graham