Subject: dc:dates in atom - some questions

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

For those proposing we use the various dc:dates in atom, please answer some
questions:

[1] Will the atom spec be providing text which describes what format the
dates will be in (eg. RFC 3339), and any other limitations or subset
definitions?

[2] Will this be valid in an atom feed:
    <dcterms:modified>1999-12-24</dcterms:modified>
and if so, how will the various aggregator developers handle it?

[3] With dc:modified, will we be providing any clarification text, since
dc:modified is described with reference to terms of RSS. Will some
publishers translate RSS terms to Atom terms, or will some say "that's
specific to RSS, Atom is different, so I'm ignoring that bit of spec text"?

    http://web.resource.org/rss/1.0/modules/dcterms/#modified

[4] With dc:modified, note that it says "It is recomended that the Modified
date should correspond to the  HTTP 1.1 Last-Modified date, of the document
the <link> element points to when Modified is used within a <item> element".
If translating to Atom, is this the <link> element which points to the
@rel="alternate" resource, or the resource which the entry is "about" (eg.
when pointing at an external resource, the original model for RSS)?

[5] Should I be using dcterms:available or dcterms:issued, and which ones
will Shrook, RSS Bandit, NNW etc support or ignore? If the market by
practice decides on dcterms:issued (and mostly ignores dcterms:available,
thus resulting in aggregator clients ignoring same), should I stick my value
for dcterms:available in dcterms:issued just so I can provide useful
functionality to my consumers?

    http://web.resource.org/rss/1.0/modules/dcterms/#issued
    http://web.resource.org/rss/1.0/modules/dcterms/#available

[5] Does everyone realise that, apart from the issue of dcterms allowing
partial dates (eg. "2004-08"), some of the dc dates are not W3CDTF values at
all, but are instead date *ranges*? For example, did you read the previous
question thinking dcterms:available would be a date value, and not something
like this:
    <dcterms:available>
      name=OO Perl / mod_perl programmer for Web CMS;
      start=2002-7-5;
      end=2002-8-5;
      scheme=W3C-DTF
    </dcterms:available>

[6] Look closely at that last date construct ... will we be supporting the
"scheme" sub-element, or mandating in the Atom spec that all dates must be
in RFC 3339 format? [and will the anti-micro-parser crowd please chime in
now too?]

e.

---

From: Antone Roundy <[email-masked]>
Date: Thu, 12 Aug 2004 19:23:35 -0600

> dates will be in (eg. RFC 3339), and any other limitations or subset
At least some of these proposals, if not all, say that they SHOULD be 
in the more restricted format, but don't REQUIRE it.

> [5] Should I be using dcterms:available or dcterms:issued
I thought the difference between the two was pretty clear: available = 
the date range during which the publisher wishes the entry to be 
presented to the user. issued = when the entry was actually published.  
Use the one that means what you want to say.

> If the market by
If you want people to see your entry beginning at some particular time, 
and available isn't widely supported, then wait till that time to 
publish it rather than fudging the value of issued--that'd be my 
preference.

---

From: grayrest <[email-masked]>
Date: Thu, 12 Aug 2004 22:11:30 -0400

> dates will be in (eg. RFC 3339), and any other limitations or subset

This is specified in my pace. It may not be explicit but the intent is
to have any date formatting in the dc:dates extension mechanism use
the exact same formatting as the rest of the dates. I doubt that I'm
going to find a useful dc:dates parsing library in (e.g.) javascript,
so I'd have to re-implement this myself and it's just easier if there
is one and only one format to the dates.

> and if so, how will the various aggregator developers handle it?

No. Times and timezones must be specified.

> specific to RSS, Atom is different, so I'm ignoring that bit of spec text"?

I believe the 80% use case is explicitly defined in my proposal,
dcdates is only provided as a recommended extension mechanism so that
tool wishing to extend the api do so in the same direction. If a
particular item becomes a de facto standard, then it should be
officially amended to the next version of the Atom syntax to become de
jure.

> [4] With dc:modified, note that it says "It is recomended that the Modified..."

Specified, not an issue.

> will Shrook, RSS Bandit, NNW etc support or ignore? 

I hope that atom:a is the obvious target for developers to display and
that other common consumer wants are covered without having to choose
which to show and which to ignore. It is expected that all conforming
consumers be able to handle at least three (a,b,d) and preferably c as
well. If I'm missing a common use case, please propose an amendment.

> all, but are instead date *ranges*? 

I do not believe these fall into common usage, hence their status as
preferreed extensions.

