Re: [xliff-comment] xliff_core_2.1.sch: canDelete' attribute is set to 'no', but the corresponding element is missing in the sibling target.

Jano, thanks for reporting this XLIFF 2.1 csprd01 issue

I have created the issue in the TC JIRA

https://issues.oasis-open.org/browse/XLIFF-10

Please follow the progress of your issue disposal at the above URL

If you want to agree/disagree with or comment on the resolution, once the TC reaches one, please send another comment to this list quoting the JIRA issue number XLIFF-10

BTW, Yves wanted to record this issue also against Lynx, but I don't think that this is needed as the issue seems rather with the XLIFF 2.1 sch file.

Cheers and thanks again for you feedback to the XLIFF 2.1 1st Public Review Draft

dF

Dr. David Filip
===========

OASIS XLIFF OMOS TC Chair

OASIS XLIFF TC Secretary, Editor, Liaison Officer

Spokes Research Fellow

ADAPT Centre

KDEG, Trinity College Dublin

Mobile: +420-777-218-122

On Tue, Nov 15, 2016 at 11:46 AM, Yves <> wrote:

Thanks Jan,

 

I’ll record the issue and look at it.

 

Cheers,

-yves

 

From: Ján Husarčík [mailto:] 
Sent: Tuesday, November 15, 2016 4:39 AM
To: 
Subject: [xliff-comment] xliff_core_2.1.sch: canDelete' attribute is set to 'no', but the corresponding element is missing in the sibling target.

 

Hello,

a file
<?xml version="1.0" encoding="utf-8"?>
<xliff xmlns:mda="urn:oasis:names:tc:xliff:metadata:2.0" xmlns="urn:oasis:names:tc:xliff:document:2.0" srcLang="en-US" version="2.0" >
    <file id="1">
        <group id="content">
            <unit id="1">
                <segment>
                    <source>some <pc  id="p1"  canDelete="no">sentence</pc></source>
                </segment>
            </unit>
        </group>
    </file>
</xliff>

passes XLIFF2.0 validation using Lynx.

When validated using xliff_core_2.1.sch (https://tools.oasis-open.org/version-control/browse/wsvn/xliff/trunk/xliff-21/schemas/xliff_core_2.1.sch) an error "canDelete' attribute is set to 'no', but the corresponding element is missing in the sibling target." is reported.

Maybe the rule should check whether sibling <target> is defined first.

Regards,

Jan