RE: [xliff] Another spec question - processing requirements for state attribute

I'm still not 100% sure if I'm right about the interpretation
😊

 

But if this is true, I can imagine there are many invalid XLIFF 2 files everywhere.

In my honest opinion, I feel the XLIFF spec is problematic and we should correct it.

 

I think there are a few options to resolve this problem, without affecting existing XLIFF 2 files with no explicit state attribute, with <target> element.

 

Option 1. Change the processing requirement - "Writers MUST NOT set the state attribute values to other than the default initial if and only if the <segment> element where the attribute is set doesn't have the <target> child." Either changing
 "MUST NOT" to "SHOULD NOT" or completely drop this (i.e. allowing state="initial" with <target>)

 

Option 2. Add a new state keyword â "unknown" and change default value from "initial" to "unknown", or do not define default value (so if not specified, no value for "state", which would be interpreted as "unknown").

 

Option 1 won't affect the XLIFF core schema. The attribute definition can stay same. But I think the original intent/semantics of "initial" might be lost.

Option 2 affects XLIFF core schema, removing default value might match the idea what Rodolfo explained in earlier response.

 

-Yoshito

 

From: <> on behalf of "Rodolfo M. Raya" <>

Date: Thursday, April 7, 2022 at 3:54 PM

To: "" <>

Subject: [EXTERNAL] RE: [xliff] Another spec question - processing requirements for state attribute

 

Hello: Yoshito is right, an attribute that has a default value defined in the schema should be automatically added to an element when a parser is processing an element that lacks the
 attribute. I have to fix my validator to handle the "state" ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hello:

 

Yoshito is right, an attribute that has a default value defined in the schema should be automatically added to an element when a parser
 is processing an element that lacks the attribute.

 

I have to fix my validator to handle the "state" attribute and probably some other attributes too. 

 

Regards,

Rodolfo

--

Rodolfo M. Raya 

Maxprograms http://www.maxprograms.com

-------- Original Message --------

Subject: RE: [xliff] Another spec question - processing requirements for

state attribute

From: "Rodolfo M. Raya" <>

Date: Thu, April 07, 2022 2:44 pm

To: <>

 

Hello
Yoshito,

 

I based my reply on my experience with Java XML
parsers. They
 donât set the attribute when it is missing in the XML file.

 

What you write is logical indeed and you are probably right. If you are right as it seems, then most of the XLIFF files Iâve seen are
 invalid.

 

I need to investigate a bit more what
parsers should
 do in this case and adjust my validator
 accordingly.

 

Regards,

Rodolfo

--

Rodolfo M. Raya 

Maxprograms http://www.maxprograms.com

-------- Original Message --------

Subject: RE: [xliff] Another spec question - processing requirements for

state attribute

From: Yoshito
Umaoka <>

Date: Thu, April 07, 2022 2:05 pm

To: "Rodolfo M. Raya" <>,

"" <>

