ARIA-AT Automation Working Session

23 May 2022


michael_fairchild, s3ththompson, zcorpan
Michael Fairchild

Meeting minutes

<zcorpan> RRSAgent: make logs public

Discuss protocol schema definition language


<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://github.com/w3c/webdriver-bidi/pull/44

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://github.com/w3c/webdriver-bidi/pull/194

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


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

Minutes manually created (not a transcript), formatted by scribe.perl version 185 (Thu Dec 2 18:51:55 2021 UTC).


Maybe present: Job, Matt_King, mzgoddard