> in RFC 3339 format? [and will the anti-micro-parser crowd please chime in

I'm pro-micro-parser, if you haven't gathered. Parsers I write won't
support any extensions unless market pressures force me into it.

---

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

> dates will be in (eg. RFC 3339), and any other limitations or subset

I would like that, at least.

> [2] Will this be valid in an atom feed: <dcterms:modified>1999-12-24
> </dcterms:modified> and if so, how will the various aggregator developers
> handle it?

I don't know how aggregators will handle it, but that should be an allowed  
(though not preferred) date. I think we should encourage publishers do be  
as exact as possible in this regard, especially seeing that most of the DC  
dates should be provided (automatically) by tools.

> dc:modified is described with reference to terms of RSS.

What do you mean with «since dc:modified is described with reference to  
terms of RSS»? In the DCMI document, 'modified' is described as «Date on  
which the resource was changed.»:

<url: http://dublincore.org/documents/dcmi-terms/#modified>

> Will some publishers translate RSS terms to Atom terms, or will some
> say "that's specific to RSS, Atom is different, so I'm ignoring that
> bit of spec text"?

Since Atom actually has a history (it effectively inherits RSS' history),  
we need to write something about it in the specification. If RSS' history  
and practice is unsuited for Atom, that needs to be mentioned. If RSS'  
history and practice is what we want in and from Atom, that needs to be  
mentioned as well.

> @rel="alternate" resource, or the resource which the entry is "about"  
> (eg. when pointing at an external resource, the original model for
> RSS)?

Wouldn't those be the same in most cases? Or am I misunderstanding  
something here?

> thus resulting in aggregator clients ignoring same), should I stick my  
> value for dcterms:available in dcterms:issued just so I can provide  
> useful

I don't know for sure. I'd guess that 'issued' would have the same value  
as the start-range of 'available' in most cases. What aggregators would do  
about this is uncertain, though. It would be nice to have some input from  
the DC people on what the practical difference between the start-range  
value of 'available' and 'issued' is.

> partial dates (eg. "2004-08"), some of the dc dates are not W3CDTF  
> values at all, but are instead date *ranges*?

Since all Dublin Core dates are built on ISO 8601, I would assume the date  
ranges would still be proper ISO 8601 dates, only separated by a slash:

2004-08-14T00:00:00/2004-08-15T02:40:00

<url:  
http://www.mcs.vuw.ac.nz/technical/software/SGML/doc/iso8601/ISO8601.html>

> [6] Look closely at that last date construct ... will we be supporting  
> the "scheme" sub-element, or mandating in the Atom spec that all dates  
> must be in RFC 3339 format? [and will the anti-micro-parser crowd please  
> chime in
> now too?]

I would like the scheme to be as strict as possible. That is, to encourage  
(but probably not enforce) as exact dates as possible. Ranges should be  
allowed though, which leaves W3CDTF and RFC 3339 out in uncertainty.

Would it be too much to just write our own note on dates as a (non-)  
normative appendix, though? In that one, we could basically just copy  
W3CDTF, allow for the '-00:00' time zone designator from RFC 3339, and  
also date ranges as defined in ISO 8601.

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

---

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

> publish it rather than fudging the value of issued--that'd be my  

That would imho be the recommended practice nonetheless. Future dates just  
doesn't make much sense, especially if what the publisher wants is the  
entry not to appear until the specified date and time arrives.

---

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

> entry not to appear until the specified date and time arrives.

Use case: a conference is announced. it is of course occurring sometime in
the future, no point announcing it otherwise. The announcement would be
dated today(), but they make available a new feed for important information
regarding the conference. One of those entries is a note about one of the
speakers, who has deigned to make their slides available but only during the
period the conference is on.

The entry might look something like this:

<entry>
    <issued>2004-08-15T14:22+10:00</issued>
    <author><name>Joe Bob</name></author>
    <title>Joe Bob's slides</title>
    <dcterms:available>
      name=The Big Conference;
      start=2002-09-05;
      end=2002-09-07;
      scheme=W3C-DTF
    </dcterms:available>
    <link rel="alternate" type="application/powerpoint"
        href="URL-of-the-slides" />
</entry>

Does that make sense? This way people know the slides will be available, and
available for only a short window of time, and they can make plans to access
and retrieve that resource. The conference organiser will also be alleviated
of the endless emails that ask "when will the slides be available?".

e.

---

From: "Bill Kearney" <[email-masked]>
Date: Sun, 15 Aug 2004 11:14:26 -0400

> entry not to appear until the specified date and time arrives.

Or use a format better suited for it.  At the present time NewML, with all of
its syntactic complexities, is probably a better choice.

If and it's a BIG IF, the market evolves such that considerable consumer demand
exists for such things there's always room for further evolution of the
standard(s) involved.

-Bill Kearney
Syndic8

---

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

On Sun, 15 Aug 2004 11:14:26 -0400, Bill Kearney <[email-masked]>  
wrote:

>> That would imho be the recommended practice nonetheless. Future dates  
>> just doesn't make much sense, especially if what the publisher wants
>> is the entry not to appear until the specified date and time arrives.
>
> Or use a format better suited for it.  At the present time NewML, with  
> all of its syntactic complexities, is probably a better choice.

Yes, probably. NewsML is, however, extremely complex. Atom is simple.

> If and it's a BIG IF, the market evolves such that considerable consumer  
> demand exists for such things there's always room for further evolution
> of the standard(s) involved.

Indeed. I think, however, that for now, future dates should be  
discouraged. It's the publisher's, not the consumer's job, to hide the  
entry from the readers until the date and time it's supposed to be  
visible, arrives.