International Federation of Digital Seismograph Networks

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

None
Started: Sept. 29, 2015, 9:08 a.m.
Last activity: Sept. 29, 2015, 1:45 p.m.
Dan Auerbach
Sept. 29, 2015, 9:08 a.m.
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. If 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




  • Dan Auerbach
    Sept. 29, 2015, 9:11 a.m.
    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. If 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





    • Philip Crotwell
      Sept. 29, 2015, 1:45 p.m.
      This seems reasonable to me.
      Philip

      On Tue, Sep 29, 2015 at 12:14 PM, Dan Auerbach <dauerbach<at>ucsd.edu> wrote:

      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/