Subject: PaceDateSamRuby +1

From: Tim Bray <[email-masked]>
Date: Wed, 11 Aug 2004 08:37:17 -0700

It respects prior art, provides the minimum necessary to declare 
victory and (this is very important), in my opinion based on observing 
the discussion to date, it's about the most that we can actually build 
consensus around.  BTW, in my experience "the most you can get 
consensus around" often turns out to be also "the right answer". -Tim

---

From: Norman Walsh <[email-masked]>
Date: Wed, 11 Aug 2004 12:28:03 -0400

/ Tim Bray <[email-masked]> was heard to say:
| It respects prior art, provides the minimum necessary to declare
| victory and (this is very important), in my opinion based on observing
| the discussion to date, it's about the most that we can actually build
| consensus around.  BTW, in my experience "the most you can get
| consensus around" often turns out to be also "the right answer". -Tim

+1

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Almost every man wastes part of his
http://nwalsh.com/            | life in attempts to display qualities
                              | which he does not possess, and to gain
                              | applause which he cannot keep.--Dr.
                              | Johnson

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 11 Aug 2004 09:56:49 -0700 (PDT)

+1 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #25
No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot.

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

---

From: Graham <[email-masked]>
Date: Wed, 11 Aug 2004 12:07:08 -0500

Differing interpretations of the DC spec as regards Atom + different 
expected behavior + people trying to be clever = my definition of 
interoperability hell (And lots of new convoluted date code in  Shrook 
that doesn't actually work all of the time, presumably)

"cleanly and thoroughly specified"

Graham

---

From: Elias Torres <[email-masked]>
Date: Wed, 11 Aug 2004 13:20:35 -0400

+1 I like it too, but I thought Atom WG was not too comfortable with
bringing items from DC into the spec? i.e. not using dc:title and
using atom:title, etc, etc.

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 11 Aug 2004 10:48:18 -0700 (PDT)

> using atom:title, etc, etc.

Extensions are going to exist and the WG should
acknowledge that. I think makes a lot of sense to say
"all the complex, non-mainstream use cases should be
solved in extensions". 

=====

__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 11 Aug 2004 10:50:03 -0700 (PDT)

> that doesn't actually work all of the time,

How does your stand of 'include umpteen dates in the
spec and then consumers just ignore the ones they
don't like' any more of a recipe for interoperability
than saying 'here is the core date construct that must
be supported and all the funky stuff should be done in
optional extensions'? 

=====

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

---

From: Elias Torres <[email-masked]>
Date: Wed, 11 Aug 2004 14:06:26 -0400

Right, I'm fully aware that there will be extensions, but will we
state in the spec to use dcterms:* for date or will we simply say atom
only has atom:d?

Regards,

Elias

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 11 Aug 2004 21:01:16 +0200

On Wed, 11 Aug 2004 08:37:17 -0700, Tim Bray <[email-masked]> wrote:

> It respects prior art, provides the minimum necessary to declare victory  
> and (this is very important), in my opinion based on observing the  
> discussion to date, it's about the most that we can actually build  
> consensus around.

-1 here. I feel that it just caters for the current practice without doing  
anything to improve it. I think the current practice needs improvement,  
which is why I would like more and better specified dates available in the  
core.

Allowing people to use Dublin Core elements does not encourage them to do  
so. I think we should encourage more shared semantics between tools, which  
PaceDateSamRuby does not.

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

---

From: Ken MacLeod <[email-masked]>
Date: 11 Aug 2004 14:39:53 -0500

Elias Torres <[email-masked]> writes:

> state in the spec to use dcterms:* for date or will we simply say
> atom only has atom:d?

My reading of PaceDateSamRuby is that Atom 1.0 will only specify,
validate, and test interoperability on one date, atom:d.  All dct:*
dates are optional, and if specified, validated, or tested for
interoperability it will be "later" or elsewhere.

Two concerns I have with this Pace:

 1) Less important: it does not suggest any interoperable means for
    indicating to a consumer that the entry has changed (at any level
    of significance, but I'm only concerned about the least
    significance, such as entity tags, file timestamp, or database
    change time).

    The impact of this is that consumers must continue to *always* use
    client-side hashing on each entry each time they read a feed.
    This is not critical, as the "change" indicator only tells you
    when you *don't* have to do hashing (after checking the change
    indicator, the consumer may/should still do hashing of fields they
    display to see if they need to signal the user that a change has
    occurred that is visible to them).

 2) More important: it does not suggest any interoperable means for a
    client to distinguish between two versions of the same entry
    within a feed (or index or archive).  Earlier proposals used a
    simple, date-based approach for this that allowed core Atom 1.0
    interoperability to be achieved while still leaving a "versioning"
    model to a separate effort.

I'm not comfortable with the validation and interoperability testing
aspects of the other two Paces (PaceDateAntoneRoundy,
PaceDateAsbjornUlsberg), but I also find this Pace critically lacking
this simple solution to the above requirements.

To provide a concrete example of added spec text, I have created
PaceDateKenMacLeod that includes that date.  It is otherwise identical
to PaceDateSamRuby, so you can skip right to the proposal for the
atom:e element.

  -- Ken

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 11 Aug 2004 22:50:07 +0200

On 11 Aug 2004 14:39:53 -0500, Ken MacLeod <[email-masked]> wrote:

> PaceDateKenMacLeod that includes that date.

Seeing that there are several widely used publishing tools that doesn't  
support both of the atom:d and atom:e elements your pace is proposing, I  
don't think both atom:d and atom:e can be MUST.

That's what I like about PaceDateAsbjornUlsberg and PaceDateAntoneRoundy.  
They only require _one_ date, but they don't specify which one that should  
be, since current practice is so chaotic that it's impossible to require  
all tools to support one set of (shared) semantics now.

Instead, the specification should hash out the semantics we find useful,  
and hope that the tools will support and share these eventually.

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 11 Aug 2004 14:46:20 -0700 (PDT)

> interoperability it will be "later" or elsewhere.

Same here. 

>     occurred that is visible to them).

True, but the client now has to depend on the server's
idea of what a change means which may lead to
inconsistency when applied to dozens of feeds the
average aggregator user might see. 

To me this is not a big deal but I can imagine that
some consumers would rather not have to write the code
to keep track of such things themselves. I actually
don't in RSS Bandit but instead silently update old
content with new content without indicating any change
this to the user.

>     model to a separate effort.

