EML

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

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 <access>, 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 <distribution> elements: the first in its resource group, and the second as a child of <implementation>.
1. The first is untouched, obviously.
2. the second (implementation/distribution) could be retyped to the new PhysicalDistributionType. This makes the <access> 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.

changing status to "fixed"

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.

schema bugs targeted for 2.1.0 set to P1

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.

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:
<xs:complexType name="DistributionType">
<xs:choice>
<xs:choice>
<xs:element name="online" type="OnlineType"/>
<xs:element name="offline" type="OfflineType"/>
<xs:element name="inline" type="InlineType"/>
</xs:choice>
<xs:group ref="ReferencesGroup"/>
</xs:choice>
<xs:attribute name="id" type="IDType" use="optional"/>
<xs:attribute name="system" type="SystemType" use="optional"/>
<xs:attribute name="scope" type="ScopeType" use="optional" default="document"/>
</xs:complexType>

in eml-physical.xsd
<xs:complexType name="PhysicalDistributionType">
<xs:sequence>
<xs:choice>
<xs:choice>
<xs:element name="online" type="PhysicalOnlineType"/>
<xs:element name="offline" type="res:OfflineType"/>
<xs:element name="inline" type="res:InlineType"/>
</xs:choice>
<xs:group ref="res:ReferencesGroup"/>
</xs:choice>
<xs:element name="access" type="acc:AccessType" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="id" type="res:IDType" use="optional"/>
<xs:attribute name="system" type="res:SystemType" use="optional"/>
<xs:attribute name="scope" type="res:ScopeType" use="optional" default="document"/>
</xs:complexType>

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

Original Bugzilla ID was 3480