| |
| META TOPICPARENT |
name="DALGWSTigerTeam" |
P3T Meeting (online) - Mon Aug 26, 2024 @ 20:00 UTC
Attendees |
|
<
< | |
>
> |
-
- Janet, Pat, Brian, Jesus, Russ, Dave, Joshua, Marco, Gregory, Tom
|
|
<
< |
-
- Pat
- Brian
- Jesus
- Russ
- Dave
- Joshua
- Marco
- Gregory
- Tom
|
| |
Zoom |
|
<
< | https://smithsonian.zoom.us/j/97478328416?pwd=ZEpmMnI4RGhrS01pazF5dXBLbEsyZz09 |
| | Highlights |
|
<
< |
- Prototypes
- IVOA Note
- Session
|
>
> |
- 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
- No integration with a MAST service yet
- Suggests an example document set with a specific implementation
- 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?
|
|
<
< |
-
-
-
- Gregory: Does the pypi uws library have backwards compatibility/legacy support?
|
>
> |
-
-
-
- Gregory: Does the pypi UWS library have backwards compatibility/legacy support?
|
| | |
|
<
< |
-
-
-
- Russ: A legacy uws pypi exists already and can perhaps be merged with the new one…
|
>
> |
-
-
-
- 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. Send 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
|
|
<
< | |
>
> | |
| |
-
- 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
- Needs to figure out how to import the YAML file
- 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:
|
|
<
< |
- Russ on the layer document exercise (in the 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?
|
>
> |
- IVOA Document
- Russ on the layer document exercise (in the 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: should we be engaging clients ahead of the Nov interop?
- Jesus: Perhaps a validator is the best we can do in this time frame.
|
>
> |
-
- 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: 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 as far as
- ahead of the interop
- 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
<--
--> |
|
>
> | |