Using dates as a versioning mechanism seemed like a
hack to me. I definitely oppose all efforts to
conflate the date issue with versioning. 

=====

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

---

From: Ken MacLeod <[email-masked]>
Date: 11 Aug 2004 16:54:25 -0500

Asbjørn Ulsberg <[email-masked]> writes:

> Seeing that there are several widely used publishing tools that
> doesn't support both of the atom:d and atom:e elements your pace is
> proposing, I don't think both atom:d and atom:e can be MUST.

According to BlogToolDateSurvey, every tool there is capable of
providing both atom:d and atom:e in a way that is conformant with the
proposed spec, validatable, and testable for interoperability.

If the publishing tool does not have a separate value for atom:d, the
value for atom:d can be the same value used for atom:e (in
PaceDateSamRuby, it would anyway).

> That's what I like about PaceDateAsbjornUlsberg and
> PaceDateAntoneRoundy.  They only require _one_ date, but they don't
> specify which one that should be, since current practice is so
> chaotic that it's impossible to require all tools to support one set
> of (shared) semantics now.
> 
> Instead, the specification should hash out the semantics we find
> useful, and hope that the tools will support and share these
> eventually.

I believe semantics without testable spec assertions to be less useful
to implementors.

Neither of PaceDateAsbjornUlsberg or PaceDateAntoneRoundy specify
interoperable behavior* -- why a producer would include such dates or
what consumers will do when they receive them.  Both of
PaceDateSamRuby and PaceDateKenMacLeod define their dates in the
context of what they do in Atom tools, not just what they "mean".

  -- Ken

* excepting some "don't change when you pass-thru" text.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 12 Aug 2004 00:08:37 +0200

On Wed, 11 Aug 2004 14:46:20 -0700 (PDT), Dare Obasanjo <[email-masked]>  
wrote:

> Using dates as a versioning mechanism seemed like a hack to me.
> I definitely oppose all efforts to conflate the date issue with
> versioning.

I second this. As I've written before: the 'updated' date is such a far  
stretch after a more professional publishing model that I feel that those  
who want it should stretch all the way, and not just pick the bits they  
find useful from such a model.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 12 Aug 2004 00:20:52 +0200

> proposed spec, validatable, and testable for interoperability.

The way I understand PaceDateKenMacLeod, atom:d conveys  
BlogToolDateSurvey's «Creation Date» and atom:e conveys «Changed Date».  
Unless atom:d also conveys «Display Date», neither Movable Type,  
WordPress, BigBlogTool, ExpressionEngine nor Blosxom conforms to your  
pace. If atom:d is both «Creation Date» and «Display Date», your pace  
should say so explicitly somehow.

> PaceDateSamRuby, it would anyway).

Which is one reason I don't like PaceDateSamRuby.

> I believe semantics without testable spec assertions to be less useful

Is it a requirement to be able to have testable spec assertions for  
something to go into the Atom specification? I have no problem with  
understanding the usuefulness of it, I just don't see how it can be a  
requirement.

> what consumers will do when they receive them.

Good point. I'll try to write something about that.

---

From: Antone Roundy <[email-masked]>
Date: Wed, 11 Aug 2004 17:24:32 -0600

> context of what they do in Atom tools, not just what they "mean".
Why should the behavior be specified or suggested?  Isn't that entirely 
up to the implementor or the user?  I don't think we really need to 
speak on the issue of sort order.  Sometimes people will sort by date, 
sometimes by another criteria.  When sorting by date, if we have more 
than one Date Construct, which to prefer for sorting is an individual 
preference.

As for suggesting that entries MAY not be displayed until a post-dated 
date is reached, I think that would be an appropriate use for 
dcterms:available.  Unless we explicitly bake that semantic into a core 
element, it's anybody's guess whether post-dated entries are intended 
by each publisher to be handled that way.

The single atom:d seems to carry some weak ("MAY") SUGGESTIONS for 
behavior, but doesn't appear to SPECIFY behavior.  And the MEANING of 
the date is not very specific.

The only behavior I can think of that might need to be suggested is 
that the "subjective" date might be thought of as a "display" date.  
But even that would be nothing more than a weak suggestion--some people 
may prefer to display one of the objective dates.

---

From: David Powell <[email-masked]>
Date: Thu, 12 Aug 2004 00:56:37 +0100

> Good point. I'll try to write something about that.

Arghh! - You've renumbered your definitions. That is going to make the
discussion very confusing - any chance of changing back to the old
numbering system and just missing out atom:c?

-- 
Dave

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 12 Aug 2004 02:17:37 +0200

> numbering system and just missing out atom:c?

Of course. Sorry for the confusion I may have caused. atom:c is now simply  
skipped in the pace, since I think (and hope) atom:b will be able to  
represent that date.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 11 Aug 2004 18:05:56 -0700

Seems like the right balance to me. It may be worthwhile to highlight 
that consumers can (and should) put the decision about what to do with 
dates into the arms of consumers; e.g., sorting, delayed display, etc.

I can imagine future extensions that give much more fine-grained 
control to feed authors, thus automagically configuring the display and 
use of dates, but it doesn't look like we're there yet.

--
Mark Nottingham     http://www.mnot.net/

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 11 Aug 2004 18:49:36 -0700

At 2:17 AM +0200 8/12/04, Asbjørn Ulsberg wrote:
>Of course. Sorry for the confusion I may have caused. atom:c is now 
>simply skipped in the pace, since I think (and hope) atom:b will be 
>able to represent that date.

Changing your proposal multiple times in one day does not help the 
discussion move. Could you instead simply add comments? At this 
point, the thread about your proposal is badly broken.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 12 Aug 2004 09:38:20 +0200

On Wed, 11 Aug 2004 18:05:56 -0700, Mark Nottingham <[email-masked]> wrote:

> I can imagine future extensions that give much more fine-grained control  
> to feed authors, thus automagically configuring the display and use of  
> dates, but it doesn't look like we're there yet.

Is it really imaginable that any tool vendor will stretch in any way to  
use the Dublin Core dates if they aren't encouraged to do so by the  
specification? Especially when the current practice obviously is  
considered to work «just fine».

---

From: David Powell <[email-masked]>
Date: Thu, 12 Aug 2004 10:20:19 +0100

> considered to work «just fine».

I agree.  If the 500+ permathread taught us anything, then I think it is obvious
that there is confusion about the meaning of dates and we need to be very clear
on how various date terms relate to Atom.

