OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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" attribute and probably some other attributes too. 

Regards,
Rodolfo
--
Rodolfo M. Raya <rmraya@maxprograms.com>
Maxprograms http://www.maxprograms.com

-------- Original Message --------
Subject: RE: [xliff] Another spec question - processing requirements for
state attribute
From: "Rodolfo M. Raya" <rmraya@maxprograms.com>
Date: Thu, April 07, 2022 2:44 pm
To: <xliff@lists.oasis-open.org>


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 <rmraya@maxprograms.com>
Maxprograms http://www.maxprograms.com

-------- Original Message --------
Subject: RE: [xliff] Another spec question - processing requirements for
state attribute
From: Yoshito Umaoka <yoshito_umaoka@us.ibm.com>
Date: Thu, April 07, 2022 2:05 pm
To: "Rodolfo M. Raya" <rmraya@maxprograms.com>,
"xliff@lists.oasis-open.org" <xliff@lists.oasis-open.org>

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: <xliff@lists.oasis-open.org> on behalf of "Rodolfo M. Raya" <rmraya@maxprograms.com>
Date: Thursday, April 7, 2022 at 7:06 AM
To: "xliff@lists.oasis-open.org" <xliff@lists.oasis-open.org>
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 <yoshito_umaoka@us.ibm.com>
Date: Thu, April 07, 2022 2:10 am
To: "Rodolfo M. Raya" <rmraya@maxprograms.com>,
"xliff@lists.oasis-open.org" <xliff@lists.oasis-open.org>
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: <xliff@lists.oasis-open.org> on behalf of "Rodolfo M. Raya" <rmraya@maxprograms.com>
Date: Wednesday, April 6, 2022 at 8:06 PM
To: "xliff@lists.oasis-open.org" <xliff@lists.oasis-open.org>
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 <yoshito_umaoka@us.ibm.com>
Date: Wed, April 06, 2022 7:04 pm
To: "xliff@lists.oasis-open.org" <xliff@lists.oasis-open.org>



 
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
 
  1. If <segment> does not have <target>, writers must not set state attribute other than "initial". I understand this requirement.
  2. 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]