connection definition issue

[Peter McCartney]

Im afraid my patience with bugzilla has been exhaused for today, so im now
emailing the information i twice wrote  and lost there.

Ive no desire to have similar experiences trying to figure out how to do
branches in cvs, so ive attached two files showing a suggested solution to
the connection information issue i entered in buzilla. DistributionType has
been edited as follows:

- reusability is enabled
- "connection" is added to the function type enumeration to notify an
application that the url describes connections accordig to some schema.
- inline is added from the distribution element in eml-physical
- the choice element is made non repeating as the distribution element
itself repeats.
- eml-physical imports the DistributionType  complex type from resource.

With no change to the way conventional urls are handled, this structure
allows one to enter one or more connnection definitions and then reference
them for all the objects that are available via that connection.

This does not really address the first of the two issues i identify in this
bug. after lots of review of email discussion threads all over the internet,
ive reached the conclusion that we probably dont want to clutter EML with
hacks, but we have to be realistic about there simpley not being universally
standard schemas for expressing urls to connections outside of a few
commonly used formats that are bound to specific software drivers - eg
"jdbc://jdbc:tdsDriver:mohave.asu.edu:1433?database=arthropods". There are
attempts, but no universal solutions, for presenting the lower level
connection information that could used to create a url for any give driver.
Nevertheless, for the few that we use, any of us could easily define a
simple string that does the job
(mssql://mohave.asu.edu:1433?version=7.0&networkprotocol=tcpip&database=arth
ropods). The best compromise seems to be to accept that not everything we
might express in a "url" is going to have a well established schema or a
processor that can deal with it without some custom programming to parse it.


One further thing to consider, is that we include an attribute that provides
a url (yes, i realize the circularity of this!) that provides an explanation
of the URL syntax - ideally in  machine readable form, but most likely in
text form for now. for my second example i might put:

schema: mssql
syntax: mssql://host[:port] ? version [& networkprotocol] [& instance] [&
database] 

parameters:

	version 	version identifier of server software
	instance 	instance name of service
	database 	name of database to connect to
	networkprotocol 	protocol on which server listens ( tcpip |
namedpipes | banyan | appleshare )

Even if someone else defines a different syntax for the same service, this
would at least provide a publicly available explanation of it, just not
included in EML.

Thinking beyond this, im not sure what would be the best way to extend this
solution so that it also works to point to WSDL descriptions documented in a
UDDI type registry, but we should probably ensure that it is so we dont have
to revise it in 2.1.



Peter McCartney (peter.mccartney at asu.edu)
Center for Environmental Studies
Arizona State University
480-965-6791 

 <<eml-resource.xsd>>  <<eml-physical.xsd>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20020822/30dc1acf/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eml-resource.xsd
Type: application/octet-stream
Size: 36794 bytes
Desc: not available
Url : http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20020822/30dc1acf/eml-resource.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eml-physical.xsd
Type: application/octet-stream
Size: 48276 bytes
Desc: not available
Url : http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20020822/30dc1acf/eml-physical.obj