Hi Paul, On 2014-04-04 14:58, Paul Millar wrote:
Hi Florido,
On 25/03/14 12:00, Florido Paganelli wrote:
After reading all the discussion with Stephen, I am convinced of one thing: [..]
Capability is better; however, the OGSA definitions are (currently) higher-level functionality; they don't (currently) specify which protocol the endpoint supports.
Additional definitions could be added but I'm not sure this is the correct approach.
This is the only correct approach, despite what OGSA definitions are. If Capabilities are open enumerations, we're free to set another route, and create specific ones for protocol. [...] I vote for creating better Capabilities.
Sounds good to me.
My I suggest we have a standard way of mapping an OGF and RFC specification to a Capability? This could be a URL or a URN.
We have two ways: EITHER we just insert the URN in the description, OR we want a machine to be able to parse it and hence we add an additional field in the Capability_t.csv. I think it would be reasonable to add a specific field for better machine-readability.
That way, publishing the correct Capabilities becomes straight-forward and no further registration is needed.
true indeed. But we still have to agree on names. I am thinking of something like (omitting some fields for readability): Capability_t | Description |...| Reference documentation ======================================================================================================================= data.transfer.http | capacity of moving a file from one network location |...| https://tools.ietf.org/html/rfc6585 | | to another using the HTTP protocol |...| | ------------------------------------------------------------------------------------------------------------------------ data.transfer.https | capacity of moving a file from one network location |...| https://tools.ietf.org/html/rfc2660 | | to another using the HTTPS protocol |...| | ----------------------------------------------------------------------------------------------------------------------- data.transfer.webdav | .... Also, agreeing on which RFC is crucial in my opinion. Cheers, Florido -- ================================================== Florido Paganelli ARC Middleware Developer - NorduGrid Collaboration System Administrator Lund University Department of Physics Division of Particle Physics BOX118 221 00 Lund Office Location: Fysikum, Hus B, Rum B313 Office Tel: 046-2220272 Email: florido.paganelli@REMOVE_THIShep.lu.se Homepage: http://www.hep.lu.se/staff/paganelli ==================================================