[OASIS Issue Tracker] (XLIFF-48) existence of "firstNo" at the start of non-reorderable sequences not checked

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/XLIFF-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=65999#comment-65999 ] 

David Filip commented on XLIFF-48:
----------------------------------

Thanks Soroush, I think that the rule should work differently.

The firstNo of a sequence can be in a different segment (maybe not at the time of Extraction, but can get separated), hence it is not enough to look for the preceding firstNo in the same source elements. WRT checking in target it should be subject to the state conditions as other editing hints (not checked if target doesn't exist, being error rather than warning only when the segment state is final etc.)
In both cases the sequence can start in a different segment, so you need to look within a unit.

WRT firstNo preceded by another firstNo, this is not illegal. It only means that one non-reorderable sequence is preceded by a one member non-reorderable sequence. The first firstNo can then be switched to yes by Modifiers but is not illegal.

In both cases, 1) a sequence staring within another segment and 2) concatenated firstNo values, it may well be that the Extractor did not encode quite what they intended to encode, both would be nevertheless valid states.
Cheers dF

> existence of "firstNo" at the start of non-reorderable sequences not checked
> ----------------------------------------------------------------------------
>
>                 Key: XLIFF-48
>                 URL: https://issues.oasis-open.org/browse/XLIFF-48
>             Project: OASIS XML Localisation Interchange File Format (XLIFF) TC
>          Issue Type: Bug
>          Components: validation artifacts
>    Affects Versions: 2.1_csprd03
>         Environment: http://markmail.org/thread/sbz3myvzpzlfilsf
>            Reporter: David Filip
>            Assignee: Soroush Saadatfar
>            Priority: Blocker
>              Labels: AdoptionBlocker, material, request_tc_discussion, work_required
>             Fix For: 2.1_csprd04
>
>
> the xliff file
> <xliff version='2.0'
>     xmlns='urn:oasis:names:tc:xliff:document:2.0' srcLang="en" trgLang="fr">
>     <file id="f1">
>         <unit id="u1">
>             <segment>
>                 <source><pc id="1" canCopy="no" canDelete="no"
> canReorder="no"><ph id="2" canCopy="no" canDelete="no"/></pc></source>
>             </segment>
>         </unit>
>     </file>
> </xliff>
> is recognized as valid by xliff_core_2.1.sch (rev. 807), event though
> in
> http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd03/xliff-core-v2.1-csprd03.html#canreorder
> says:
> "firstNo when the code is the first element of a sequence that cannot
> be re-ordered, no when it is another element of such a sequence."
> Could you please have a look?



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)