I am -1 on PaceDateSamRuby:

We need to be explicit on how to apply fine-graned date terms to Atom if they
are to have any shared semantics.  Yet, I don't believe that Atom should attempt
to (re)define how dcterms can be applied to entries.  dcterms isn't our
namespace, if we provide guidance for its use there is a danger that we may
bake a misinterpretation of it into the spec.

I think that it is best if we define an explicit set of dates in Atom so that we
can clearly specify how they should be applied.

Also neither Sam's atom:d or anything in dcterms allows for a subjective date,
which was one of the most popular dates in the date survey.

Sam's atom:d seems to be a catch-all date for the benefit of pre-Atom systems. 
We do need to make it easy for RSS users to move to Atom, but this is
effectively making a weakly specified legacy field a mandatory element of atom
feeds for now and forever more.

I am +1 on PaceDateAsbjornUlsberg:

Both PaceDateSamRuby and PaceDateAsbjornUlsberg require a single mandatory
date.

The difference is, PaceDateAsbjornUlsberg provides the metadata to enable the
publisher to say what that date means.  I'm far more comfortable with this than
saying:
"Here is atom:d, it might mean created, modified, or issued - I can't tell you
and you can't guess".

-- 
Dave

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 12 Aug 2004 11:44:56 +0100

Paul Hoffman / IMC wrote:

> discussion move. Could you instead simply add comments? At this point, 
> the thread about your proposal is badly broken.

Can I echo that sentiment, and also for thread headings that have +1 
in them - bad idea that. There are people responding to "* +1" 
postings with 0 and -1 sentiments. I for one can't make head nor 
tail of people's position or where consensus is leaning if anywhere. 
I would suggest starting over with more sensibly titled threads.

cheers
Bill

---

From: Ken MacLeod <[email-masked]>
Date: 12 Aug 2004 09:40:09 -0500

Asbjørn Ulsberg <[email-masked]> writes:

> understanding the usuefulness of it, I just don't see how it can be
> a requirement.

Yes, I do feel strongly that any feature in the core whose use is not
implemented by at least two implementations (depending on role:
publisher, reader, intermediary) should be struck from the spec.

That's the second half of "rough concensus, and running code".

The simplest way to check to see if a feature is implemented is to
have a checklist drawn from the spec's stated assertions or directly
derived from them, and then run through each implementation and see if
it adheres to the spec.  Just as importantly, you then have to pair-up
implementations to see if they are consistent with each other, in case
we missed something in the checklist.

This works both ways: by testing implementations against the spec we
are also testing the spec against the implementations.

  -- Ken

---

From: Eric Scheid <[email-masked]>
Date: Fri, 13 Aug 2004 00:57:52 +1000

On 12/8/04 7:20 PM, "David Powell" <[email-masked]> wrote:

> We need to be explicit on how to apply fine-grained date terms to Atom if they
> are to have any shared semantics.  Yet, I don't believe that Atom should
> attempt to (re)define how dcterms can be applied to entries.  dcterms isn't
> our namespace, if we provide guidance for its use there is a danger that we
> may bake a misinterpretation of it into the spec.
> 
> I think that it is best if we define an explicit set of dates in Atom so that
> we can clearly specify how they should be applied.
> 
+1

---

From: Graham <[email-masked]>
Date: Wed, 11 Aug 2004 17:20:42 -0500

> be supported and all the funky stuff should be done in

Because in the latter the DC dates aren't extensions. PaceDateSamRuby 
essentially introduces all of the DC dates into the core without 
bothering to properly define their usage because, in name[space] only, 
they're extensions. I don't want to deal with 12 ill-defined date 
fields.

Whereas a small number of core elements, with definitions properly 
defined as they relate to the processes of syndication, is totally 
manageable. And if people do stuff outside of the core, it's okay for 
me to ignore them.

PaceDateSamRuby exists purely because of the perceived difficulties 
we've had with the AtomPub process - it is not a good technical 
solution.

Graham

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 12 Aug 2004 10:09:48 -0700 (PDT)

> they're extensions. I don't want to deal with 12

Interesting. I assume you haven't read their spec
then. Looking at
http://web.resource.org/rss/1.0/modules/dcterms/ I
don't see how they are any worse defined than any of
the proposals on the Atom list. In fact, I have found
them less ambiguous and prone to misinterpretation
than the dates I saw proposed in the two other Paces I
read yesterday. 

> manageable. And if people do stuff outside of the

Fine, show me the proposal that hits this 80/20 point
yet is unambiguous and clear. Neither of the other 2
Paces struck me as being properly defined or
straightforward for producers or consumers to
understand. 

> we've had with the AtomPub process - it is not a

The elements in the dcterms namespace look like an
excellent technical solution to myriad arguments I've
seen on this list around dates. Please read the spec. 

=====

---

From: Ken MacLeod <[email-masked]>
Date: 12 Aug 2004 12:25:06 -0500

David Powell <[email-masked]> writes:

> I agree.  If the 500+ permathread taught us anything, then I think
> it is obvious that there is confusion about the meaning of dates and
> we need to be very clear on how various date terms relate to Atom.
> 
> We need to be explicit on how to apply fine-graned date terms to
> Atom if they are to have any shared semantics.  Yet, I don't believe
> that Atom should attempt to (re)define how dcterms can be applied to
> entries.  dcterms isn't our namespace, if we provide guidance for
> its use there is a danger that we may bake a misinterpretation of it
> into the spec.
> 
> I think that it is best if we define an explicit set of dates in
> Atom so that we can clearly specify how they should be applied.

Could you take your preferred date Pace and, assuming it is adopted
and properly implemented by clients, say what checks someone would
perform to test clients for conformance?

That's my biggest stumbling block, I'm not seeing how some of the
"fine grained" date proposals are supposed to be applied.

  -- Ken

---

From: Graham <[email-masked]>
Date: Thu, 12 Aug 2004 12:37:01 -0500

On 12 Aug 2004, at 12:09 pm, Dare Obasanjo wrote:

> Interesting. I assume you haven't read their spec then. Looking at 
> http://web.resource.org/rss/1.0/modules/dcterms/ I don't see how they 
> are any worse defined than any of the proposals on the Atom list. In 
> fact, I have found them less ambiguous and prone to misinterpretation 
> than the dates I saw proposed in the two other Paces I read yesterday.

You're right, I haven't looked at it in a while, but I remember it 
being thin. I don't see anything much about revisions to documents, 
which is the big thing that separates syndication from, say, email. The 
process those dates are built around isn't one where the document 
appears to change ever.

