[glue-wg] New Endpoint and Service types

[stephen.burke at stfc.ac.uk]

Paul Millar [mailto:paul.millar at desy.de] said:
> Later on, I proposed:
> 
> 	http://www.ietf.org/rfc/rfc4918.txt
> 
> This is a precise definition of the additional semantics supported by
> the endpoint.
> 
> Would that be better?

No, worse! My objection is to the use of any URL as a selection parameter: because the text of a URL can vary while resolving to the same document, because a URL can change, and especially in a case like the above because it's hugely error prone (very easy to type say "rcf4981"). 
 
> > A URL is something which is basically a free-form
> > string aside from syntax constraints,
> 
> (Isn't that an oxymoron?  If there are syntax constraints then it isn't
> free-form ;-)

That's nitpicking. What we want here is a *single* defined string which means "webdav", not a wide and undefinable range of strings.

> I disagree.  Taking what you say at face value, we should remove all
> URIs as attribute types in the specification!

First, my point applies to selection parameters used in queries, which is only a subset of all attributes. A URL as information returned by a query is fine. Secondly, a URI is not necessarily a URL; it's entirely possible to have a defined format for a URI which leads to a unique string in a given case, although I agree that we haven't been very good about doing it in practice.

> > In any case, we already have an attribute to
> > publish additional subsidiary types, namely InterfaceExtension.
> 
> I'm perfectly happy if we publish WebDAV as an InterfaceExtension rather
> than a SupportedProfile.
> 
> GLUE-2 says nothing about how these should be used (it defines
> SupportedProfile as a profile and InterfaceExtension as an extension!)

I agree that these are not well-defined. At a fairly late stage in the schema process we had both primary and secondary interfaces defined as a URI which was supposed to be a formatted combination of a name and a version; it was me who argued to split the primary interface into separate Name and Version attributes. Here's part of Sergio's reply to a mail from me on 14/5/08:

-----------------

> And I don't
> understand why or how Type and Version are combined as a single
> Interface URI: at the very least this needs *much* more explanation
> since it's absolutely vital to using the endpoints! And the Type list
> needs to be enumerated (as it is now). Basically I don't understand why
> we haven't kept the Type and Version as we have them in 1.3. 

this emerged during the revision process with Balazs; one of the most 
wanted query pattern is: I want to search for an endpoint complying with 
an interface name an version, plus some extensions as well.

E.g.: ARC implements BES 1.0 + a number of extensions; how do you search 
for them?

Interface = urn:ogf:bes:1.0 and InterfaceExtension = urn:arc:bes++:1.0 
and InterfaceExtension = urn:ogf:hpc:1.0

the problem sits mainly in the extensions; by coupling the name and 
version into one attributes, we can maintain simple properties

----------------

And here's part of a reply from *you* the following day!

----------------

Could the documentation be updated to say that Interface should (must?) be a 
URN that encodes the type and version of the interface.  Leaving it 
as "Type=URI" is potentially confusing.

--------------

Unfortunately I don't think the documentation ever was updated or clarified, and in practice we've never used this up to now so it never came up. If we do want to treat webdav this way I think we need to define what the URI format is for InterfaceExtension. Basically we want a format with two variable parts: a protocol name which we should treat as an enumerated type like InterfaceName, and a version string which we should treat like InterfaceVersion.

Stephen

-- 
Scanned by iCritical.