[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] @disabled in Validation Module. Fix example. Add constraint?
|
Hi all, The summary of what I’m hearing is that *there is no harm in having a validation element with a rule set to disabled=”yes” at the file level* - but the
use cases I’ve seen so far, and the references to the spec I’ve seen pointed to - still leave me unconvinced. The argument, as I understand it, is that you may have a rule element with some rule set (let’s say isPresent), and on that very same rule element
you disable that very rule by setting disabled=”yes”. And the part of the spec said to justify this is "This rule attribute determines whether a rule MUST or MUST NOT be applied within the scope of its enclosing element." If that were the only sentence in the description, I would say it is an ambiguous statement, but it could support that use case. But luckily the description does not end there. It continues “For example, a rule defined at the <file> level can be disabled at the <unit> level.” And then
it further clarifies its intention (in my opinion) with the next sentence “This attribute is provided to allow for overriding execution of rules set at
higher levels (emphasis added by me)” To me you cannot be any clearer than that. None of us are arguing against this: <file id="f1"> <val:validation> <val:rule isPresent="store" /> </val:validation> <unit id="1"> <segment id="1"> <source>Choose an option in the online store:</source> <target>Escolha uma opção na loja online:</target><!-- this is invalid --> </segment> </unit> <unit id="2"> <val:validation> <val:rule isPresent="store" disabled="yes" /> </val:validation> <segment id="1"> <source>Choose an option in the online store:</source> <target>Escolha uma opção na loja online:</target><!-- this is valid because @disabled at the unit-level--> </segment> </unit> </file> The first unit is invalid because it violates the global rule set at the file level. The second unit is valid because the global rule is disabled for that unit.
But if I understand how those who want to keep @disabled at the file level are thinking. I think the following is that use case. <file id="f1"> <val:validation> <val:rule isPresent="store" disabled=”yes” /> </val:validation> <unit id="1"> <segment id="1"> <source>Choose an option in the online store:</source> <target>Escolha uma opção na loja online:</target><!-- this is valid --> </segment> </unit> </file> The use case says one may both set and unset a validation rule on the same rule element. And I guess the reason to do so is that one might want to load the
file element with the rule for use at a later time. And when that later time comes, the agent removes the disabled=”yes” – and the rule springs back into being enforceable.
I am not against this functionality per se. If we want to support this use case (and it sounds like most on this thread do), I think the spec needs to be updated
to explicitly support it. In my opinion, as currently written, the spec does not support it. Thanks, Bryan From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
On Behalf Of Yves Savourel Hi Fredrik, all, Yes, the example of a temporary disabling would have to go along with a step making sure the original values are set back properly (which means remembering which rules
had a disabled=’yes’ before). That example is an extreme one. The best solution for “temporarily disabling” validation is to have an option in the processing tool to apply or not the rules, so no one has to change the rules themselves
(just like here: http://okapi-lynx.appspot.com/validation) Cheers, -yves From:
xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
On Behalf Of Estreen, Fredrik Hi All, I agree that it should be fine to allow <file> level rules to be disabled. I don’t see any harm in doing so.
I’m not sure about the “temporary” disabling though. It would obviously work, but the agent doing that would have to keep enough information to undo that operation.
There is a constraint that modifiers MUST NOT change any of the validation module attributes that were already present in the file. I assume that that includes changing implicit default valued attributes. If a use case example is added I think we need to be
careful that the example does not encourage things that are prohibited by other constraints. Regards, Fredrik Estreen From:
xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
On Behalf Of Dr. David Filip Bryan, Yves, all I see the use case of temporarily switching off the rules at the highest level as valid. If you think of a conformant validation processor that is to disable the rules until translations are final, this flag is actually the conformant way to do it. As result I agree with Yves that no material change is needed (no new constraint). Just correction of example and clarification of description. If we reach consensus on that, we can assign an Editor to fix this. Cheers dF
Dr. David Filip ======================= OASIS XLIFF TC Secretary, Editor, and Liaison Officer LRC | CNGL | CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 mailto: david.filip@ul.ie On Mon, Nov 3, 2014 at 4:14 AM, Yves Savourel <ysavourel@enlaso.com> wrote: > I am struggling. Probably my fault. Since once you reach the end of the
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]