Re: [xliff] RE: Contsraints for start and end markers and codes was: Re:

Subject: Re: [xliff] RE: Contsraints for start and end markers and codes was: Re: [xliff] RE: Resolution proposal/Call for Dissent Re: [xliff] mrk translate outside the content but in scope

Thnaks, Yves

inline

Dr. David Filip

=======================

LRC | CNGL | LT-Web | 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 Thu, Nov 7, 2013 at 12:24 PM, Yves Savourel <ysavourel@enlaso.com> wrote:

Hi David, all,

> • The attribute isolated MUST be set to yes when the <sc>

> element corresponding to this end code is not in the same <unit>.
> [The attribute does not need to be *set* to "no" otherwise, because
> "no" is the default value. The same is true for the sc constraint.]
> • Exactly one of the attributes id or startRef MUST be specified:

> o The startRef attribute is REQUIRED if and only if the value of

> the attribute isolated is "no".

> o The id attribute is REQUIRED if and only if the value of isolated
> is "yes".

How about this:

• The attribute isolated MUST be set to yes only when the <sc>

element corresponding to this end code is not in the same <unit>.

I agree that adding the word "only" improves to clarity, so this one is fine with me..

• Exactly one of the attributes id or startRef MUST be specified:
o The startRef attribute MUST be specified if and only if the

value of the attribute isolated is "no".

o The id attribute MUST be specified if and only if the value

of isolated is "yes".

Rational:
- adding 'only' in the first PR says yes is not to be used in other cases
- using "REQUIRED" just after OPTIONAL is used for the same attributes in the list of attributes looks a bit strange.

However, I think that static Constraints are more naturally expressed using the wording with REQUIRED/OPTIONAL than the verb variants MUST/MAY. [BTW, I have been doing these reformulations from MUST to REQUIRED in Constraints as part of the normative language rehaul after csprd01)]

And it is exactly my intent to stress the contrast with the keyword OPTIONAL in the list, to make it clear that the Constraints are similar type of information

that is importantly adjusting the schema expressible information given in the flat lists above.

From the schema point of view both attributes are optional. But the option is rather tight because exactly one of them is REQUIRED. This is what we want to express in the Constraint.

This said, I can live with the MUST formulations if you or others are not convinced by the above reasoning for the REQUIRED formulations, because they are after all equivalent.. We just seem to differ in the opinion which is clearer from the implementer point of view..

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