Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

TD section on schematron constraints still needs work #2639

Open
sydb opened this issue Dec 16, 2024 · 1 comment
Open

TD section on schematron constraints still needs work #2639

sydb opened this issue Dec 16, 2024 · 1 comment
Assignees
@sydb @ebeshero
Labels
CouncilResponsibility Status: Needs Discussion TEI: Guidelines & Documentation TEI: Schematron
Milestone
Guidelines 4.10.0

Comments

@sydb
Copy link
Member

sydb commented Dec 16, 2024

[This is a continuation of the two remaining concerns of #2179, which is now closed. The point of moving those two concerns here is that while the other four have been addressed, an interested party would have to read through nearly a dozen comments, most of which are now irrelevant, to get caught up. Here, hopefully, we can concentrate on the work left to do.]

Points to address below are in bold; the list is designed to mirror those of previous ticket:

  1. DONE, at least to some extent.
  2. DONE.
  3. Being addressed elsewhere.[1]
  4. “The language used by constraint messages varies wildly between formal passives ("x should be,,,") and hortatory ("you should...") : either be consistent or thematize that this is a project choice”
  5. “The phrase " note here the use of a report and an assertion within one pattern:" is not very informative. This section doesn't have to provide a full schematron tutorial (though it might be useful to reference one) but gnomic remarks like this don't help.”
  6. Irrelevant, now that we require @context of <rule>.

Note
[1] In #2330, and thus #2594, TEIC/Stylesheets#696, & TEIC/Stylesheets#697, to be precise.
@sydb sydb added this to the Guidelines 4.10.0 milestone Dec 16, 2024
@sydb
Copy link
Member Author

sydb commented Dec 16, 2024

My thoughts:

  1. I think prose should explain that linguistic style is project-specific, and therefore we exemplify different approaches in different examples. That said, the two messages in this example (“A <table> should have a caption, using a <head> element”, & “Do not use tables to lay out the document body”) should be modified so that they use the same basic approach.
  2. I do not think the phrase in question (“note here the use of a report and an assertion within one pattern”) is particularly gnomic or problematic. That said, it is not particularly helpful, either; so I would not be sad to see it go. Perhaps this would be a good place to address (4), above, though. For example, something along the lines of the following. (Although perhaps this advice deserves a paragraph of its own, instead.)

Schematron rules can also be used to enforce other HTML accessibility rules, here about tables. Note that the messages within constraints may occur in whatever writing style a project is most comfortable (e.g., as commands such as “Do not use <table> inside <body>”, as declarations such as “<table> is not allowed inside <body>”, or as explanations such as “using <table> inside <body> to layout content makes it hard for screen readers to process your output”; either in the singular or the plural, etc.), however it is best if consistent practice is used within a given project, lest its encoders became annoyed, or worse, confused.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@sydb sydb

@ebeshero ebeshero

Labels
CouncilResponsibility Status: Needs Discussion TEI: Guidelines & Documentation TEI: Schematron
Projects
None yet
Milestone
Guidelines 4.10.0
Development

No branches or pull requests
2 participants
@sydb @ebeshero