propsective changes branch

[Chad Berkley]

Hi Peter,

I'm just trying to understand your proposal.  See what you think of my
second example below, or if my first example is what you had in mind.

So would the instance document look like this:
<distribution>
  <online>
    <url
function="connectin">sde://mohave.asu.edu:5150?instance=ces_sde&catalog=USGSDRG</url>
    <url
function="information">http://server.com/sdeinformation.html</url>
  </online>
</distribution>

where sedinformation.html contains the human readable parameter
information?  

If this is the case, why not have something like this:

<distribution>
  <online>
    <url
function="connection"sde://mohave.asu.edu:5150?instance=ces_sde&catalog=USGSDRG</url>
    <connectionNotes>
      sde://host[:port]?[instance=]&[catalog=]
 
      host = the dsn name or ip address of the SDE service host computer
 	port= the communication port the service listens to ( if missing,
        this is asusmed to be 5150)
      instance = the name of the service. to use this name it must be
        mapped to a tcp/ip port number in your 	services file.
      catalog= name of the database or catalog to connect to (this is not
        supported by all services. If missing, the service will connect to the
        default catalog).
    </connectionNotes>
</distribution>

I thought that was the reason we added the connectionNotes element in the 
Sevilleta meeting. I have no problem with a human readable description of the 
connection information where it is needed.

chad

> Im suggesting that for url structures that are either obscure or totally
> made up, a pointer to its explnation would make it more useable by more
> people. There IS no structured format for an sde connection -
> alternately...there are MANY structure formats for others depending on what
> software driver you might use. It all this discussion, none of you have
> provided me with an example of a url string for SDE or a url string for an
> sql database that doesnt require a user to parse the string, extract the
> individual bits of information and pass them to the particular software they
> intend to use. If we are going to force ourselves to use a single url
> structure that isnt defined in eml, they we're going to have to accept that
> the contents of that string are going to be non-standard. my sugession of a
> second url was merely a way to provide indivuduals outside my own immediate
> peer group the informatin needed to parse the particular string i make up.
> for example, the following string is probably pretty opaque to you:
> 
> sde://mohave.asu.edu:5150?instance=ces_sde&catalog=USGSDRG
> but if i give you a page that contains the following then anyone familiar
> with sde would know how to parse that string and open a connection to sde
> using any of a variety of tools that can do it - arcGIS, mapObjects,
> arcExplorer, arcIMS, etc:
> 
> sde://host[:port]?[instance=]&[catalog=]
> 
> where host = the dsn name or ip address of the SDE service host computer
> 	port= the communication port the service listens to ( if missing,
> this is asusmed to be 5150)
> 	instance = the name of the service. to use this name it must be
> mapped to a tcp/ip port number in your 	services file.
> 	catalog= name of the database or catalog to connect to (this is not
> supported by all services. If 	missing, the service will connect to the
> default catalog).	
> 
> The only way you can use my string is 1) correctly guess what the parameters
> are 2) call me or 3) read the above file if ive made it available and
> pointed to it in my instance file. I supposed that in principle, there must
> be a standard format for expressing url syntax like this that is machine
> parsable, but i dont see what that gets you - in the absence of any
> universal semantic standard for the parameter names, you're simply going to
> have to read the page to understand that what im calling "catalog" is what
> arcExplorer is prompting you for as "database"
> 
> ESRI added an element called SDE_connection to their profile of FGDC = its a
> compound element with host,port,userid*,password*. Because the structure is
> defined in the metadata standard, everyone knows exactly what the terms
> mean. But you all dont want to make this information part of EML.
> 
> 
> > It would be helpful to me if you could provide a sample 
> > markup for, say,
> > an SDE connection.
> > 
> > Thanks,
> > chad
> > 
> > 
> > 
> > On Tue, 2002-08-27 at 11:45, Peter McCartney wrote:
> > > Ok, ive checked in a working set of modules under the
> > > EML_PROSPECTIVE_CHANGES_082602 branch. These files show:
> > > 
> > > 1) my proposed change to distribution to allow one to 
> > provide a url string
> > > that represents a connection rather than a discreet resource object,
> > > identify the url as such with the function attribute, and 
> > provide a url that
> > > points to online documentation for a custom schema (eg 
> > sde://hostname:port ?
> > > instance=&database= )
> > > 
> > > 2) my proposed changes to address the LTER IM complaints about
> > > protocol/project: these involved defining a new module 
> > called eml-methods
> > > which includes elements for quality control, sampling 
> > description and
> > > methodStep(s). MethodSteps includes pointers to related 
> > sofware, datsets,
> > > and instruments and a description which any combination of text,
> > > eml-protocol, or eml-citation.
> > > 
> > > methods is imported optionally into dataset, entityBase and 
> > attribute and
> > > any previous links to protocol is removed. 
> > > 
> > > This solution leaves eml-protocol to be used only for 
> > generic protocols that
> > > we wish to publish as resources. There is still a flaw here 
> > in that protocol
> > > also defines a methodStep elment that differs from the one 
> > in method. so the
> > > name should be changed or perhaps protocol should just 
> > import eml-method so
> > > that all it does is add the resourceBase elements.
> > > 
> > > And Matt..thanks for the tip on winmerge...it was just what 
> > i was looking
> > > for.
> > > 
> > > Peter McCartney (peter.mccartney at asu.edu)
> > > Center for Environmental Studies
> > > Arizona State University
> > > 480-965-6791 
> > > 
> > -- 
> > -----------------------
> > Chad Berkley
> > National Center for 
> > Ecological Analysis 
> > and Synthesis (NCEAS)
> > berkley at nceas.ucsb.edu
> > -----------------------
> > 
-- 
-----------------------
Chad Berkley
National Center for 
Ecological Analysis 
and Synthesis (NCEAS)
berkley at nceas.ucsb.edu
-----------------------