And the other thing, I can only guess at how publishers might use those 
dates and fields in their feeds - there's no way I could implement 
anything straight from the spec, which I could with some of the other 
proposals.

> straightforward for producers or consumers to

PaceEntryDates still looks good (though as I've said before, the 
wording about entries being issued again isn't quite right yet).

Graham

---

From: Graham <[email-masked]>
Date: Thu, 12 Aug 2004 12:45:21 -0500

> perform to test clients for conformance?

Surely you just use the program and see if it's displaying nonsense? 
You don't always need formal tests, do you?

Graham

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 12 Aug 2004 11:07:44 -0700 (PDT)

> process those dates are built around isn't one where

Again, I'd suggest rereading the spec. There are
several elements on revisions to documents such as
dcterms:isVersionOf, dcterms:replaces and
dcterms:isReplacedBy which are explicit mechanisms for
revisioning documents as opposed to the numerous hacks
proposed on this list for overloading the semantics of
dates. 

=====

__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 12 Aug 2004 11:11:28 -0700 (PDT)

> You don't always need formal tests, do you?

What does displaying nonsense mean? If someone sends
me a bug report saying a feed does X in Shrook while
RSS Bandit does Y how do we know which behavior is
correct? For example, in NetNewsWire if the pubDate is
changed in the feed the item's display date in the
application is changed while this is not the case in
RSS Bandit. Which behavior is correct and why? These
are the kinds of questions a spec is supposed to
answer. 

=====

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 12 Aug 2004 21:17:01 +0200

> the thread about your proposal is badly broken.

Not really, imho, since no one afaik have commented on the (big) changes  
I've made lately. Thus, I've reverted the page to the one that has been  
discussed, and rather created a new page that reflects my new view  
proposal. I hope this is okay. The new page is:

<url: http://intertwingly.net/wiki/pie/PaceDateAsbjornUlsberg2>

The difference between PaceDateAsbjornUlsberg and PaceDateAsbjornUlsberg2  
is that PaceDateAsbjornUlsberg2 don't have atom:c and that it contains  
text to say what publishers and consumers may do with the dates (not sure  
how useful this is, though).

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 12 Aug 2004 21:17:40 +0200

> I would suggest starting over with more sensibly titled threads.

I can only say +1 to that.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 12 Aug 2004 22:57:18 +0200

> perform to test clients for conformance?

How is it easier to test conformance with either PaceDateKenMacLeod or  
PaceDateSamRuby than the others?

> "fine grained" date proposals are supposed to be applied.

I'm not seeing how it is possible to test any date proposal at all. You  
can check the date's syntax, you can check if it's a future or present  
date, you can check if it has a local timezone and you can compare one  
date with the other (if there's multiple dates). Much more than that would  
be impossible regardless of what the specification says and the number of  
date elements we have, no?

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 12 Aug 2004 23:09:54 +0200

On Thu, 12 Aug 2004 11:11:28 -0700 (PDT), Dare Obasanjo <[email-masked]>  
wrote:

> For example, in NetNewsWire if the pubDate is changed in the feed the
> item's display date in the application is changed while this is not
> the case in RSS Bandit. Which behavior is correct and why? These
> are the kinds of questions a spec is supposed to answer.

Then please help us answer them. I can't see how either PaceDateKenMacLeod  
or PaceDateSamRuby specifies this any better than the other paces. They  
both state what the consumer MAY do with the date(s), but I can't see how  
that improves interoperability or consistency between clients. In  
PaceDateAsbjornUlsberg2, I've added some text covering this as well.

To improve consistency between clients, we need to say what the dates  
specifically should represent. Is it e.g. possible to agree on what date  
should be the «sort date»? I think not, since what the client sorts on  
most likely is modifyable by the user.

Is it possible to agree on what date should work as the «display date»?  
Perhaps. But won't the date available be displayed, no matter what that  
is? If a Pace with multiple dates is chosen, which dates have precedence  
over the others? Is the subjective date more preferrable as a display date  
than the date of formal issuance?

Questions like these needs to be answered. They are not answered in any  
date paces yet. As I don't use any common RSS aggregators, I'm not the  
right man to answer these questions. I really don't care what aggregators  
do with the dates. The can convert them to linux timestamp, add them all  
together and divide them by pi for all I care.

What I care about is what the publishers do with the dates, which is why I  
have used so many words in my pace(s) to explain how publishers should  
treat each date element. If there's still not enough text in my pace(s)  
about how publishers should treat the date elements, please let me know  
what's missing.

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 12 Aug 2004 14:32:01 -0700 (PDT)

> PaceDateAsbjornUlsberg2, I've added some text

There's only one date in PaceSamRuby. I don't see how
any ambiguity or interoperability issues can arrive
from misinterpreting a single date. The one ambiguity
from previous experience in RSS is resolved because it
is explicitly stated that the value of the date field
can change. 

> than the date of formal issuance?

It is silly for the spec to try to dictate which dates
clients should display to users or use for sorting.
You can spec it if you want, I'll ignore it in my
application and do what I think is best for my users
based on their feedback. 

By the way none of these problems exist if we just
adopt PaceSamRuby. 

> together and divide them by pi for all I care.

So why are you holding up consensus by ratholing on
these points then? 

> about how publishers should treat the date elements,

What is so wrong with using the existing and very
clearly defined dates in
http://purl.org/rss/1.0/modules/dcterms/ 

They cover the dates in the significant publishing
scenarios as well as define mechanisms for versioning
and superceding. 

=====

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 13 Aug 2004 00:48:46 +0200

On Thu, 12 Aug 2004 14:32:01 -0700 (PDT), Dare Obasanjo <[email-masked]>  
wrote:

> There's only one date in PaceSamRuby. I don't see how any ambiguity
> or interoperability issues can arrive from misinterpreting a single
> date.

The date in PaceSamRuby is ambiguous as specified. It is close to the  
definition of ambiguity. It can represent absolutely all dates it is  
possible to express in human language. It says that it «typically, will be  
associated with the creation or availability of the resource», but that's  
just typically. Nothing required there.

What does PaceSamRuby's atom:d mean to you? To me, it means absolutely  
nothing. Well, it represents a date. Nothing more.

> The one ambiguity from previous experience in RSS is resolved because
> it is explicitly stated that the value of the date field can change.

So the ambiguity of RSS' dc:date and pubDate is only because it isn't  
stated whether it should change or not? Yes, that's one ambiguous thing  
about those dates, but there are several other things that make them  
ambiguous. Even if pubDate says it's a date that «Indicates when the item  
was published», almost no one uses it as a published date.

pubDate and dc:date is used as «display date», «modified date», «creation  
date», «issued date» etc. And all of these can change whenever the author  
or tool feels like it. 'pubDate', 'dc:date' and PaceDateSamRuby's 'atom:d'  
conveys absolutely no semantical meaning. They're all as ambiguous as you  
can get them, and this is something we're supposed to add text for in the  
Atom specification? Are we really going to specify and encourage ambiguity?

> It is silly for the spec to try to dictate which dates clients should
> display to users or use for sorting.

I totally agree. That's why I don't see what PaceDateSamRuby or  
PaceDateKenMacLeod does differently in this regard than the other paces.

> You can spec it if you want, I'll ignore it in my application and
> do what I think is best for my users based on their feedback.

I don't want to specify it. I thought you wanted it to be specified.

> By the way none of these problems exist if we just adopt PaceSamRuby.

Why not? Becuase atom:d can be just about any date?

> So why are you holding up consensus by ratholing on these points then?

Because I care about what publishers do. Very much so.

> What is so wrong with using the existing and very clearly defined
> dates in http://purl.org/rss/1.0/modules/dcterms/

It's wrong because Atom would then just encourage all tools, both on  
publisher and consumer side, to continue the current practice where  
absolutely no semantic is shared between them. If PaceDateSamRuby or  
PaceDateKenMacLeod strongly encouraged people to use the DC dates instead  
of the atom:* date(s), I would be happier, but I still think these few  
dates are so important that they should go in the core.

Also, PaceDateSamRuby and PaceDateKenMacLeod don't explicitly specify a  
subjective date, which many people have expressed interest in. Or should  
atom:d be objective, subjective, created, issued, modified and display all  
at the same time?

---

From: Ken MacLeod <[email-masked]>
Date: 12 Aug 2004 18:13:08 -0500

Asbjørn Ulsberg <[email-masked]> writes:

> PaceDateKenMacLeod strongly encouraged people to use the DC dates
> instead of the atom:* date(s), I would be happier, but I still think
> these few dates are so important that they should go in the core.

The DC date element and the DC qualified date elements provide
semantics for informational dates.  I'm mostly concerned about
processing and spec text that describes that processing.  I'm fine
with adopting all of DC as "informational" elements, and I think
that's what Sam's reference to the dcterms module is proposing.

> Also, PaceDateSamRuby and PaceDateKenMacLeod don't explicitly
> specify a subjective date, which many people have expressed interest
> in. Or should atom:d be objective, subjective, created, issued,
> modified and display all at the same time?

PaceDateSamRuby and PaceDateKenMacLeod
   The "atom:d" element's content conveys a date associated with an
   event in the life cycle of the entry.

This does not suggest that atom:d is a "mechanical" date generated by
the system, it may be any date that the publishing system or user
selects as a date associated with an event in the life cycle of the
entry.

  -- Ken

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 12 Aug 2004 16:22:04 -0700 (PDT)

--- Asbjørn_Ulsberg <[email-masked]> wrote:
> clearly defined
> absolutely no semantic is shared between them. 

Huh ?!?

The semantics in dc:terms are extremely clear to me.
It seems you are claiming that if an extension exists
it won't be widely supported which completely flies in
the face of experience in the syndication world. 

If your application wants to express all sorts of fine
grained date information about an entry use the
dcterms:* elements which have a mechanism for
providing this. If enough feeds do this then client
support will appear. 

Heck lots of clients support a <dc:author> element
even though it isn't specced anywhere simply because
the need existed and people started using it. 

> If
> PaceDateSamRuby or  

You think some arbitrary subset of the dcterms:* dates
are important. I think some other arbitrary subset are
important. Everyone who's posted about dates has
seemed a different subset of these dates as important.

The proper compromise would be for atom to use the
superset of these dates which are those defined in
dcterms. 

To me the only question then is whether Atom
replicates all of the dcterms elements or recommends
that people use them instead and provide only the
lowest common denominator needed.

Either solution works for me. Picking some random
subset of these dates and moving them into the core is
the worst of both worlds. Now I have to mix and match
with dcterms if I want to use professional publishing
terms in my application but have to be careful not to
conflict with the random ones that exist in Atom.

> atom:d be objective, subjective, created, issued,

What is pubDate in RSS now? That is atom:d in
PaceDateSamRuby. Every blogging tool today that
supports a subjective date uses pubDate so I'm pretty
sure they can use atom:d for it as well. 

=====

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 13 Aug 2004 01:37:41 +0200

> that's what Sam's reference to the dcterms module is proposing.

I don't get that feeling from Sam's proposal. If that's the intent, it  
should be made much clearer.

> selects as a date associated with an event in the life cycle of the

Yes. But you do agree that this is very ambiguous, right? Is it possible  
to have any idea of what a publisher means with this date, without doing  
publishing system sniffing somehow?

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 13 Aug 2004 01:59:58 +0200

> the face of experience in the syndication world.

Then let me ask this simple question: isn't absolutely all Dublin Core  
dates available to RSS 1.0 and 2.0 today? If your answer to this question  
is «yes», then can you tell me why pubDate and dc:date is still used  
ambiguously?

If there was need for any publishing tools to use the Dublin Core dates,  
they would have done so already. But they haven't. Thus, current practice  
works just fine for all publishers. Why would anyone change current  
practice when delivering Atom content, if the Atom specification don't  
even try to encourage anyone to do so?

> providing this. If enough feeds do this then client

I'm not primarily a publisher. I at least don't speak as a publisher here,  
because what I do with Atom is nothing I want to bother the format with.  
If I want to use an 'http://asbjorn/' namespace for my elements, I'll do  
so.

I am, as a consumer, interested in mildly forcing publishers to share  
semantics. If or when publishers use the Dublin Core elements (in or  
outside of Atom's namespace), I can be pretty confident that the content  
of these elements mean the same across all feeds.

With Sam and Ken's proposals, however, the date we're left with means  
nothing. It caters for current practice, yes, but it doesn't improve  
anything, at least not for my part. Encouraging publishers to be more  
thoughtful in the dates they provide, and get them all to share common  
semantics, will improve the situation greatly.

> the need existed and people started using it.

Yes. And that's a great example of why the more fine-grained Dublin Core  
date elements _won't_ be used in Atom: They're not used in RSS.

> seemed a different subset of these dates as important.

According to the date survey, that's not the impression I get. We all  
share some kind of semantic in what dates we want, but we all want  
different things.

> superset of these dates which are those defined in

If those are explicitly defined in the Atom specification, I can go along  
with having these dates in the Dublin Core namespace.

> To me the only question then is whether Atom replicates
> all of the dcterms elements or recommends that people
> use them instead and provide only the lowest common
> denominator needed.

That's the problem: there _is_ no «lowest common denominator». The date  
proposed in Sam and Ken's proposal, is a collection of all dates  
imaginable.It's not common, it's not lowest and it's definately not a  
denominator. It's as wide, high and broad as you can get it.

> What is pubDate in RSS now? That is atom:d in PaceDateSamRuby.

Yes.

> Every blogging tool today that supports a subjective date uses
> pubDate so I'm pretty sure they can use atom:d for it as well.

Of course. But the problem is that they squeeze any objective date into it  
as well. Infact, they squeeze _all_ dates they have available in that  
element, no matter what dates that may be. «You have 'modified'? Use  
pubDate. You have 'created'? Use pubDate. You have 'issued'? Use pubDate.»

---

From: Eric Scheid <[email-masked]>
Date: Fri, 13 Aug 2004 10:12:57 +1000

> conflict with the random ones that exist in Atom.

"random"?

no one has suggested such a process at all.

please refrain from such straw man arguments.

e.

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 12 Aug 2004 17:44:38 -0700 (PDT)

> date elements _won't_ be used in Atom: They're not

This implies to me that no one wants this
functionality not that people won't use extensions for
stuff missing from the core spec. Again experience
with RSS has shown that people will create and use
extensions for stuff missing from the core that they
actually need. 

=====

__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 13 Aug 2004 02:50:11 +0200

On Thu, 12 Aug 2004 17:44:38 -0700 (PDT), Dare Obasanjo <[email-masked]>  
wrote:

> This implies to me that no one wants this functionality not that
> people won't use extensions for stuff missing from the core spec.
> Again experience with RSS has shown that people will create and use
> extensions for stuff missing from the core that they actually need.

So publishers rule all. They own the content, and content is king. How do  
we get the publishers to support dates that are useful to consumers  
without getting them into the specification? The publishers are already  
quite content with the one date element they have.

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 12 Aug 2004 17:41:20 -0700 (PDT)

> please refrain from such straw man arguments.

To anyone who looks at the dcterms namespace elements
and the subsets proposed in the various Paces what is
the connection that one could draw? To me they look
like a randomly chosen subset.  

=====

---

From: Eric Scheid <[email-masked]>
Date: Fri, 13 Aug 2004 11:15:38 +1000

> like a randomly chosen subset.

For someone advocating people should go read what they are talking about,
you don't seem to have read the reasonings provided for choosing those
subsets. Disappointing. [and apologies for snarkiness]

Admittedly, those reasonings are for why certain dates are selected, but
silent on why others were omitted. Let me correct that then:

<dcterms:created> -- selected
<dcterms:issued> -- selected
<dcterms:modified> -- selected

<dcterms:valid> -- is a date-range value, not a date value, which is not a
semantic we are pursuing under the rubric of "date construct"

<dcterms:available> -- is a date-range value, ditto as :valid

<dcterms:dateAccepted> -- though popular in academic publishing, isn't of
particular interest to most RSS/Atom publishers at this time (dare I say)

<dcterms:dateCopyrighted> -- we already have a <copyright> element in core,
and we've been careful to have that element not be machine readable, leaving
such to extensions.

<dcterms:dateSubmitted> -- ditto as for dateAccepted

When I take the time to read the reasonings it's not so random to me.

e.

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 12 Aug 2004 18:58:12 -0700 (PDT)

> semantic we are pursuing under the rubric of "date

This is optionally a range. I can imagine news sites
would get some use out of having such a date
construct. 

> <dcterms:available> -- is a date-range value, ditto

This is optionally a range. Also I've seen people talk
about dcterms:available in the discussions about dates
especially since this is more inline with informal
publishing on the web than dcterms:issued. 

=====

---

From: Eric Scheid <[email-masked]>
Date: Fri, 13 Aug 2004 12:08:56 +1000

> publishing on the web than dcterms:issued.

will you be supporting date ranges in your aggregator implementation, or
will you be borking/ignoring date ranges?

do you believe the atom spec should specify whether date ranges are
optional, or whether dcterms:available and dcterms:valid MUST be RFC 3339?

e.

---

From: David Powell <[email-masked]>
Date: Fri, 13 Aug 2004 12:45:29 +0100

> that's what Sam's reference to the dcterms module is proposing.

I would be ok with using DC to represent all "informational" dates (such as
dc:issued, dc:created, etc), but I think that some dates are expected to have
behaviours associated with them - and I'm not comfortable with specifying
behaviours for DC dates, which I believe are intended to be mostly
informational.

If atom agents would be expected to associate behaviours with certain dates then
I'd rather those dates be inlined and fully specified by Atom.  These two dates
have significant behaviours:

"date of minor modification" - if included could be used by indexers and
processors to not process entries that had not changed.  Like a Last-Modified
header for entries.

"date of significant update" - if included a client might alert the user to an
update in a mutable entry.

(Note I'm not necessary suggesting that "date of significant update" should be
included in atom - just that if it were it would have a significant behaviour)

Also I think that "display date" needs to be specified within Atom because it
isn't part of DC.

I probably ought to write this up as a Pace to avoid reintroducing ambiguous
date terms back into the discussion.

> selects as a date associated with an event in the life cycle of the

Well it does seem to exclude "display date" from the definition because
"display date" is a date associated with the content of the entry, not
necessarily with the publishing life-cycle.  Perhaps excluding it wasn't
intended though?  Sam?

-- 
Dave

---

From: Norman Walsh <[email-masked]>
Date: Fri, 13 Aug 2004 14:53:57 -0400

/ Graham <[email-masked]> was heard to say:
| On 12 Aug 2004, at 12:09 pm, Dare Obasanjo wrote:
|
|> Interesting. I assume you haven't read their spec then. Looking at
|> http://web.resource.org/rss/1.0/modules/dcterms/ I don't see how
|> they are any worse defined than any of the proposals on the Atom
|> list. In fact, I have found them less ambiguous and prone to
|> misinterpretation than the dates I saw proposed in the two other
|> Paces I read yesterday.
|
| You're right, I haven't looked at it in a while, but I remember it
| being thin. I don't see anything much about revisions to documents,
| which is the big thing that separates syndication from, say, email.
| The process those dates are built around isn't one where the document
| appears to change ever.

What Dare said earlier in this thread: "Using dates as a versioning
mechanism seemed like a hack to me. I definitely oppose all efforts to
conflate the date issue with versioning."

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | You can pretend to be serious; you
http://nwalsh.com/            | can't pretend to be witty.--Sacha Guitry

---

From: Ken MacLeod <[email-masked]>
Date: 13 Aug 2004 16:36:07 -0500

Norman Walsh <[email-masked]> writes:

> mechanism seemed like a hack to me. I definitely oppose all efforts
> to conflate the date issue with versioning."

Please [re]read http://imc.org/atom-syntax/mail-archive/msg08423.html

As far as I am aware no one is proposing using dates as a versioning
mechanism, only as, as one use case, a mechanism to allow versioning
to be added later as an extension without affecting Atom 1.0
processors.

  -- Ken

---

From: Dare Obasanjo <[email-masked]>
Date: Fri, 13 Aug 2004 15:00:46 -0700 (PDT)

--- Ken MacLeod <[email-masked]> wrote:
> Please [re]read
http://imc.org/atom-syntax/mail-archive/msg08423.html
> to be added later as an extension without affecting

Your mail implies that dates have something to do with
versioning. I posit they don't and conflating the two
is not a fruitful excercise. It seems you are not only
assuming that Atom will have a mechanism for
versioning entries in future but also what form this
will take. 

I have first hand experience from various technologies
that shows that assuming how a versioning model will
evolve is often a difficult task to get right. Just
ask the W3C XML Schema working group about xs:redefine 

=====

---

From: Robert Sayre <[email-masked]>
Date: Fri, 13 Aug 2004 20:18:35 -0400

> versioning entries in future but also what form this

I agree with Dare here.

Another possibility for a backwards-compatible versioning mechanism 
would be for atom:id to always point at the head revision (status quo). 
Versioning extensions would identify previous revisions with different 
URIs or point to a versioned resource.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Sat, 14 Aug 2004 14:52:17 +1000

> conflate the date issue with versioning."

Using dates for versioning is an 80/20 solution though.

Is it really versioning that we're modelling though? Is it instead freshness
that we are modelling, and isn't that what the market is really asking for
more than a method of tracking distinct instances of a changing resource.

If it is freshness of a changing resource which we are modelling, then using
modified/updated dates is no longer an 80/20 solution, it's a 100% solution.

e.

---

From: Ken MacLeod <[email-masked]>
Date: 14 Aug 2004 11:20:55 -0500

I've seen only one possible message in support of PaceDateKenMacLeod
(a date indicating last change of an entry) and several against, so
I'm moving to withdraw it.  However, I would like to resummarize the
use cases for the change date.  If anyone gets an, "oh, I didn't think
of that" positive reaction, then say so, otherwise there is no need to
reply.  Note the second use case has not been mentioned previously.

Use cases for atom:e:

  1) When compared to a stored value of atom:e from a previous read,
     indicates (by being "later") whether any additional processing
     needs to be performed (such as overwriting the stored
     representation of the entry or further processing to determine
     whether the entry should be passed on or displayed).

  2) If the same entry (same atom:id) is read from multiple sources
     (such as republishers) they may possibly differ, the value of
     atom:e indicates which is the latest.

  3) If the same entry (same atom:id) appears more than once in the
     same feed, the value of atom:e is one indicator that can be used
     to determine which to process (store, pass on, or
     display).  Another strong indicator would be xml:lang.

