duplicate distribution types (in resource.xsd, and physical.xsd)

[mbjones]

---

Author Name: Margaret O'Brien (Margaret O'Brien) Original Redmine Issue: 3480, https://projects.ecoinformatics.org/ecoinfo/issues/3480 Original Date: 2008-08-29 Original Assignee: Matt Jones

---

In examining : there are currently 2 Distribution Types, which are identical:

1. eml-physical.xsd:

used by: eml-physical.xsd:1169: <xs:element name="distribution" type="PhysicalDistributionType"

and

2. eml-resource.xsd:

used in these schemas: eml-resource.xsd:364: eml-software.xsd:129: (this one is a child of )

I cant tell why this is the case. What was the rationale for having 2?

Also note that bug #1154 only mentions one of these, PhysicalDistributionType

[mbjones]

---

Original Redmine Comment Author Name: Margaret O'Brien (Margaret O'Brien) Original Date: 2008-08-29T19:37:11Z

---

adding David's comments from email<<<<<<<<<

I am trying to remeber the rational for having distribution in two places. I think that we did that expecting that lots of people would not use eml-Physical, so it made sense to have it in resource. The distribution information in Resource was intended, I think, for human consumption while the element in eml-physical was meant primarily for software agents.

I am not making a case for two versions, but rather trying to remember the rational. I don't trust my memory so I could be wrong, but my explanation, at least, seems logical. David Blankman

[mbjones]

---

Original Redmine Comment Author Name: Margaret O'Brien (Margaret O'Brien) Original Date: 2008-08-29T22:14:10Z

---

Summarizing comments on eml-dev: The distribution element in the resource group is generally intended to be informational, although sometimes it has been used for download. The distribution element in the entity group is generally intended to be machine readable, and used for download.

looking closely at the 2 named Types and their uses, this is what I think should happen:

First, in eml-resource.xsd:

1. keep named type, DistributionType in the resource group.
2. make the element offline/mediumName required, per bug #1154
3. make sure that the documentation on the res:distribution element reflects the recommended or allowed uses, especially wrt the use of function="download" or "information".

Second: in eml-physical.xsd

1. derive a second type PhysicalDistributionType from res:DistributionType. Currently, it is a copy of res:DistributionType (with some additional documentation), and gets some of it's simpleTypes from the eml-resource schema.
2. The derived Type can have additional elements (like , see bug #1132 for code)
3. update the documentation on the physical/distribution element to reflect the recommended use

And third: eml-software.xsd: this schema actually has two elements: the first in its resource group, and the second as a child of .

1. The first is untouched, obviously.
2. the second (implementation/distribution) could be retyped to the new PhysicalDistributionType. This makes the tree available to implementation
3. clarify the appinfo on the implementation/distribution, since currently, this is a duplicate of the resource tag.

I tried to make schema language reset the default attribute value for the extended Type so that a particular use could be reflected in the model (ie, function="information" or function="download". Maybe this is not necessary, or maybe someone else has done this and can advise? As is, the default of "download" implies the most stringent content, but can be relaxed if authors need to.

[mbjones]

---

Original Redmine Comment Author Name: Margaret O'Brien (Margaret O'Brien) Original Date: 2008-09-22T17:10:20Z

---

changing status to "fixed"

[mbjones]

---

Original Redmine Comment Author Name: Margaret O'Brien (Margaret O'Brien) Original Date: 2008-09-23T21:46:40Z

---

reopened, since the desirability of specifying different defaults to the function attributes of these types was not established. ie, res:DistributionType has function="information" and phys:PhysicalDistributionType gets function="download"

Basically, derivation is based on either restriction or extension. So if we wanted to assign different default values for function in these 2 types, then we would need a 3rd type with no default value, which becomes the base type for both, which are then allowed to set their own defaults by restriction.

[mbjones]

---

Original Redmine Comment Author Name: Margaret O'Brien (Margaret O'Brien) Original Date: 2008-10-01T23:26:08Z

---

schema bugs targeted for 2.1.0 set to P1

[mbjones]

---

Original Redmine Comment Author Name: Margaret O'Brien (Margaret O'Brien) Original Date: 2008-10-23T21:01:41Z

---

These 2 types were not identical: res:distributionType included a choice of connectionDefinition independent of the one allowed under connection. physicalDistributionType did not allow this choice (all connectionDefinitions are children of connection) See text from cvs log at the bottom of this note. So the current fix will not work.

Revision 1.62 / (download) - [select for diffs], Thu Sep 12 00:30:00 2002 UTC (6 years, 1 month ago) by jones Branch: MAIN Changes since 1.61: +28 -16 lines Diff to previous 1.61 (colored)

Modified DistributionType in resource and physical to accomodate McCartney's changes to simplify connections. His changes were made, except that the reference was retained in connection so they can be re-used, and the connectionDefinition can still be used in eml-resource independently of a connection so that users can define connections outside of an actual connection. In eml-physical, this is not possible. A new ComplexType was created to accomplish this called PhysicalDistributionType.

[mbjones]

---

Original Redmine Comment Author Name: Margaret O'Brien (Margaret O'Brien) Original Date: 2008-11-04T23:05:15Z

---

In eml201, these two types were slightly different, with the similar chunks of code copied from one to the other. Extending the res:DistributionType (comment #2) wont do the job. Here is another option that makes components reusable, but each keeps each type distinct and their differences can be explained in the documentation.

1. define some additional types in resourcs.xsd: res:OfflineType, res:OnlineType (which are analogous to the existing, res:InlineType). res:ConnectionType (contains the already-defined ConnectionDefinitionTYpe, plus some optional overrides) res:OnlineType, phys:PhysicalOnlineType 2 online Types are required because in the resource group, it needs be be allowed to have a child connectionDefintion (see comment #6, r1.62)

2. build res:DistributionType and phys:PhysicalDistributionType from these, plus acc:AccessType. See below. This way, the basic use of each Type can be put into the annotation under it's complexType description, and the intended use at the resource or physical level can go into the instance elements.

in eml-resource.xsd:

in eml-physical.xsd

[mbjones]

---

Original Redmine Comment Author Name: Margaret O'Brien (Margaret O'Brien) Original Date: 2008-11-06T18:16:06Z

---

done, except for documentation of phys:PhysicalDistributionType, which is now in bug #3599

[mbjones]

---

Original Redmine Comment Author Name: Redmine Admin (Redmine Admin) Original Date: 2013-03-27T21:23:34Z

---

Original Bugzilla ID was 3480