I'm torn; on the one hand, dcterms is already defined, and already used in other feed formats; on the other hand, the syntax is less- than-simple.

So, I'm neutral on this.


On 08/10/2005, at 7:37 AM, James M Snell wrote:



Ok all, after looking this over in detail, I personally still have a preference for the age:expires and age:max-age elements in the feed-expires spec. Of course, this is likely due more to the fact that I wrote the draft as opposed to a sound, objective and technical perspective. So I want to open it up to a poll.
Here are the options.

I wanted to indicate that a given entry must expire at Midnight on Dec, 12, 2005 (GMT).
using age:expires:

  <entry>
    ...
    <age:expires>2005-12-12T00:00:00Z</age:expires>
  </entry>

  Advantage:
* The value of the expires element uses the Atom date construct making it ALWAYS compatible with other Atom dates
  Disadvantage:
    * New namespace, new element

using dcterms:valid (http://web.resource.org/rss/1.0/modules/ dcterms/#valid)

 <entry>
   <dcterms:valid>end:2005-12-12T00:00:00Z</dcterms:valid>
 </entry>

 Advantage:
   * Existing namespace, known element
 Disadvantage:
* Value can be many different things. I've even seen cases in which the content of dcterms:valid is an XML structure. My chief problem with dcterms:valid (and with dublin core in general) is that the elements are very loosely defined. The content can literally be anything folks want it to be and still be considered valid. Unless we constrain the value space for this element when used in Atom, it *could* lead to a bunch of extra work for consumers to parse and process those dates. I prefer very crisply defined elements. Then again, reusing an existing namespace is Goodness.

So what do y'all think?

- James

Mark Nottingham wrote:



FWIW, the Media RSS extension cites http://web.resource.org/rss/ 1.0/ modules/dcterms/#valid] as a best practice.


On 29/09/2005, at 4:45 PM, James Holderness wrote:




Just a follow-up on the representation of Date Ranges in dublin core. I was under the mistaken impression that you needed to use a DCMI Period encoding to represent a date range, but apparently ISO 8601 time intervals are perfectly valid. In order to clarify the situation, the DC Date Working Group has recently recommended the following replacement for the comment associated with the date element:

"Typically, Date will be associated with the creation or availability of the resource. A date value may be a single date or a date range. Date values may express temporal information at any level of granularity (including time). Recommended best practice for encoding the date value is to supply an unambiguous representation of the single date or date range using a widely- recognized syntax (e.g., YYYY-MM-DD for a single date; YYYY-MM-DD/ YYYY-MM-DD for a date range; YYYY-MM-DDTHH:MM to specify a single date and time down to the minute)."

Full details of the recommendation can be found here:
http://dublincore.org/usage/meetings/2005/09/madrid/files/ 2005-07-29.date-comment.txt

Personally I think that makes the idea of using dublin core for this extension a whole lot more palatable.







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










--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems



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

Reply via email to