atom:e serves the same purpose as the HTTP header Last-Modified.  Best
practice would be for publishing systems to ensure that the
Last-Modified value of the entry on the server (any representation) is
the value represented in atom:e.

What happens in each case if atom:e is not adopted:

  1) Assuming the source is authoritive (the original source), each
     new read of an entry can be considered the "latest" and be
     overwritten.  Impact: minimal, unnecessary processing may occur.

  2) This behavior is undefined.  Impact: In the event that an entry
     differs between two or more sources (based on the time they
     retrieved the entry), there is then an equal or greater than 50%
     chance that silent data loss will occur.

  3) This behavior is undefined, particularly it is also not defined
     as invalid in Atom format-01.  Impact: Should this practice not
     be explicitly disallowed and a producer emits an entry more than
     once, there is then an equal to or greater than 50% chance that
     silent data loss will occur.  Empirically, the chances of silent
     data loss approaches certainty, as most publishers put "new"
     entries towards the beginning of feeds and most consumers process
     entries in feed order so that later entries would overwrite
     earlier ones.

  -- Ken

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 15 Aug 2004 02:53:48 +0200

On Fri, 13 Aug 2004 12:45:29 +0100, David Powell <[email-masked]>  
wrote:

> I'm not comfortable with specifying behaviours for DC dates, which I
> believe are intended to be mostly informational.

