search

w3c / pronunciation

Pronunciation Task Force deliverables
https://www.w3.org/WAI/APA/task-forces/pronunciation/
Other
20 stars 12 forks source link

Technical approach document review comments #83

Open alia11y opened 3 years ago

alia11y commented 3 years ago

Jason White from my team sent all this comments after reviewing our document:

  1. Normative and, if applicable, non-normative references should be added and cited using SpecRef. Examples include references to the JSON specification, references to the SSML and PLS specifications, and so forth. This is probably editorial.
  2. In the draft JSON schema, I suggest checking the correctness of (and, if possible, simplifying) the regular expression patterns that specify certain property values, notably time durations. It may be possible to simplify the regular expressions without changing the set of strings that match them. This is not necessarily editorial, if bugs are found in the patterns as given.
  3. For the first public working draft, a clearer discussion of the relative advantages and disadvantages of the two proposed approaches would be helpful. I appreciate that the purpose of publication is to obtain comments, so there may be a benefit in not providing too much commentary to influence reviewers. However, I didn’t find the existing discussion particularly insightful.
  4. The question of how to respond to invalid attributes merits greater attention and should probably be addressed in the specification. Currently, it is noted, but the error handling logic isn’t specified. Nor is there a statement indicating that it is intentionally left for each implementation to decide.
  5. Should there be a security and privacy considerations section?
AutoSponge commented 3 years ago
  1. I'm not sure how to do this, but I'll look for some docs.
  2. I'm not interested in debugging or writing tests for RegExp right now. I feel like if we're 100% going to use JSON, then we'll put that effort into the normative spec.
  3. Without competing implementations, we actually don't know all of the pros/cons. We listed the ones we knew. More to be learned from implementations.
  4. Again, this isn't a normative spec. It's a decision point on the way to a spec. Exactly what error scenarios could come up depend on which branch we take. Also, this document is for authors, not parsers. Parsers will need to handle the errors but we don't know what to tell them to parse until we get passed this document.