EML

Completed subitems 1, 2, 3, 4, 5, 7, 8, 9, and 11. Regarding pubDate (4), the
XML Schema datatypes spec does not allow truncation of any date type, so the
"xs:date" type must be a full calendar date, and the "xs:gYear" must be a 4
digit year and can not contain a month or day. Therefore, I have changed the
type of the "pubDate" field to be "xs:string", and specified inthe docs that the
date should follow ISO 8601 format. We may want to consider creating a derived
type that is either a gYear or a xs:date value.

Changes to coverage (6) are waiting on required changes to the eml-coverage
module.

That leaves items (6-coverage) and (10-distribution) remaining.

Item (6) is finished now that coverage has been updated in eml-coverage.

Item (10): Distribution:
I have created a content model that I think satisfies the spirit of our
Sevilleta discussions in full, but is more compact than the exact content model
that we discussed there. However, I still have problems with using the named
parameter list as it currently stands in the module. Right now, the model is:

<!ELEMENT distribution ((connection|offlineMedium)+)>
<!ELEMENT connection (onlineURL|parameter+)>
<!ATTLIST connection name CDATA #IMPLIED
scheme CDATA #IMPLIED>
<!ELEMENT onlineURL (#PCDATA)>
<!ELEMENT parameter (#PCDATA)>
<!ATTLIST parameter name CDATA #IMPLIED>

This means someone can submit either a url or a list of named parameters for a
connection. However, the latter does not have well defined semantics, and so it
is impossible to actually construct a connection using this information without
a human interpreting the connection information. For example, if I give you the
following named parameter list for the scheme "database", precisely how do you
connect?
hostid=5
machinemap=7
network=tcp/ip
machinename=rover
machinedomain=somewhere.com
protocol=http
location=perm

My point is, the semantics of the parameter list are specific to the scheme, and
URLs provide a standard way of encoding those semantics. If users create EML
for a common http URL as a param list, we will effectively be eliminating the
possibility of machine-processable connections.

An alternative is to provide a token substitution mechanism in the URLs. For
example, if the user can define a token delimiter (e.g., "@"), then a url might
be encoded as:

http://host.org:9087/webapps/cgi/getdata?id=@identifier@&username=jones

In which case a single parameter needs to be provided to make the connection.
Trying to go beyond a simple URL encoding like this gets us into the realm of
re-inventing SOAP/WSDL or other service description systems. I really don't
think we should go there.

Sooo...I propose that we either 1) eliminate the parameter list entirely
(preferred), or 2) augment the URLs with a token substitution mechanism.

Changes completed and in CVS.

Original Bugzilla ID was 480