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] XLIFF Variants - Wording in Spec


Hi Christian,

 

You are absolutely right about the wording leading to confusion.

 

Hopefully we will get rid of those 2 schemas when we release XLIFF 2.0. I think that it would be more productive to put our energy into the future version instead of looking back.

 

Best regards,

Rodolfo

--

Rodolfo M. Raya   <rmraya@maxprograms.com>

Maxprograms      http://www.maxprograms.com

 

From: Lieske, Christian [mailto:christian.lieske@sap.com]
Sent: Tuesday, March 29, 2011 11:19 AM
To: xliff@lists.oasis-open.org
Subject: [xliff] XLIFF Variants - Wording in Spec

 

Dear fellow TC members,

 

I just reread the „variants“ section of the spec (see http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#Intro_Flavors) …

 

·      Transitional - Applications that produce older versions of XLIFF may still use deprecated items. Deprecated elements and attributes are allowed. Non-XLIFF items are validated only to ensure they are well-formed. Use this variant to validate XLIFF documents that you read.

xsi:schemaLocation='urn:oasis:names:tc:xliff:document:1.2 xliff-core-1.2-transitional.xsd'

·      Strict - All deprecated elements and attributes are not allowed. Obsolete items from previous versions of XLIFF are deprecated and should not be used when writing new XLIFF documents. In order for XLIFF documents with extensions to validate, the parser MUST find the schema for namespaced elements and attributes, and elements and attributes MUST be valid. Use this variant to validate XLIFF documents that you create.

xsi:schemaLocation='urn:oasis:names:tc:xliff:document:1.2 xliff-core-1.2-strict.xsd'

To me, the wording sounds a bit weird if you look at tools that both read and write XLIFF.

 

From my point of view, these tools (or rather their implementers) could interpret the wording as “When you write, do “strict” even if the input was “transitional”. I guess that not the message we want to convey, since producers who supply transitional XLIFF expect that to get transitional XLIFF back.

 

Example: “prop-group” is deprecated and thus not part of “strict”. Thus, a scenario like the following would be possible/required with the current wording

 

-          Read “prop-group”

-          Write something else (that captures “prop-group”)

 

What’s your view on this?

 

I could imagine to add a clarification for this in the XLIFF 1.2 errata (see http://wiki.oasis-open.org/xliff/XLIFF1.2/Errata).

 

Best regards,

Christian

 



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