Actually, looking at the example, I think the example should have isPresent changed to isNotPresent rather than the explanatory text changed.
-ys
From: [mailto:] On Behalf Of Yves Savourel
Sent: Sunday, November 2, 2014 5:08 PM
To: 'Schnabel, Bryan S';
Subject: RE: [xliff] @disabled in Validation Module. Fix example. Add constraint?
Hi Bryan,
I would agree with the first point (fixing the text for isPresent).
But I think we should keep @disabled allowed for rules at the <file> level: it simply allows to disabled the rule where it is set.
-ys
From: [mailto:] On Behalf Of Schnabel, Bryan S
Sent: Sunday, November 2, 2014 10:56 AM
To:
Subject: [xliff] @disabled in Validation Module. Fix example. Add constraint?
Hello,
In 5.8.5.9 disabled, in the Validation Module section, we say:
“This attribute is provided to allow for overriding execution of rules set at higher levels . . .”
And
“In the following example, the isNotPresent rule is applied in its entirety to the first unit, but not to the second.”
I have 2 observations.
(1) The example uses isPresent, not isNotPresent. So I think we should change the sentence to reflect isPresent.
(2) Since there is no higher level that a rule can be set than <file>, I think we should add a constraint that says @disabled MUST NOT be used on a rule, whose parent validation is a direct child of file. There may be a clearer way of stating that. Probably somebody who thinks less XPath-y than me could come up with a constraint that is worded more clearly.
Thanks,
Bryan
