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

[Wilson, Brian D (335G)]

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