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

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
Sent: Monday, November 3, 2014 11:44 AM
To: Dr. David Filip; Yves Savourel
Cc: Schnabel, Bryan S; xliff@lists.oasis-open.org
Subject: RE: [xliff] @disabled in Validation Module. Fix example. Add constraint?

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
Sent: den 3 november 2014 04:50
To: Yves Savourel
Cc: Schnabel, Bryan S; xliff@lists.oasis-open.org
Subject: Re: [xliff] @disabled in Validation Module. Fix example. Add constraint?

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

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

http://www.cngl.ie/profile/?i=452

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
> validation rule at the end of the <file></file>, what rule are we
> temporarily disabling? Rules set in <unit> elements?

No, setting disabled='yes' on a rule at the <file> level disabled that rule.
Any similar rule at the unit level but without a disabled attribute would override it (the default value of disabled is 'no')

You can use it just like a switch to turn off a rule.

> Could you please sketch a use case where @disable at the <file>
> level has meaning?

For example: setting disabled='yes' in the rule at the file level, allow you to keep the rules in the document, but not validate
them. For example if you need to run the document through a tool that, among other things, processes the Validation module but has
no switch to turn that validation off.
(for example when the translations are not final yet)

I hope that helps,
-yves

-----Original Message-----
From: Schnabel, Bryan S [mailto:bryan.s.schnabel@tektronix.com]
Sent: Sunday, November 2, 2014 8:39 PM
To: Yves Savourel; xliff@lists.oasis-open.org
Subject: RE: [xliff] @disabled in Validation Module. Fix example. Add constraint?

I am struggling. Probably my fault. Since once you reach the end of the validation rule at the end of the <file></file>, what rule
are we temporarily disabling? Rules set in <unit> elements?

I cannot imagine this use case.

Could you please sketch a use case where @disable at the <file> level has meaning?

Sorry to be so thick.

-----Original Message-----
From: Yves Savourel [mailto:ysavourel@enlaso.com]
Sent: Sunday, November 02, 2014 5:38 PM
To: Schnabel, Bryan S; xliff@lists.oasis-open.org
Subject: RE: [xliff] @disabled in Validation Module. Fix example. Add constraint?

I think the text that truly defines what the attributes does is:

"This rule attribute determines whether a rule MUST or MUST NOT be applied within the scope of its enclosing element."

It doesn't exclude <file> as an enclosing element.

Then we have "For example, a rule defined at the <file> level can be disabled at the <unit> level." Which provides an example of
usage.

The text "This attribute is provided to allow for overriding execution of rules set at higher levels" seems to be a) redundant and
b) missing a "for example". We could delete it without changing any expected behavior since it seems to cause confusion.

I would be on favor to not add new constraints because using disabled='yes' at the <file> level is a perfectly fine use case: you
can need to temporarily disable rules for examples.

Cheers,
-ys

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

xliff message