Difference between revisions of "Discovery Telecon 2012-02-14"

Latest revision as of 11:56, July 22, 2012

<< Back to the Discovery Telecons page

Tuesday, February 14, 2011. 4:00pm ET / 1:00pm PT
WebEx Info:
- Call-in toll-free number (US/Canada): 1-877-668-4493
- Attendee access code: 231 407 50
- To start the online portion of the Personal Conference meeting , go to https://esipfed.webex.com/mw0306ld/mywebex/default.do?siteurl=esipfed&service=1 and select the Discovery Cluster meeting.

Attendees

Action Items

Agenda

Recap of Winter Meeting (if needed)
Status of new DCPs
- DCP-4: Use of xlink attributes in Atom <link> tags
- DCP-5: Use of OpenSearch <Query> tags for valid parameter values
- DCP-6: Replace overloaded time:start and time:end tags with dc:date
- DCP-7: define error handling best practices

Notes

Recap of Winter Meeting (if needed)

DCP-4: Use of xlink attributes in Atom <link> tags

Current Version: DCP-4: OPeNDAP Links in the Atom <link/> element

DCP-5: Use of OpenSearch <Query> tags for valid parameter values

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

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

@@ Line 8: / Line 8: @@
 == Attendees ==
-* Chris Lynnes
-* Hook Hua
-* Brian Wilson
-* James Gallagher
-* Erin Robinson
-* Ken Keiser
-* Li
-* Nga Chung
-* Pedro Goncalves
-* Christine White
-* Chris Mattmann
-* Eric Rozell
-* Call-in User_5
 == Action Items ==
@@ Line 38: / Line 25: @@
 === DCP-4: Use of xlink attributes in Atom <link> tags ===
-* Current Version: [[DCP-4|DCP-4: OPeNDAP Links in the Atom <link/> element]]
+Current Version: [[DCP-4|DCP-4: OPeNDAP Links in the Atom <link/> element]]
-* Potentially use "role" and "arcrole" from xlink to capture all the semantics of DCP-3.
-* Should we change DCP-4 to the current OPeNDAP suggestion, or should there be a separate DCP for the more general case of DCP-4?
-* Brian suggests a separate DCP for the general case (e.g., using "arcrole"), this will be coming in DCP-5
-** Basically, covering the case where service casts refer to collections, or collection casts referring to services
-* Returning a collection cast is a different use case from returning OPeNDAP response
-* Pedro suggests you don't need to use something like arcrole, IANA has registered mime types and rels that should cover everything
-* Summary -> DCP-4 will use xlink role, DCP-5 will use xlink role and arcrole
 === DCP-5: Use of OpenSearch <Query> tags for valid parameter values ===
-* Likely renamed to DCP-8
-* Li is interested in this, will be in contact with Ruth Duerr and Discovery mailing list for further information
 === DCP-6: Adopt Dublin Core Date Specification in Atom Response ===
-* Current version:  [[Discovey_Change_Proposal-6|DCP-6: Adopt Dublin Core Date Specification in Atom Response]]
+Current version:  [[Discovey_Change_Proposal-6|DCP-6: Adopt Dublin Core Date Specification in Atom Response]]
-* More aligned with OGC use of OpenSearch
-* dc:date refers to "point or period of time for an event associated with a resource"
-* should we use the convention that the parameter and XML element should match?
-* dc:date is more standard than the OpenSearch parameters
-* time:start and time:end were only standardized as "queryable"
-* which does ESRI prefer or suggest based on client development?
-** ESRI would align more with the dc approach (since there is already a dc:date XML element)
-** Not a big deal either way, but prefer things that may become standardized
-* another option (considered by OGC) is using gml, but this is more complex
-* Brian seeking connection between parameters and response elements in OSDD; however, OSDD does not support this
-** Only potential mechanism is "rel" and "type"
-* Eric also suggests using the "rel" list capabilities of OpenSearch to tell clients of this "convention"
-* The response may not actually echo all the values for search parameters
-* Another avenue is to use the Query tag is someway
-* Could use the <atom:Content> tags to put whatever data you want
 === DCP-7: define error handling best practices ===