#wmQuoteWrapper #wmQuoteWrapper /* Font Definitions */ @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} #wmQuoteWrapper #wmQuoteWrapper @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} #wmQuoteWrapper
 #wmQuoteWrapper @font-face {font-family:"Yu Gothic"; panose-1:2 11 4 0 0 0 0 0 0 0;} #wmQuoteWrapper #wmQuoteWrapper @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} #wmQuoteWrapper #wmQuoteWrapper @font-face {font-family:Verdana; panose-1:2
 11 6 4 3 5 4 4 2 4;} #wmQuoteWrapper #wmQuoteWrapper @font-face {font-family:"\@Yu Gothic"; panose-1:2 11 4 0 0 0 0 0 0 0;} #wmQuoteWrapper #wmQuoteWrapper /* Style Definitions */ p.MsoNormal, #wmQuoteWrapper #wmQuoteWrapper li.MsoNormal, #wmQuoteWrapper #wmQuoteWrapper
 div.MsoNormal {margin:0in; font-size:11.0pt; font-family:"Calibri",sans-serif;} #wmQuoteWrapper #wmQuoteWrapper a:link, #wmQuoteWrapper #wmQuoteWrapper span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} #wmQuoteWrapper #wmQuoteWrapper
 p.MsoListParagraph, #wmQuoteWrapper #wmQuoteWrapper li.MsoListParagraph, #wmQuoteWrapper #wmQuoteWrapper div.MsoListParagraph {mso-style-priority:34; mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:11.0pt;
 font-family:"Calibri",sans-serif;} #wmQuoteWrapper #wmQuoteWrapper span.pfptpreheader1 {mso-style-name:pfptpreheader1; display:none;} #wmQuoteWrapper #wmQuoteWrapper span.pfpttitlemso1 {mso-style-name:pfpttitlemso1; font-family:"Arial",sans-serif; color:black;
 font-weight:bold;} #wmQuoteWrapper #wmQuoteWrapper span.pfptsubtitlemso1 {mso-style-name:pfptsubtitlemso1; font-family:"Arial",sans-serif;} #wmQuoteWrapper #wmQuoteWrapper span.EmailStyle39 {mso-style-type:personal-reply; font-family:"Calibri",sans-serif;
 color:windowtext;} #wmQuoteWrapper #wmQuoteWrapper .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} #wmQuoteWrapper #wmQuoteWrapper @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} #wmQuoteWrapper #wmQuoteWrapper div.WordSection1
 {page:WordSection1;} #wmQuoteWrapper #wmQuoteWrapper /* List Definitions */ @list l0 {mso-list-id:196740347; mso-list-template-ids:1768201586;} #wmQuoteWrapper #wmQuoteWrapper @list l1 {mso-list-id:1294554087; mso-list-type:hybrid; mso-list-template-ids:-1840994568
 -345231428 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;} #wmQuoteWrapper #wmQuoteWrapper @list l1:level1 {mso-level-number-format:bullet; mso-level-text:-; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;
 font-family:"Calibri",sans-serif; mso-fareast-font-family:"Yu Gothic";} #wmQuoteWrapper #wmQuoteWrapper @list l1:level2 {mso-level-number-format:bullet; mso-level-text:o; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:"Courier
 New"; mso-bidi-font-family:"Times New Roman";} #wmQuoteWrapper #wmQuoteWrapper @list l1:level3 {mso-level-number-format:bullet; mso-level-text:Â;
 mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:Wingdings;} #wmQuoteWrapper #wmQuoteWrapper @list l1:level4 {mso-level-number-format:bullet; mso-level-text:Â;
 mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:Symbol;} #wmQuoteWrapper #wmQuoteWrapper @list l1:level5 {mso-level-number-format:bullet; mso-level-text:o; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;
 font-family:"Courier New"; mso-bidi-font-family:"Times New Roman";} #wmQuoteWrapper #wmQuoteWrapper @list l1:level6 {mso-level-number-format:bullet; mso-level-text:Â;
 mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:Wingdings;} #wmQuoteWrapper #wmQuoteWrapper @list l1:level7 {mso-level-number-format:bullet; mso-level-text:Â;
 mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:Symbol;} #wmQuoteWrapper #wmQuoteWrapper @list l1:level8 {mso-level-number-format:bullet; mso-level-text:o; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;
 font-family:"Courier New"; mso-bidi-font-family:"Times New Roman";} #wmQuoteWrapper #wmQuoteWrapper @list l1:level9 {mso-level-number-format:bullet; mso-level-text:Â;
 mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:Wingdings;} #wmQuoteWrapper #wmQuoteWrapper ol {margin-bottom:0in;} #wmQuoteWrapper #wmQuoteWrapper ul {margin-bottom:0in;}

Hi Rodolfo,

 

> As the use of
 "state" is optional, parsers
 don't apply the default value when processing a file. 

 

I still don't understand above. I admit I'm not XML schema expert. But I read w3c specs and some other tutorials, I could only see

 

Processors of the schema should act as if the attribute was specified with the default value
 if it was absent.

If the schema provides a default value, the "use" attribute must be "optional" ("optional" is
 the default value for "use" in XML schema, so either use="optional" is explicitly declared or not specifying the "use" attribute)

 

> The fragments  <segment>
 and <segment state="initial">
 are not equivalent.

 

So I could not find any specifications or explanation that support your statement above.

 

 

-Yoshito

 

 

From:
<>
 on behalf of "Rodolfo M. Raya" <>

Date: Thursday, April 7, 2022 at 7:06 AM

To: "" <>

Subject: [EXTERNAL] RE: [xliff] Another spec question - processing requirements for state attribute

 

Hi
Yoshito, The
 core XML Schema defines "state" attribute like this: <xs:attribute
 name="state" use="optional" type="xlf:stateType"
 default="initial"/> where xlf:stateType
 is an enumeration with four values. â
â
â
â
â
â
â
â
â
â
â
â
â
â
â
â
â
â
â
â
â
â
â
â
â
â
ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi
Yoshito,

 

The core XML Schema defines "state" attribute like this:

 

     
<xs:attribute
 name="state" use="optional" type="xlf:stateType"
 default="initial"/>

 

where
xlf:stateType
 is an enumeration with four values.

 

Your example

 

  <segment>

    <source>Foo</source>

    <target>Bar</target>

  </segment>

 

is legal.

 

The fragments  <segment>
 and <segment state="initial">
 are not equivalent. As the use of "state" is optional,
parsers don't
 apply the default value when processing a file. 

So, we are dealing with an XML grammar trick here. 

Your concerns would be valid if we were still using
DTDs to define
 the grammars. We are using XML Schema now because DTDs
 can't express what the specification says. 

The
Schematron rules
 shipped with XLIFF 2.0 / 2.1 are broken due to this XML Schema trick. They say that valid XLIFF files have errors because the "state" attribute is not properly handled. 

Regards,

Rodolfo 

--

Rodolfo M. Raya 

Maxprograms http://www.maxprograms.com

