Thread: New ws-station revision released

Started: 2011-06-21 23:29:08
Last activity: 2011-06-23 20:37:33
Topics: Web Services
Yazan Suleiman
2011-06-21 23:29:08
Hello webservice users,

The DMC has updated it's ws-station service: http://www.iris.edu/ws/station/

For users parsing the StationXML returned by ws-station be aware that <NumberChannels> has been changed to <TotalNumberChannels>. New elements have been introduced:

TotalNumberStations
SelectedNumberStations
TotalNumberChannels
SelectedNumberChannels


We have also fixed bugs related to virtual network result sets and timewindow for channel epochs.

For users of the DMC's Fetch scripts no change is required.

regards,
Web services team

  • John West
    2011-06-22 20:59:55
    Looking at the Network level, I get 803 networks, of which 371 have zero in
    the TotalNumberStations field. Does this mean there are no data holdings for
    those 371 networks? Any insights as to why there are so many with no data?

    Thanks!

    -- John


    On Tue, Jun 21, 2011 at 4:29 PM, Yazan Suleiman
    <yazan<at>iris.washington.edu>wrote:

    Hello webservice users,

    The DMC has updated it's ws-station service:
    http://www.iris.edu/ws/station/

    For users parsing the StationXML returned by ws-station be aware that
    <NumberChannels> has been changed to <TotalNumberChannels>. New elements
    have been introduced:

    TotalNumberStations
    SelectedNumberStations
    TotalNumberChannels
    SelectedNumberChannels


    We have also fixed bugs related to virtual network result sets and
    timewindow for channel epochs.

    For users of the DMC's Fetch scripts no change is required.

    regards,
    Web services team
    _______________________________________________
    webservices mailing list
    webservices<at>iris.washington.edu
    http://www.iris.washington.edu/mailman/listinfo/webservices


    • John West
      2011-06-22 21:20:40
      Further info: interestingly, if I use the updatedafter parameter (I used a
      date of 1801/01/01) I don't get any of the networks with zero station count.

      -- John


      On Wed, Jun 22, 2011 at 1:59 PM, John D. West <john.d.west<at>asu.edu> wrote:

      Looking at the Network level, I get 803 networks, of which 371 have zero in
      the TotalNumberStations field. Does this mean there are no data holdings for
      those 371 networks? Any insights as to why there are so many with no data?

      Thanks!

      -- John



      On Tue, Jun 21, 2011 at 4:29 PM, Yazan Suleiman <yazan<at>iris.washington.edu
      wrote:

      Hello webservice users,

      The DMC has updated it's ws-station service:
      http://www.iris.edu/ws/station/

      For users parsing the StationXML returned by ws-station be aware that
      <NumberChannels> has been changed to <TotalNumberChannels>. New elements
      have been introduced:

      TotalNumberStations
      SelectedNumberStations
      TotalNumberChannels
      SelectedNumberChannels


      We have also fixed bugs related to virtual network result sets and
      timewindow for channel epochs.

      For users of the DMC's Fetch scripts no change is required.

      regards,
      Web services team
      _______________________________________________
      webservices mailing list
      webservices<at>iris.washington.edu
      http://www.iris.washington.edu/mailman/listinfo/webservices




      • Chad Trabant
        2011-06-23 01:18:07

        Hi John,

        Our network listing includes all registered FDSN network regardless whether we have SEED metadata or waveform data from those networks. Yes, zero stations means there are no data holdings for those networks. Similar network overview information is available from the MDA network listing: http://www.iris.edu/mda

        Regarding your second question, we think this is expected behavior. Without stations and channels there is nothing to compare to the updated after date since we do not track updates to the simple network overview information (description, start & end year), even if we did it wouldn't be very meaningful in my opinion. Since nothing was updated nothing is returned for those networks. It's an interesting way to filter them out.

        Chad

        On Jun 22, 2011, at 2:20 PM, John D. West wrote:

        Further info: interestingly, if I use the updatedafter parameter (I used a date of 1801/01/01) I don't get any of the networks with zero station count.

        -- John


        On Wed, Jun 22, 2011 at 1:59 PM, John D. West <john.d.west<at>asu.edu> wrote:
        Looking at the Network level, I get 803 networks, of which 371 have zero in the TotalNumberStations field. Does this mean there are no data holdings for those 371 networks? Any insights as to why there are so many with no data?

        Thanks!

        -- John



        On Tue, Jun 21, 2011 at 4:29 PM, Yazan Suleiman <yazan<at>iris.washington.edu> wrote:
        Hello webservice users,

        The DMC has updated it's ws-station service: http://www.iris.edu/ws/station/

        For users parsing the StationXML returned by ws-station be aware that <NumberChannels> has been changed to <TotalNumberChannels>. New elements have been introduced:

        TotalNumberStations
        SelectedNumberStations
        TotalNumberChannels
        SelectedNumberChannels


        We have also fixed bugs related to virtual network result sets and timewindow for channel epochs.

        For users of the DMC's Fetch scripts no change is required.

        regards,
        Web services team
        _______________________________________________
        webservices mailing list
        webservices<at>iris.washington.edu
        http://www.iris.washington.edu/mailman/listinfo/webservices


        _______________________________________________
        webservices mailing list
        webservices<at>iris.washington.edu
        http://www.iris.washington.edu/mailman/listinfo/webservices


  • Philip Crotwell
    2011-06-23 20:37:33
    Hi

    I have 2 requests.

    1) If the schema for a web service is going to change, please let us
    know before you make the change instead of afterward. If the schema
    changes, then there is a reasonable likelihood that clients will have
    to be changed as well and it is much nicer if there is a little
    warning given.

    2) Please find a way to version the schemas you use and include that
    in the XML returned from your web services. At least then a client can
    tell if the schema it was coded against is different from the schema
    of the returned xml. I think many places do this by putting a version
    number in the URL of the schema location, so something like this could
    be done for ws-station:

    <StaMessage xsi:schemaLocation="http://www.data.scec.org/xml/station/1.2.3
    http://www.data.scec.org/xml/station/1.2.3/station.xsd">

    I think it is nice to keep old version of the schema around as well.
    It is not unreasonable for someone to store metadata as a stationXML
    document, and without versioning of the schema, a xml file that is
    "valid" one day might become invalid the next just due to schema
    upgrades. It might also be a good idea to put the version of the
    server somewhere, prehaps into the <Module> or <Source> elements.

    As a client writer, I am very concerned about backwards incompatible
    changes that will negatively effect applications that I have released.
    I am happy to see ws-station and stationXML being improved, but
    stability of the schema and managing the upgrade path are important as
    well.

    thanks,
    Philip


    On Tue, Jun 21, 2011 at 7:29 PM, Yazan Suleiman
    <yazan<at>iris.washington.edu> wrote:
    Hello webservice users,

    The DMC has updated it's ws-station service: http://www.iris.edu/ws/station/

    For users parsing the StationXML returned by ws-station be aware that <NumberChannels> has been changed to <TotalNumberChannels>.  New elements have been introduced:

    TotalNumberStations
    SelectedNumberStations
    TotalNumberChannels
    SelectedNumberChannels


    We have also fixed bugs related to virtual network result sets and timewindow for channel epochs.

    For users of the DMC's Fetch scripts no change is required.

    regards,
    Web services team
    _______________________________________________
    webservices mailing list
    webservices<at>iris.washington.edu
    http://www.iris.washington.edu/mailman/listinfo/webservices



    • Chad Trabant
      2011-06-23 17:48:51

      Hi Philip,

      You make two good points. Regarding #1 we will better announce upcoming changes to the schema supported by our service, in the future we will likely offer beta versions prior to moving them into production so that client writers such as yourself can test against the updated service. Regarding #2, we think that's a good idea and we'll raise the issue in the StationXML working group.

      Thanks for the suggestions.

      Chad

      On Jun 23, 2011, at 10:37 AM, Philip Crotwell wrote:

      Hi

      I have 2 requests.

      1) If the schema for a web service is going to change, please let us
      know before you make the change instead of afterward. If the schema
      changes, then there is a reasonable likelihood that clients will have
      to be changed as well and it is much nicer if there is a little
      warning given.

      2) Please find a way to version the schemas you use and include that
      in the XML returned from your web services. At least then a client can
      tell if the schema it was coded against is different from the schema
      of the returned xml. I think many places do this by putting a version
      number in the URL of the schema location, so something like this could
      be done for ws-station:

      <StaMessage xsi:schemaLocation="http://www.data.scec.org/xml/station/1.2.3
      http://www.data.scec.org/xml/station/1.2.3/station.xsd">

      I think it is nice to keep old version of the schema around as well.
      It is not unreasonable for someone to store metadata as a stationXML
      document, and without versioning of the schema, a xml file that is
      "valid" one day might become invalid the next just due to schema
      upgrades. It might also be a good idea to put the version of the
      server somewhere, prehaps into the <Module> or <Source> elements.

      As a client writer, I am very concerned about backwards incompatible
      changes that will negatively effect applications that I have released.
      I am happy to see ws-station and stationXML being improved, but
      stability of the schema and managing the upgrade path are important as
      well.

      thanks,
      Philip


      On Tue, Jun 21, 2011 at 7:29 PM, Yazan Suleiman
      <yazan<at>iris.washington.edu> wrote:
      Hello webservice users,

      The DMC has updated it's ws-station service: http://www.iris.edu/ws/station/

      For users parsing the StationXML returned by ws-station be aware that <NumberChannels> has been changed to <TotalNumberChannels>. New elements have been introduced:

      TotalNumberStations
      SelectedNumberStations
      TotalNumberChannels
      SelectedNumberChannels


      We have also fixed bugs related to virtual network result sets and timewindow for channel epochs.

      For users of the DMC's Fetch scripts no change is required.

      regards,
      Web services team
      _______________________________________________
      webservices mailing list
      webservices<at>iris.washington.edu
      http://www.iris.washington.edu/mailman/listinfo/webservices


      _______________________________________________
      webservices mailing list
      webservices<at>iris.washington.edu
      http://www.iris.washington.edu/mailman/listinfo/webservices



00:41:44 v.01697673