microsoft / XLIFF2-Object-Model

If you’re looking to store localization data and propagate it through your localization pipeline allowing tools to interoperate then you may want to use the XLIFF 2.0 object model. The XLIFF 2.0 object model implements the OASIS Standard for the XLIFF 2.0 specification as defined at http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html.
Other
86 stars 25 forks source link

Unit has at least one <segment> or <ignorable> #31

Closed MaximBrain closed 5 years ago

MaximBrain commented 5 years ago

Hi. I just started using this lib and found one strange exception that doesn't correspond with the documentation http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html.

Unit tag has "at least one of ( OR )"? As a result, I get an exception with the following type of xlif file:

------------------------------------------
<unit id="Product">
    <ignorable>
        <source>Product Source</source>
    </ignorable>
</unit>
------------------------------------------

I can fix this issue, and deliver code. Are you okay with this?

simonech commented 5 years ago

Hi, Could you be more specific, pls? Provide an example of which xliff file you are trying to create? Code that raise the exception and exactly which part of the standard it is not implemented correctly? Also, please verify with the xliff schematron validation that the xliff file you are creating is valid. Thx

Sent from my iPhone

On 19 May 2019, at 07:52, Maksym notifications@github.com wrote:

Hi. I just started using this lib and found one strange exception that doesn't correspond with the documentation http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html.

Unit tag has "at least one of ( OR )"? As a result, I get an exception with the following type of xlif file: ...................................

Ignorable source

..........................................

I can fix this issue, and deliver code. Are you okay with this?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

MaximBrain commented 5 years ago

Hi, Thanks for the quick response

  1. There is example with all xliff tree:

    <?xml version="1.0" encoding="UTF-8"?>
    <xliff xmlns="urn:oasis:names:tc:xliff:document:2.0" version="2.0" srcLang="en-US" trgLang="sv-SE">
    <file id="SomeID">
        <group id="_system">
            <unit id="Unit1">
                <ignorable>
                    <source>3213</source>
                </ignorable>
            </unit>

    In this case, we get exception with the following error message: "The element must contain one or more Segment"

  2. In "4.2.1 Tree Structure" paragraph in http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html documentation, the Standard says that "Unit can have at least one of (segment OR ignorable)"

Same you can find in 4.2.2.5 unit paragraph - "One or more segment or ignorable elements in any order."

  1. The following place throws the exception: "StandardValidator.cs file, 4186 line"

And the problem is in the same file with 4126 line: hasSegment |= container is Segment; We can rename this variable to hadChildren and refactor code with the following example:

hadChildren = unit.Resources.Count > 0
simonech commented 5 years ago

I've tried your xliff file on another XLIFF 2.0 validator and it also fails.

https://okapi-lynx.appspot.com/validation

So maybe it's a bug also in there, or maybe there is either an error in the validation schema of the specs, or in the text of the specs themselves.

Maybe @DavidFatDavidF can shad some light

On Mon, May 20, 2019 at 1:29 PM Maksym notifications@github.com wrote:

Hi, Thanks for the quick response

  1. There is example with all xliff tree:

<?xml version="1.0" encoding="UTF-8"?>

3213 In this case, we get exception with the following error message: "The element must contain one or more Segment" 1. In "4.2.1 Tree Structure" paragraph in http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html documentation, the Standard says that "Unit can have at least one of (segment OR ignorable)" Same you can find in 4.2.2.5 unit paragraph - "One or more segment or ignorable elements in any order." 1. The following place throws the exception: "StandardValidator.cs file, 4186 line" And the problem is in the same file with 4126 line: hasSegment |= container is Segment; We can rename this variable to hadChildren and refactor code with the following example: hadChildren = unit.Resources.Count > 0 — You are receiving this because you commented. Reply to this email directly, view it on GitHub , or mute the thread .

-- Simone Chiaretta Microsoft MVP ASP.NET - ASPInsider Blog: http://codeclimber.net.nz RSS: http://feeds2.feedburner.com/codeclimber twitter: @simonech

simonech commented 5 years ago

@MaximBrain just double checked. If you read carefully, there is a constraint:

A <unit> MUST contain at least one <segment> element.

http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#unit

So, validation from this library is correct.

DavidFatDavidF commented 5 years ago

Hi @MaximBrain, @simonech

This library, Okapi Lynx, and XLIFF Core Schematrons all correctly catch this as invalid. http://docs.oasis-open.org/xliff/xliff-core/v2.1/xliff-core-v2.1.html#unit http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#unit In general the spec first describes the grammar as expressible in W3C Schema and then gives any additional business logic constraints or requirements under Constraints or Processing Requirements (depending on whether they are static or dynamic): Under unit it says explicitly:

Constraints A <unit> MUST contain at least one <segment> element.

simonech commented 5 years ago

Thx @DavidFatDavidF for the explanation

too bad we cannot close the issue 😄

MaximBrain commented 5 years ago

Hi,

Strange, documentation has different explained behavior Anyway, thanks for the explanation I'll close this issue

simonech commented 5 years ago

Thx

Sent from my iPhone

On 20 May 2019, at 15:05, Maksym notifications@github.com wrote:

Hi,

Strange, documentation has different explained behavior Anyway, thanks for the explanation I'll close this issue

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.