RE: [xliff] @disabled in Validation Module. Fix example. Add constraint?

["Schnabel, Bryan S" <bryan.s.schnabel@tektronix.com>]

Hmmm. Ok. But that use would not be consistent with the definition in the spec:

 

“This attribute is provided to allow for overriding execution of rules set at higher levels”

 

There can be no rule set at a higher level than <file>. And <file> cannot be nested. So what rule could @disable at the <file> level ever disable?

 

From: Yves Savourel [mailto:ysavourel@enlaso.com]
Sent: Sunday, November 02, 2014 4:08 PM
To: Schnabel, Bryan S; xliff@lists.oasis-open.org
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: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Schnabel, Bryan S
Sent: Sunday, November 2, 2014 10:56 AM
To: xliff@lists.oasis-open.org
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