Bugzilla – Bug 380
add additional constraints on the <label> element for the cases where it has/lacks a "for" attribute
Last modified: 2009-04-07 18:14:38 CEST
The content model for the <label> element states the following constraints:
"If the element has a for attribute: Phrasing content, but with no descendant labelable form-associated elements or label elements.
Otherwise: Phrasing content, but with at most one descendant labelable form-associated element, and with no descendant label elements."
The current assertions.sch file does not seem to capture the "no descendant labelable form-associated elements" for the case when there is a "for" attribute, nor the "at most one descendant labelable form-associated element" for the case where there is not "for" attribute.
The content model now reads: "Phrasing content, but with no descendant labelable form-associated elements unless it is the element's labeled control, and no descendant label elements." and "If the for attribute is not specified, but the label element has a labelable form-associated element descendant, then the first such descendant in tree order is the label element's labeled control."
But, anyway, the language for the label[not(@for)] case seems to be stating the same constraint as "with at most one descendant labelable form-associated element".
I'll take a look at updating the assertions.sch file to capture the constraints. After that, maybe I can take a shot at updating the corresponding Java code so that I can actually test whether I've got it captured correctly or not.
Created attachment 63 [details]
diff showing changes to assertions.sch
this diff adds the constraint checking in assertions.sch only; if it looks OK, I'll go ahead and commit it. In the mean time, I'm reading the org.whattf.checker.schematronequiv.Assertions code to see if I can figure out how to add the same constraint checks there
landed change to assertions.sh in r389
Created attachment 66 [details]
patch for label@for descendant-checking in Assertions.java
Tested and working as expected per current spec as far as I can tell. There's probably a better way to do this, but this is the best I could figure out on my own...
Created attachment 67 [details]
updated patch that moves label@for checking to attribute loop
landed label@for descendant checking in r394
revised assertions.sch to use explicit @id checks for label@for descendants (instead of id() check)
Created attachment 70 [details]
additional patch to check for label with multiple labeled descendants
Created attachment 71 [details]
updated patch for label with multiple labeled descendants + refinement to label@for checking
changed label@for checking to just set a hasFor boolean instead of putting the "for" values into a hashmap
Created attachment 72 [details]
label with multiple labelable descendants
adding warning messages to indicate which label has multiple labelable descendants; however, not working as expected because it's reporting the location of the offending descendant, instead of reporting the location of the label
landed "no label with multiple labelable descendants" checking in r398
*** Bug 427 has been marked as a duplicate of this bug. ***