"Adding clarification on input aspects" by Mary Jo, with a comment from Anne
Anne: I think the order in Mary Jo's edit is a bit weird. We are talking about something that we don't introduce until later, after the examples
Wilco: In your edit, you moved the MUST requirement up. So it's just reorganising?
Anne: yes
<shadi> +1
Wilco: +1 from me, but can we leave it up to Mary Jo?
Anne: Yes
Shadi: Wilco, can you put in a note about what we have discussed and ping Mary Jo?
Wilco: Yes
<shadi> +1
Wilco: breaking out optional items from the MUST list. Anyone disagree?
... No one disagrees, so that one is good to go. Leaving a reply
Wilco: Editorial changes, nothing big. What is change in line 244?
Kasper: Missing a "the"
<shadi> +1
Shadi: One of the changes will create a conflict with something I just updated
Wilco: That's fine. Anyone disagrees? No
Wilco: Looks alright to me.
... Did you mention a while ago that capitalizations of requirements (MUST, SHOULD) etc. should be done differently?
Shadi: I think they are done right currently. Ideally we should be using markup to capitalize them
Wilco: Let's create a pull request for that, when this one is merged. "Editorial", and assigned to me
<shadi> +1
Wilco: Anyone disagreeing with this change on #380? No.
<shadi> +1
Shadi: When "Web" is used as a noun, we capitalize it, but when it is used as an adjective, e.g. in "web technology" it should be written in small caps
Wilco: All right. Anyone disagree with the changes made? No.
Shadi: "fully-automated, semi-automated and manual categories" - someone asked how we define them, so we removed them instead, since they are not used anywhere else.
Wilco: It seems consistent. Any concerns? No.
Wilco: I have added that if a rule is within a set, the identifier is unique within that set
Shadi: grammar seems broken in the first sentence
Wilco: can we get proposals in IRC?
<shadi> [[An ACT Rule MUST have an identifier that is unique when the rule is part of a ruleset.]]
<trevor> An ACT Rule MUST have a unique identifier, meaning that if the rule is part of a ruleset it is unique within that set.
<shadi> [[An ACT Rule MUST have an identifier. This identifier MUST be unique when the rule is part of a ruleset.]]
<shadi> [[An ACT Rule MUST have an identifier. This identifier MUST be unique within a ruleset when the rule is part of a set.]]
Wilco: Then there is the other part about identifying across versions
Shadi: I would prefer then to have all the requirements together, but it's a matter of preference
... But the first section still needs to be changed
Kathy: I am not sure I understand why we need the second sentence, because if it is unique, it will be unique everywhere
Shadi: yes, we need to remove the one "unique"
<shadi> [[An ACT Rule MUST have an identifier. This identifier MUST be unique when the rule is part of a ruleset. The identifier can be any text, such as plain text, URL or a database identifier. [...] In addition to the identifier, each new release of an ACT Rule MUST be versioned with either a date or a number. A reference to the previous version of that rule MUST be available. The identifier MUST NOT be changed when the rule is updated. For extensive changes, a
<shadi> new rule SHOULD be created with a new identifier, and the old rule SHOULD be deprecated.]]
<shadi> CHANGE: extensive changes to substantial changes
Shadi: Can we exchange "extensive changes" with "substantial changes" since it's not about quantity, but quality
Wilco: Yes. Anyone disagree with this proposal? No.
... I will make some edits. Anything else on this one? No.
Shadi: Kathy, did this clarify your question?
Kathy: Yes, thank you
Wilco: Changing "Vue component" to "web component". Anyone disagree? No.
<shadi> +1
<Wilco> https://pr-preview.s3.amazonaws.com/w3c/wcag-act/pull/387.html#act-rule-structure
<shadi> +1
Wilco: A straight forward one: linking to the right heading
... a good catch from Audrey. Any comments? No.
<shadi> +1
Wilco: Removing uninted "may" and "must". Anyone disagree? No.
Shadi: First I added an introduction paragraph to the section to give context. Level Access requested more details and examples on EARL. We are now also linking out. I provided a small list outlining the examples for people to orient themselves before diving into the examples.
... Clarified example headings. Adding the context that we previously just assumed. Making examples self-enclosed. Linking out to Github repository where people can find more up to date information.
... We cannot change the spec, so I want to not have too much information within this, but link out instead to something that we can easily update.
Wilco: Should we link out to JSON-LD?
Shadi: It does already
Wilco: It doesn't link to the spec itself
Shadi: Good point
... Let me make the first two acronyms to links to more informative pages, not directly to the spec
Wilco: I think we should link to the spec
Shadi: What does other think? Is linking to json.org helpful?
Wilco: I think it is so simple that it doesn't need an explanation
Shadi: I will just change json.org link to the spec.
Wilco: Should we even link to the ACT Rules Community Group? Because the plan is to eventually have the rules at w3.org
... Should we introduce ACT-CG as a namespace in the spec?
Shadi: I think we need to check whether we can do such an update from Public Review to Recommendation phase?
Wilco: I want to give this a careful review. I'll do it today.
Shadi: Will it be okay if we merge all these changes and then do a CFC on the updated editor's draft
Wilco: My idea is that we merge all pull requests and then create a CFC for next editor's draft
... Mary Jo completed all of her tasks. I still need to respond to one of Alistair's comments
Shadi: So the Task Force agrees with how we responded to all of the comments, and our resulting changes
... We need to prove to the Working Group that we responded and that everyone is happy with the responses
... I think we need either a survey or a CFC
Wilco: I think email is going to be fine. Everything has already been discussed on calls and is in minutes
Shadi: yes, and we didn't make any feature changes
Wilco: question is to better define what we mean by "atomic"
Alistair: I think defining what we mean by "atomic" as in Anne's proposal is a good way forward
Wilco: I guess this would go in section 3. Rule Types
Anne: I think the underlying issue is whether it is more atomic to write a rule for everything that has the semantic role of button, or something that looks for one specific type of element. I don't think an "atomic" definition will help anything for that issue
Wilco: Are we okay not having a stricter definition of "atomic" in the rules format?
Alistair: If we cannot get rules as atomic as we need, and cannot chain rules in composite rules, there is an issue