What's the use of these dates if no one is going to do anything with them,  
I wonder. I know I would like to do something with them, at least. Much  
more than I would ever want to do with any subjective date, at least.

> If atom agents would be expected to associate behaviours with certain  
> dates then I'd rather those dates be inlined and fully specified by
> Atom.

That would be my preference anyway. I thought it was a goal to have Atom  
reference as few specifications, and inline as much (foreign) text, as  
possible.

> Also I think that "display date" needs to be specified within Atom  
> because it isn't part of DC.

True. Even 'dc:date' isn't appropriate as a highly subjective display  
date, since it's defined as «A date associated with an event in the life  
cycle of the resource» and «Typically, Date will be associated with the  
creation or availability of the resource». Neither of those sentences  
imply subjective, user-specified, only-for-display dates.

But it's difficult to discuss these terms, as different people put  
different meanings in them all.

> necessarily with the publishing life-cycle.

I agree. A subjective, user-provided date is imho, obviously not a part of  
the life-cycle of a resource.

---

From: David Powell <[email-masked]>
Date: Sun, 15 Aug 2004 02:44:00 +0100

> more than I would ever want to do with any subjective date, at least.

I probably wasn't very clear about what I mean by behaviours.

I see Atom as a protocol for the transfer of metadata between agents.
Some fields in atom:entry are part of the protocol, and some are part
of the metadata/data. (The boundaries are a bit blurred though because
all protocol fields are also metadata.)

