[Esip-discovery] Concerning use of 'rel' attributes, in service casting and more generally

Thu Jul 28 09:16:25 EDT 2011

Brian,
  I agree that DCP-2 is not without disadvantages.  But at the same time, it is simple and we have applications stalled because we have no way to recognize an OPeNDAP link.  It's hard for me to tell from your message if you are proposing an alternative to move us forward.    
  One disadvantage I am not concerned with is the namespace pollution, as I think the number of well-known protocols that are in common use in our community (OPeNDAP, WMS, WCS, w10n, with versions) is still in the single digits.
  So here's what I am going to do:  Firstly, I will modify the DCP-2 proposal to clarify that it is meant to apply to URLs representing specific data files/objects served through OPeNDAP (e.g., http://airspar1u.ecs.nasa.gov/opendap/Aqua_AIRS_Level2/AIRX2RET.005//2011/205/AIRS.2011.07.24.091.L2.RetStd.v5.2.2.0.G11206115718.hdf), not the service endpoint of an OPeNDAP server (e.g., http://airspar1u.ecs.nasa.gov/opendap/). These usually have different meanings and treatments within an OPeNDAP server in any case.  This way, it will not conflict with the scast use of rel (where we would advertise http://airspar1u.ecs.nasa.gov/opendap/).
  Also, I will extend the voting period to the end of August, so that you (or someone else) can propose a viable alternative for people to evaluate DCP-2 against.  People that have already voted (including myself) are free to change their vote until then.  WHat I will be looking for in any alternative is usability and adoptability by application clients.

On Jul 27, 2011, at 9:32 PM, Wilson, Brian D (335G) wrote:

> 
> Quoting Sky Bristol:
>> For instance, I might want to include a URI that points to something more specific that tells an application that the link is >specifically to an OGC-WMS version 1.1.1 instead of the generic scast:serviceEndpoint. I might also want to include a link to >the ISO19137 XML rendering of an item's metadata so that an application could go get that view of the item if needed.
> 
> All,
> 
> We need to be careful how many purposes we try to stuff into the 'rel' attribute on <link rel=''> tags.
> 
> In service casting I intended to use it at a semantic level.  The 'rel' is serviceInterface, serviceEndpoint,
> or documentation.  For W3C standard <link> tags there is a 'type' attribute which contains the MIME
> type of the application server you are pointing at.  Also, in scasts, there is also a <scast:serviceSemantics>
> tag for each service entry.  So for an OGC-WMS entry, we have:
> 
> <scast:serviceSemantics>OGC.WMS</scast:serviceSemantics>
> <link rel='scast:serviceEndpoint' type='application/vnd.ogc.wms_xml' href='...' />
> 
> So a machine script can process this information and know that it's a WMS server in two ways.
> 
> If machine clients need to know the version of the WMS server to construct a proper REST call
> (which actually is true sometimes for OGC services), then we could change the one tag
> value to "OGC.WMS.<version>", or something like it.
> 
> However, I do recognize the *feature* of having all the needed information inside the standalone
> <link> tag.  I just don't think we can cover all the purposes -- semantic, syntax, & protocol version
> -- inside the single 'rel' attribute.
> 
> For the same reason, I think adding the OpenDAP 'purpose' to the 'rel' attributes (change proposal
> DCP-2) is not quite correct.
> 
> Currently, all of the generic rel values are just that, generic;  viz. data, service, metadata, browse, etc.
> And now suddenly a versioned DAP protocol is there.
> 
> OpenDAP, OGC/WMS, etc. are kinds of services.  So to my mind, we need two levels of information:
> first this link is pointing to a service, and then what kind of service with version.
> 
> We might introduce a new attribute, subrel, standing for sub-purpose, and put the versioned DAP
> and OGC/WXS URI's in the subrel attribute.  This proposal doesn't scale if we ever need three
> levels of hierarchy.
> 
> Alternatively, the W3C spec. for <link rel=''/> actually says that the value of the 'rel' attribute can
> be a "space separated list of link relationships".
> 
> So we might try:
> <link rel="<discover_service_URI> <WMS_v1.1.1_URI>" />
> 
> I think W3C intended this to express alternatives rather than a purpose and a sub-purpose, but
> we are already well beyond what is codified at IANA.
> 
> Putting space-separated URI's in the rel attribute will scale to any number of information items.
> However, the code to interpret rel attributes will now have to make many assumptions, or simply
> scan for 'known' URI's.  It could become a mess.
> 
> I think we need to ponder a more complete solution here that is as simple as possible, but still
> captures 'semantics' using generic purposes (like data, service, etc.) and 'syntax/protocol' using
> more specific purposes (like the versioned DAP URI). 
> 
> -- Brian
> 
> 
> _______________________________________________
> Esip-discovery mailing list
> Esip-discovery at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-discovery

--
Dr. Christopher Lynnes     NASA/GSFC, Code 610.2    phone: 301-614-5185