Re: [ogsa-wg] OGSA/OGF URI for non-bound or non-functional EPRs

In ther OGSA Data Architecture document we suggest that URI's are needed to name transport protocols, access interfaces, and query languages. I would be surprised if this list were exhaustive. ByteIO, of course, have made a start on naming SOAP transport protocols (SwA, MTOM and DIME). Dave. -----Original Message----- From: ogsa-wg-bounces@ogf.org [mailto:ogsa-wg-bounces@ogf.org] On Behalf Of Andre Merzky Sent: 30 August 2007 12:01 To: Michel Drescher Cc: OGSA-DMI ML; OGSA-WG Subject: Re: [ogsa-wg] OGSA/OGF URI for non-bound or non-functional EPRs Hi Michel, Quoting [Michel Drescher] (Aug 30 2007):
Folks,
- apologies for cross-posting -
[...]
Also, while we were discussing this matter on the last DMI call, we came up with the idea whether it is feasible to pull together a couple
of interested people and create an OGF Community Practice document that may be based on GFD.84: "Standardised Namespaces for XML infosets in OGF" (http://www.ogf.org/documents/GFD.84.pdf) and defines, at an OGF level, standardized URIs for things such as - non-bound EPRs (as discussed) - Data transport protocol identifies (GridFTP, HTTP, FTP, SRB, RFT, ...) - ...
Any ideas or comments?
The SAGA groups would happily consume such a document - at the moment, we leave all these specification to either the implementors or (worse) to the end users, and are not satisfied with that solution. Cheers, Andre.
Cheers, Michel -- "XML is like violence: if it does not help, use more."
-- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg

Dave Berry wrote:
In ther OGSA Data Architecture document we suggest that URI's are needed to name transport protocols, access interfaces, and query languages. I would be surprised if this list were exhaustive.
ByteIO, of course, have made a start on naming SOAP transport protocols (SwA, MTOM and DIME).
There's a whole zoo of such things. One of my favourites (only suitable for small files though) is the data: url type (RFC 2397) which puts the information directly inline in the message. OK, it's very inefficient, but it shows how there are many different ways to approach the problem. Trawling the RFCs for other URL "protocols" may be worthwhile. Donal.
participants (2)
-
Dave Berry
-
Donal K. Fellows