For example I'd class atom:id as part of the protocol - it is likely
that Atom will specify behaviours of how the Atom protocol interacts
with this field.

I'd class atom:title to be part of the metadata. Atom has done its job
if this field gets passed intact from the publisher to the client. The
client of course can process this field in any way it chooses, but it
is done outside of the Atom specification.

(Perhaps we should be clearer in general about what the boundaries of
Atom are, otherwise we are likely to over-specify user-agent behaviour
and make intermediaries and automated "Atom services" difficult to
implement within the specification.)

An example of this principle in action would be dcterms:available.
This field is used to describe when a document was/will be made
available, but I believe that this field (like all of dcterms) should
only be used as an informational field. Clients should not expect that
setting a dcterms:available element to be in the future should hide
that entry - if clients require future publishing then that would need
to be specified as an extension using it's own namespace.

(If I added <meta name="DCTERMS.available" content="2005-01-11" /> to
my website I wouldn't expect it to disappear).

> [...]
> Neither of those sentences

"Display date" is a bad name - I don't consider that date to be
"only-for-display". I'd probably want to sort on it. In fact people
might sort on absolutely any field. I think sort-order is out of scope
of the spec.

-- 
Dave

---

From: Eric Scheid <[email-masked]>
Date: Sun, 15 Aug 2004 14:32:57 +1000

On 15/8/04 11:44 AM, "David Powell" <[email-masked]> wrote:

> might sort on absolutely any field.

I sometimes sort by title for some feeds, and sometimes sort by category or
by author on others. I might want to sort on other fields, but that's about
all I get with my newsreader of choice.

> I think sort-order is out of scope of the spec.

+1

I've previously noted that while I consider <updated> as very important and
useful to me, I wouldn't be sorting on it. I'd let the updated entry fall
where it would normally sort, retaining context, and let my newsreader alert
me to it's updated-ness some other way (eg. bolding the title).

e.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 19 Aug 2004 13:23:46 +0200

> all protocol fields are also metadata.)

