Bug #568
closedaccomodation of stateful connection information.
0%
Description
This issue has two distinct, but often confused parts.
1) is it adequate to rely on an external convention (URL) to provide the
standardization needed to unambiguously describe online access to data? points
on both sides of the debate are extensibility of EML and rendundancy with
established standards, the extent to which those external bodies do in fact
provide expressons of all online access protocols in common use by the
community, and are we all conversant enough with that standard to use it
efficiently.
2) should EML support descriptions of online connections that do not return a
data object but instead enable opening of a stateful connection over which a
proprietary communication protocol operates.
EML beta 9 supports online access in two forms: a download url which, when
passed to a url processor that recognized the mode, will result in a data
object, and an information url that is expected to point to a document of
unknown format with further instructions on how to get the data.
Files
Updated by Peter McCartney over 21 years ago
Ive reviewed the edits Matt made to distribution in response to fridays
discussion on distribution. It struck me that there was alot of complexity
that might be a result of prior edits, so Ive made an attempt an a much simpler
version that i think does the same thing. in short, ive dropped
connectionNotes as it seems redundant with the connection description, in
connectionDefinition, Ive dropped the reference option within the entire
distribution element as it was only the connectionDefinition that we wanted to
make reuseable, Ive dropped connection Definition as a direct choice as it is a
required element under connection.
so the way you use this is you may fill in a conection element under dataset
and supply a connectionDefinition with defaults for some of the parameters.
for each eml-physical, you can supply a connection element and either provide
or reference an existing connectionDefinition. Unless im missing some further
functionality, this seems to do everything we wanted with fewer choices.
Updated by Peter McCartney over 21 years ago
Im happy with the connection/connectionDef solution, especially if it can be
simplified as ive suggested here. Im reassigning this to matt so he can close
it out when he's merged the changes.
Updated by Matt Jones over 21 years ago
FIXED. Changes checked into CVS. Although this solution using a "connection"
element is more powerful than a plain URL, it is a far cry from being able to
describe arbitrary application protocols, even things as simple as CGI scripts
over HTTP. So, at some later point in time (after the 2.0.0 release), we may
want to consider how to be more comprehensive about this solution, probably by
adopting WSDL or a similar technology for connection descriptions.
Updated by Peter McCartney over 21 years ago
I still think there is some gratuitous complexity here regarding references
i dont see why we would want to enable references for connections in eml-
physical - these should be unique.
I also dont see why we have a sequence containing a choice under
conenctionDefinition. this looks like an error from a prior structure.
Updated by Matt Jones over 21 years ago
Discussed during conference call 10/1/2002. Agreed the current structure will
work, and allows processors to distinguish between the connection and connectionDef.
Only chnage needed is to get rid of the superfluous choice nested in a sequence.
Updated by Matt Jones over 21 years ago
Done. Extraneous sequence has been removed from both the eml-resource and
eml-physical modules. FIXED.