P3T Meeting (online) - Mon Aug 26, 2024 @ 20:00 UTC

Attendees

• Attendees:
  • Janet, Pat, Brian, Jesus, Russ, Dave, Joshua, Marco, Gregory, Tom, Jose
• Regrets : Sara

Zoom

Highlights

• Prototypes in work, no major showstoppers
• IVOA Note framework put together and discussed - settling on 4 docs
• Session & Engaging clients - more next meeting
• Next mtg: Sept 23rd @20:00 UTC

Meeting Agenda/Notes

• Status Updates - Prototypes - aiming for mid Sep
  • Josh (UWS, TAP 1.1)
    • UWS prototype nearly complete - published on ST Github
    • No integration with a MAST service yet
    • Suggests an example document set with a specific implementation
    • Wanted to connect to TAP but hit Integ issues - will pursue in print scheduled for next 2 weeks
    • Questions
      • Janet: Will you be moving the prototype to the IVOA github repo?
        • Answer: will be pushing to pypi, maybe IVOA later
      • Pat: Am I referencing the right FastAPI UWS repo?
        • Answer: yes
      • Gregory: Does the pypi UWS library have backwards compatibility/legacy support?
        • Answer: no
      • Russ: A legacy UWS pypi exists already and can perhaps be merged with the new one…
  • Russ ( SODA, UWS)
    • Have been working on getting the legacy UWS packaged up. Will start with the OpenAPI additions next.
    • Created 3 documents that are layered. Sent to the mailing list.
      • Next step: will be adding UWS
      • Need to improve the data types so that they reference VOSI, etc
    • Will be implementing the serialization layer next
    • Questions
      • Russ: How do Josh and I reconcile our work?
        • Answer, Josh: Need external validator
      • Brian: UWS validator available here: https://github.com/kristinriebe/uws-validator
  • Pat (TAP 1.2, UWS, VOSI)
    • Working on OpenAPI on TAP 1.2
    • Started VOSI /tables OpenAPI description
    • Hope to pull in the UWS spec and re-use it, and assemble the whole service API together - PAH - this is much less DRY than desireable (at least I could not find a satisfying solution) - e.g. see https://stackoverflow.com/a/75795907/10862023
    • Needs to figure out how to import the YAML file
    • WIll be working on this over next 2 weeks
  • Dave (Execution Broker)
    • API has been simplified, but data model has become more complex
    • On track to publish the OpenAPI doc and updated specification sometime in October
    • Found something interesting about error messages and handling:
      • https://messagetemplates.org/
• IVOA Document
  • Russ on the layer document exercise (in the p3t mailing list)
    • Point was to provide and example on an encoding format, Next step is UWS part
    • Questions:
      • Brian: What is the vision for the future of types?
        • Russ: OpenAPI and JSON not specific/detailed enough for our use
          • Need to figure out types - are data model and network encoding types shared?
        • Dave: OpenAPI types have been working for me (so far) and are extensible.
        • Gregory: IVOA is missing an unsigned 64 bit integer type, which is being used more and more frequently. This is just a heads up for those looking at type standardization.
        • Russ: Not sure if OpenAPI can handle 64-bit int because (for example) JSON doesn't support that. Probably needs an extension.
      • Jesus: Need to flag issues (such as the 64-bit type problem) somewhere.
      • Jesus: How is OpenAPI referenced/linked from UWS implementation?
      • Josh: Can be more clear. Was a result of the auto-generation.
• Looking ahead to the Nov Interop
  • Janet: When should we be engaging clients ahead of the Nov interop?
    • Jesus: Perhaps a validator is the best we can do in this time frame
    • Brian: Agree, and can be used as a neutral test
    • Dave: Should be reaching out and asking what specific concerns they have?
    • Gregory: Think that some communication with client implementers is needed
    • Josh: Perhaps present it as a "what do you need' question
    • Janet: Have clients engaged in plan
    • Russ: In post May Interop emails most concerns were about interoperability. We haven't figured out the particular situations yet.
    • Marco: Details are important but not as important as the engagement
    • Pat: The plan of interoperability needs to be more than "you must deal with this new version". Question of what's the best way to deal with that must be raised.
    • Gregory: How can clients deal with this new (unscoped) work?
    • Brian: wrap up this thread:
      • We must involve clients with our plans
      • But we can probably only expect to get so far ahead of the interop
      • Engaging with the clients will be a topic at the next mtg once we're a little further along
  • Dave: Lessons learned from auto-generation
    • The more complicated the model, the less well the auto-generators work
      • Java working well
      • Python not so well
    • But still thinks OpenAPI is promising, as it's a machine readable spec.
    • Plan on presenting this in the GWS session
• Next meeting:
  • Sept 23rd @20:00 UTC - will discuss how to engage clients