Okay, now I see what you mean.

> that Atom will specify behaviours of how the Atom protocol interacts

I agree.

> is done outside of the Atom specification.

There is another layer, though, where an atom:entry isn't metadata about  
another resource, but the first-class resource itself. Then, atom:title  
would be data, not metadata. The same goes for the other elements in  
atom:entry otherwise classified as «metadata».

Yes.

> to be specified as an extension using it's own namespace.

Yes, or just by using an internal model for it. What would be interesting  
about 'available' as a part of Atom, is the date that ends the range, e.g.  
the date that tells when the entry is going away. This is still just  
informational, but it's nice to know.

> my website I wouldn't expect it to disappear).

Heh. :)

> "only-for-display".

Yes, I agree. That's why I think the user-provided date should just be  
called «date», since it means different things to different people. What  
clients do with elements in Atom isn't that interesting, imho. As long as  
they remain clients (e.g. don't re-publish the data anywhere), they can do  
whatever they want with atom:date as well as atom:id.

> I'd probably want to sort on it.

...Or on whatever other available element in the entry. Why should we  
refuse someone to sort entries on atom:title, or even atom:content?

> In fact people might sort on absolutely any field. I think sort-order
> is out of scope of the spec.

I totally agree. I think going too far to specify what clients should do,  
if they indeed only are clients, is meaningless. We don't know what  
clients might want to do. Finding new uses for Atom is one of the virtues  
of such a new format, and we shouldn't restrict client behavior in the  
specification.

Publisher's behaviour, however, should be restricted and specifically  
defined as much as possible. The current practice where 'pubDate' can  
represent any date, be immutable and whatever, is a practice we should  
discourage. Sure, provide an element they can push this ambiguous data  
into, but provide elements that have a bit more specific semantic value  
and meaning as well.

---

From: Andreas Sewe <[email-masked]>
Date: Thu, 19 Aug 2004 20:52:23 +0200

> that Atom will specify behaviours of how the Atom protocol interacts

That's a distinction (between protocol and metadata) well worth to make.
Thanks for pointing it out.

Now in my opinion the dates from dcterms are all informational metadata
about the publishing process that produced a given entry. None of these
dates are essential for the protocol - perhaps with the sole exception
of dcterms:modified.

That's because the date of the last modification is useful for the user
agent itself - even if the user is never interested in it. Similarly the
date of the last major modification might be useful for the user agent,
too, to keep its local cache of entries up-to-date. So I consider both
atom:modified and atom:updated to be dates that are useful as part of
the protocol.

Now one might argue whether a (protocol) atom:modified is indeed the
same as a (metadata) dcterms:modified, or if the latter only refers to a
modification in terms of the given publishing process whereas the former
reflects all modification including the "low-level" ones like e.g.
changing the case of an xml:lang attribute's content.

At any rate, I would like to see only dates being part of the protocol
included in the Atom core. For nice-to-have metadata dates there is
always the option of extensions - even if this might result in some kind
of overlap between e.g. atom:modified and dcterms:modified.

Any further thoughts?

Regards,

Andreas Sewe

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 27 Aug 2004 19:39:48 +0200

I agree.

> dates are essential for the protocol - perhaps with the sole exception

They aren't essential to the format itself either, but they are indeed  
useful for a lot of purposes (and people). Since people are so resilient  
to have the Dublin Core dates in the format (specification), maybe we  
should put them in the protocol (specification) instead?

Some examples of how Dublin Core dates could be used in the protocol:

   - A future 'available' date could make the protocol implementation
     hide the entry until the assigned point in time arrives.

   - When someone creates an entry with POST, 'issued', 'created' and
     'modified' are set. ('created' could of course be set on the client
     in offline scenarios and such.)

   - When someone updates an existing entry with PUT, 'modified' is set.

> atom:modified and atom:updated to be dates that are useful as part of

'available' is certainly also useful, both for the server and client  
implementation. 'issued' and 'created' are useful in historical and  
archival scenarios.

> changing the case of an xml:lang attribute's content.

That's a meta-meta discussion. If people are less resilient to have the  
Dublin Core dates as a part of Atom (whatever namespace they may reside  
in) if they belong to the protocol and not to the format, I think it's a  
path worth exploring.

So far, everyone have thought it should be a part of the format, but since  
most of the DC dates are format publishing-specific dates, don't they fit  
better in the protocol specification?