Talk:Discovery Change Proposal-2
From Earth Science Information Partners (ESIP)
Combined with incubator DCP from Matt Cechini -- Clynnes 10:22, 17 June 2011 (MDT)
We grafted the description from Matt Cechini's incubator DCP on OPeNDAP link_type with this DCP.
However, the namespace remains in opendap.org. This is chosen as a namespace because it is more authoritative than ESIP, i.e., the keepers of the DAP standard.
From telecon discussion of handling alternate service/data links in granule-level Discovery responses -- Hook 15:12, 9 August 2011 (MDT)
- See Discovery Telecon 2011-08-09 for meeting minutes on discussion.
- To continue discussion here and vote on the preferred approach.
- Possible ideas so far:
- Original DCP-2 idea: rel attribute value of http://xml.opendap.org/ns/DAP/3.3#.
- "rel" could be dereferencible URI. but is fragile.
- Could leverage the fragment part of the URI
- Use space-delimitation in "rel" URI
- Define third attribute, with appropriate namespace.
- As long as using namespaced attribute, it does not break in the W3C Feed Validation Service.
Pros and Cons of proposal #2 for DCP-2 (dereferenceable URIs) -- Rozele 15:24, 9 August 2011 (MDT)
- Example: ... rel="http://esipfed.org/ns/discovery/1.1/resources#DAP_3.3" ...
- http://esipfed.org/ns/discovery/1.1/resources#DAP_3.3 should be valid URL
- Sample content:
<?xml version="1.0" encoding="utf-8"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:esip="http://esipfed.org/ns/discovery/1.1/schema#" xmlns="http://esipfed.org/ns/discovery/1.1/resources#"> <rdf:Description about="DAP_3.3"> <rdf:type about="http://esipfed.org/ns/discovery/1.1/data" /> <rdf:type about="http://esipfed.org/ns/discovery/1.1/schema#DAP" /> <esip:DAP_version>3.3</esip:DAP_version> </rdf:Description> </rdf:RDF>
- in the sample above...
- http://esipfed.org/ns/discovery/1.1/data represents the generic type
- http://esipfed.org/ns/discovery/1.1/schema#DAP represents the specific type
- http://esipfed.org/ns/discovery/1.1/schema#DAP_version represents the property that gives the DAP version
- in the sample above...
- Positives of dereferenceable URIs
- Keeps the specification simple in the sense that only two attributes are used (rel and type)
- Capable of extended semantics (extensible beyond the current use cases)
- Negatives of dereferenceable URIs
- We will need a specification (rather, vocabulary) for the content at the URI
- Complicates feed readers by requiring (potentially many) dereferences of URIs
- Breaks feed elements when host of URI is down
Pros and Cons of proposal #1 for DCP-2 ("http://xml.opendap.org/ns/DAP/3.3#" value for "rel" attribute) -- Clynnes 15:45, 9 August 2011 (MDT)
- Pros
- Simple and unambiguous
- Instantaneously interpretable (no dereferencing needed)
- Cons
- Overloads "general-purpose" rel attribute with specific purpose
- Example:
<link rel="http://xml.opendap.org/ns/DAP/3.3#" href="http://disc2.nascom.nasa.gov/opendap/TRMM_3Hourly_3B42/2011/001/3B42.110101.12.6A.HDF.Z"/>
Pros and Cons of Proposal #3 (add DAP indicator as URI fragment) -- Clynnes 15:54, 9 August 2011 (MDT) -- Clynnes 15:54, 9 August 2011 (MDT)
- Description:
Keep the ESIP data indicator, but add the DAP identifier after "#" as a URL fragment. Note that slash '/' is allowed according to the RFC, but old browsers may gag on it.
- Example:
<link rel="http://esipfed.org/ns/discovery/1.1/data#DAP/3.3" href="http://disc2.nascom.nasa.gov/opendap/TRMM_3Hourly_3B42/2011/001/3B42.110101.12.6A.HDF.Z"/>
- Pros
- Simple and unambiguous
- Instantaneously interpretable
- Allows both general purpose (before hash) and specific purpose to coexist
- Cons
- Not exactly what fragment was intended for, i.e, return a piece of the full URI