-------- Original Message --------

Subject: RE: [xliff] Another spec question - processing requirements for

state attribute

From: Yoshito
Umaoka <>

Date: Thu, April 07, 2022 2:10 am

To: "Rodolfo M. Raya" <>,

"" <>

Hi Rodolfo,

 

>2) If <target>
 is present in <segment>, the value of "state" cannot be "initial.

 

This is the point I don't like. The spec defines "initial" as the default value of "state". If there are no default value, I can understand
 the processing requirement above.

When we parse XLIFF to
runtime representation
 in tooling code, <segment> and <segment state="initial"> should be equivalent.

 

The processing requirement above says:

 

  <segment state="initial">

    <source>Foo</source>

    <target>Bar</target>

  </segment>

 

Is illegal. But

 

  <segment>

    <source>Foo</source>

    <target>Bar</target>

  </segment>

 

Is above illegal?

 

If we need to handle above two expressions differently, then parser needs to manage two different states "state is set and the value
 is initial" and "state is not set". If default value is not defined for state attribute, then it makes sense.

 

-Yoshito

 

 

From:
<>
 on behalf of "Rodolfo M. Raya" <>

Date: Wednesday, April 6, 2022 at 8:06 PM

To: "" <>

Subject: [EXTERNAL] RE: [xliff] Another spec question - processing requirements for state attribute

 

Hello
Yoshito, What
 the spec tries to say is something like this: 1) If a <segment> does not have <target>, the only possible value for "state" is "initial" 2) If <target> is present in <segment>, the value of "state"
ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

 

Hello
Yoshito,

 

What the spec tries to say is something like this:

 

1) If a <segment> does not have <target>, the only possible value for "state" is "initial"

2) If <target> is present in <segment>, the value of "state" cannot be "initial.

 

I really don't like how the _expression_ "if and only if" is used in the specification. It is not as clear as what you can express with
 two conditions like the ones above.

 

I don't think "state" can be explicitly set to "initial" when there is a <target> because the target must contain a translation for
 the sibling <source>, which means it can't be empty and therefore it can't be in "initial" state. 

 

And you are probably right about the errors in the examples. We need to validate them all.

 

Regards,

Rodolfo

--

Rodolfo M. Raya 

Maxprograms http://www.maxprograms.com

-------- Original Message --------

Subject: [xliff] Another spec question - processing requirements for

state attribute

From: Yoshito
Umaoka <>

Date: Wed, April 06, 2022 7:04 pm

To: "" <>

http://docs.oasis-open.org/xliff/xliff-core/v2.1/os/xliff-core-v2.1-os.html#state

 

The processing requirements section has a statement:

 

  Writers MUST NOT set the state attribute values to other than the default initial if and only if the <segment> element where the attribute
 is set doesn't have the <target> child.

 

I'm struggling to interpret "only if" part. Above statement seems to tell

 

If <segment> does not have <target>, writers must not set state attribute other than "initial". I understand this requirement.

If <segment> has <target>, writers must not set state="initial". This is my interpretation of the part "only if".

 

My interpretation 2 is correct, I think many examples in XLIFF 2.1 seem to violate the processing requirement, because the default value
 of state attribute is "initial".

 

<segment> (with no attributes) is equivalent to <segment state="initial">, because the default value of state attribute is "initial".
 So the segment like below (found in the XLIFF specification) does not look right, because <segment> status should be interpreted as "initial"

 

<xliff
 xmlns="urn:oasis:names:tc:xliff:document:2.0" version="2.0"

   
srcLang="en"
trgLang="fr">

  <file id="f1">

    <notes>

      <note id="n1">note for file.</note>

    </notes>

    <unit id="u1">

      <my:elem
xmlns:my="myNamespaceURI"
 id="x1">data</my:elem>

      <notes>

        <note id="n1">note for unit</note>

      </notes>

      <segment id="s1">

        <source><pc
 id="1">Hello <mrk id="m1"
 type="term">World</mrk>!</pc>

            </source>

        <target><pc
 id="1">Bonjour
le <mrk
 id="m1" type="term">Monde</mrk>

            ! </pc></target>

      </segment>

    </unit>

  </file>

</xliff>

 

If the processing requirement statement says " MUST NOT set the state attribute values to other than the default initial EXPLICITLY",
 then it somewhat makes sense. But at the same time, from the tool developer's point of view, distinction between implicitly set (default value) or explicitly set is often not clear sometimes. I personally think changing the statement to "Writers MUST NOT set
 the state attribute values to other than the default initial if the <segment> element where the attribute is set doesn't have the <target> child." (dropping "only if") might resolve the conflict. In other words, state="initial" can be still used even <target>
 exists, but if <target> is absent, state must be "initial".

 

Again, is my interpretation wrong?

 

-Yoshito

 

 

 

 

--------------------------------------------------------------------- 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

--------------------------------------------------------------------- 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

--------------------------------------------------------------------- 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 

--------------------------------------------------------------------- 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