Thread: Change to <Operator>/<Agency> element

I apologize... neglected to provide the pull request link:
https://github.com/FDSN/StationXML/pull/9

Best,
Dan

Dan Auerbach
Application Developer, Project IDA, Rm 2120
Institute of Geophysics & Planetary Physics, MS 0225
Scripps Institution of Oceanography, UC San Diego
La Jolla, CA 92093
858-822-0797



On Sep 29, 2015, at 9:08 AM, Dan Auerbach <dauerbach<at>ucsd.edu> wrote:

Hi,

I would like to throw out for review the idea of making a small
modification to station <Operator> element. I would like to propose that *no
more than one <Agency> element be permitted within <Operator>*.

The pull request:


Here are some use cases that prompt this proposal:

Case 1) Multiple Stations per Agency: It is certainly not uncommon for an
agency to function as an operator for more than one station. It is possible
that the contacts from that agency vary from station to station. It seems
ideal to have the <Operator> only contain those <Contact>s that are
relevant to the enclosing station, and not list all <Contact>s associated
with the agency involved. While the schema doesn’t enforce which <Contact>s
are included, I suggest the intention be made clear that only those
<Contact> related to the enclosing <Station> be included in the station
<Operator> element.

Case 2) Multiple Agency per Station: If two distinct Agencies, with
distinct contacts, are operators for a single Station, the schema suggests
that they should each be in their own <Operator> tag. Allowing multiple
Agencies within a single <Operator> seems to contradict this. In addition,
since the enclosed <Agency> and <Contact> tags are siblings, the children
of <Operator> could end up being an unstructured collection of multiple
<Agency>s and multiple <Contact>s (from multiple agencies). It get



The proposed change would have the following benefits:

1) Reinforce the intention that each distinct operator should be
encapsulated in its own <Operator> element. Allowing more than one <Agency>
seems counter to this intention.

2) The <Contact>s included within <Operator> would then be those contacts
associated with (single) sibling <Agency> element, as appropriate for the
enclosing <Station>. While there is no schema requirement that the <Agency>
within <Contact> match the <Agency> within <Operator>, I would suggest that
this be the preferred/expected behavior. (Making a requirement that the
<Operator> and <Contact> <Agency> tags match would involve more substantial
schema changes). Overall, this results in an <Operator> element with
children that are all related in an intuitive way.

3) By adopting this change, the internal structure of the <Operator>
element is in line with the natural relationship between <Agency> and
<Contact> metadata, facilitating the generation of StationXML from a
database managing the station metadata.


I am proposing this simple change to <Operator> in the interest of
minimizing change to the schema. However, there are certainly other, more
involved, approaches that would get to the same conceptual place. For
example, a new complex type of AgencyType could be constructed that would
encapsulate the Agency info (name, URL, etc), and zero or more <Contacts>.
Then <Operator> could be redefined as zero or more <Agency>s. I*f this is
preferred, I can make those changes and submit as a git pull request
instead of the simpler solution I am proposing currently.*


The *CURRENT* the relevant schema snippet here:

<xs:element name="Operator" minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>An operating agency and associated contact persons. If there multiple operators, each one should be encapsulated within an Operator tag. Since the Contact element is a generic type that represents any contact person, it also has its own optional Agency element.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="Agency" type="xs:string" maxOccurs="unbounded"/>
<xs:element name="Contact" type="fsx:PersonType" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="WebSite" type="xs:anyURI" minOccurs="0"/>
</xs:sequence>
</xs:complexType></xs:element>



The *PROPOSED* schema snippet with maxOccurs=“unbounded” removed from the
enclosed <Agency> element:
here:


<xs:element name="Operator" minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>An operating agency and associated contact persons. If
there multiple operators, each one should be encapsulated within an
Operator tag. Since the Contact element is a generic type that
represents any contact person, it also has its own optional Agency
element.
It is expected that typically the contact’s optional Agency tag will match the Operator Agency.
Only contacts appropriate for the enclosing Station should be include in the Operator tag.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="Agency" type="xs:string"/>
<xs:element name="Contact" type="fsx:PersonType" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="WebSite" type="xs:anyURI" minOccurs="0"/>
</xs:sequence>
</xs:complexType></xs:element>




I welcome any discussion or questions.


Cheers,
Dan


Dan Auerbach
Application Developer, Project IDA, Rm 2120
Institute of Geophysics & Planetary Physics, MS 0225
Scripps Institution of Oceanography, UC San Diego
La Jolla, CA 92093
858-822-0797






----------------------
FDSN Working Group II (
http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)

Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
Update subscription preferences at http://www.fdsn.org/account/profile/