OASIS XML Localisation Interchange File Format (XLIFF) TC

Hello Yoshito, Section 4.2.2.12 source says that <source> contains text and may contain other optional stuff.  It does not say that text content is also optional. The specification generally indicates that something is optional when it is optional, but this is not done in a consistent way. This is something that certainly needs review. OpenXLIFF treats empty source elements as error because that would be a a useless element in most cases. Do you have a good use case for an empty <source>? Regards, Rodolfo -- Rodolfo M. Raya Maxprograms http://www.maxprograms.com -------- Original Message -------- Subject: Re: [xliff] Online validation for XLIFF From: Yoshito Umaoka < yoshito_umaoka@us.ibm.com > Date: Wed, January 20, 2021 1:51 pm To: Rodolfo M. Raya < rmraya@maxprograms.com > Cc: xliff@lists.oasis-open.org < xliff@lists.oasis-open.org > Thanks Rodolfo, > The initial implementation for the online XLIFF validator suggested > yesterday by Yoshito is now available at https:// > dev.maxprograms.com/Validation / I played with the online validator a little bit. I found something interesting case. Here is the minimal case illustrating the case I found: === <xliff xmlns = urn:oasis:names:tc:xliff:document:2.0 version = 2.0 srcLang = en > <file id = f1 > <unit id = u1 > <segment id = s1 > <source></source> </segment> </unit> </file> </xliff> === The validator returns an error for this XLIFF file with error message: Reason: Empty <source> element I read XLIFF specification and checks whether empty text in <source> element is really invalid. I could not find such description. Can someone point out why empty <source> element is invalid? -Yoshito

Rodolfo, Thank you for your quick response. > Section "4.2.2.12 source" says that <source> contains text and may > contain other optional stuff.  It does not say that text content is > also optional. > I saw the explanation. It's not really clear to me that "text" here explicitly excludes "empty text". > The specification generally indicates that something is optional > when it is optional, but this is not done in a consistent way. This > is something that certainly needs review. For clarity, for this case, we should probably explicitly specify text must not be empty (length > 0). However, I think it should allow empty value for <source> and <target> for the reason below: > > OpenXLIFF treats empty source elements as error because that would > be a a useless element in most cases. Do you have a good use case > for an empty <source>? > We often see prefix/suffix on UI text might be empty in a language, while non-empty value is used in another language. In our case, we use Okapi XLIFF toolkit and it does not invalidate the case. -Yoshito