Meeting minutes
<zcorpan> RRSAgent: make logs public
Discuss protocol schema definition language
https://
<zcorpan> Because it was the best option we could find given that we wanted something that could be written by hand and understood by readers, and also had some kind of specification.
<zcorpan> It was not an option anyone really loved, but was considered the least worst
zcorpan: the AT automation spec proposes defining the protocol with the CDDL language
<zcorpan> https://
zcorpan: jkva on GitHub asked about alternatives, such as JSON schema which seem to have better tooling support. since we aren't building on WebDriver directly, do we need to use CDDL?
<mzgoddard> +present
zcorpan: i tried to do some research into why WebDriver BiDi originally picked CDDL, by asking in their IRC channel. they picked CDDL because it had a normative specification, wasn't as verbose as JSON schema, and had been used prior in another W3C spec
zcorpan: personally, i agree with the goal to have a schema that is easy to write (and not to verbose), but as a consumer of the spec, i like the idea of using something like JSON schema that has a lot of tooling for parsing, etc.
James Scholes: i think we need to make sure that the people working on ARIA-AT have the capacity to easily parse the spec. it seems like CDDL would require a lot of custom tooling to work with. for our teams, perhaps going with something with better support would help us work expediently and efficiently.
Job: i don't have an issue with CDDL itself, but it seems to me that the commands/queries for our spec might not cover too large of a surface area. if we write in JSON schema (which now has an IETF draft spec), we'd at least have a definition we'd be able to validate against without worrying about custom parsing / validation. so my concerns are mostly implementation speed wise
Matt_King: I found it interesting in the original CDDL decision for webdriver that the ease of hand writing was considered. Does that have any relevance in this project?
mzgoddard: in my opinion, it's significant... since reviewing and drafting pull requests is mostly done by hand. JSON schema is verbose. personally, i think it can take a lot of time to review. not that i don't like how it specifies things...
James Scholes: i think there are UIs and tools that might be able to help read generated output for those who think that JSON Schema is unoptimal
mzgoddard: i'm a little worried about how we might review the original source schema if others are reviewing downstream/generated documentation
Job: in terms of tooling, there wasn't a CDDL Go implementation easily at hand (although other things like CBOR were widely supported)... it was an assessment that also was concerned with how active libraries were, etc.
s3ththompson: i also noticed that the WebDriver BiDi community recently switched their CDDL implementation to Rust since it was a better fit for their use cases https://
mzgoddard: can we document what tools/libraries and languages we might be using, just so that we're all on the same page, etc.
zcorpan: another option is we could maintain a mapping between CDDL and JSON Schema
zcorpan: why don't we switch to JSON Schema (in the short term) and investigate whether we can support a mapping to provide both JSON Schema and CDDL in the spec. I will also research to make sure we're not losing out on any semantic expressiveness in the process
Settings Milestone
https://
zcorpan: *summarizes issue above*
James Scholes: i wonder if we should instead follow a slightly different approach to unlock the long tail of settings first (rather than work on the abstracted, shared settings first)
Matt_King: i think in the long arc of things, there will never be perfect alignment. there will always be some things that will be aligned.... we can definitely implement certain things as convenience mechanisms, but having a generic tokenized approach in any given screen reader seems to be a better place to start
mzgoddard: that makes sense to me. we could have a low-level protocol and then if any two implementations agree on a higher-level implementation it can be standardized as a separate section
James Scholes: it also allows people to start working on userland abstractions
Matt_King: i think the 3 low-level starting points are: return all settings, get a single setting, set a single setting, reset to defaults, and load config file