Difference between revisions of "Discovery Change Proposal-6"

From Federation of Earth Science Information Partners
 
(3 intermediate revisions by the same user not shown)
Line 8: Line 8:
 
# '''Review period''': 2012-02-13/2012-03-13
 
# '''Review period''': 2012-02-13/2012-03-13
 
# '''Revision''': n/a
 
# '''Revision''': n/a
# '''Vote''': TBD
+
# '''Vote''': 4-1 in favor as of 2012-04-10
# '''Final review''': TBD
+
# '''Final review''': N/A
# '''Ratified''': TBD
+
# '''Ratified''': 2012-04-10
# '''Rejected''': TBD
 
 
* '''Facilitator''': [[User:Clynnes|Clynnes]]  
 
* '''Facilitator''': [[User:Clynnes|Clynnes]]  
  
Line 25: Line 24:
  
 
The proposed solution is to use the more standard Dublin Core [http://purl.org/dc/terms/date "date"] element to represent "a point or period of time associated with an event in the lifecycle of the resource.  Further, the dates are proposed to be encoded using the [http://www.w3.org/TR/NOTE-datetime W3CDTF profile of ISO 8601], as recommended by the Dublin Core.  An example of such a date is "1997-07-16T19:20:30.45Z".  Date/time intervals can also be expressed this way by separating the two date-times by a '/' character: "2007-03-01T13:00:00Z/2008-05-11T15:30:00Z".
 
The proposed solution is to use the more standard Dublin Core [http://purl.org/dc/terms/date "date"] element to represent "a point or period of time associated with an event in the lifecycle of the resource.  Further, the dates are proposed to be encoded using the [http://www.w3.org/TR/NOTE-datetime W3CDTF profile of ISO 8601], as recommended by the Dublin Core.  An example of such a date is "1997-07-16T19:20:30.45Z".  Date/time intervals can also be expressed this way by separating the two date-times by a '/' character: "2007-03-01T13:00:00Z/2008-05-11T15:30:00Z".
 +
 +
As this could cause some disruption to client/server interaction when adopted, I propose that this change be grouped with other DCPs in release 1.2 of the ESIP standard.
 +
 +
===Example===
 +
For an <entry> item that formerly displayed start and stop time as:
 +
<code>
 +
    <time:start>2009-01-01T05:23:24Z</time:start>
 +
    <time:end>2009-01-01T05:29:24Z</time:end>
 +
</code>
 +
the new form would be:
 +
<code>
 +
    <dc:date>2009-01-01T05:23:24Z/2009-01-01T05:29:24Z</dc:date>
 +
</code>
  
 
== Voting Result ==
 
== Voting Result ==
 
TBD
 
TBD

Latest revision as of 10:42, April 10, 2012

<< Back to the Discovery Change Proposals page


DCP-6: Adopt Dublin Core Date Specification in Atom Response

  • Progress (fill in the dates as the process moves forward)
  1. Submitted on: 2012-02-13
  2. Review period: 2012-02-13/2012-03-13
  3. Revision: n/a
  4. Vote: 4-1 in favor as of 2012-04-10
  5. Final review: N/A
  6. Ratified: 2012-04-10

Description

The DCP-1 specification repurposed the <time:start> and <time:end> elements from the draft specification in OpenSearch for querying on time. However, a more common standard for representing time in XML documents is available, namely the Dublin Core standard element "date" for represent a point in time or a time period. This is, not coincidentally, also the method for representing date-time within the draft specification of OpenSearch for the Open Geospatial Consortium (OGC).

Problem Addressed

The current ESIP Discovery specification uses a non-standard element for specifying date-time or date-time range. This is an unnecessary deviation from the "mass-market" standard proposed by OSGeo to OGC.

Proposed Solution

The proposed solution is to use the more standard Dublin Core "date" element to represent "a point or period of time associated with an event in the lifecycle of the resource. Further, the dates are proposed to be encoded using the W3CDTF profile of ISO 8601, as recommended by the Dublin Core. An example of such a date is "1997-07-16T19:20:30.45Z". Date/time intervals can also be expressed this way by separating the two date-times by a '/' character: "2007-03-01T13:00:00Z/2008-05-11T15:30:00Z".

As this could cause some disruption to client/server interaction when adopted, I propose that this change be grouped with other DCPs in release 1.2 of the ESIP standard.

Example

For an <entry> item that formerly displayed start and stop time as:

   <time:start>2009-01-01T05:23:24Z</time:start>
   <time:end>2009-01-01T05:29:24Z</time:end>

the new form would be:

   <dc:date>2009-01-01T05:23:24Z/2009-01-01T05:29:24Z</dc:date>

Voting Result

TBD