Re: [xliff] We cannot remove *all* extensibility and support 1.4

[Andrzej Zydron <azydron@xtm-intl.com>]

Title: Email signature standard

Hi Bryan,

A very viable alternative to namespace for embedding a skeleton file is to zip and base64 encode it, thereby removing all potential problems. We have been doing that since the outset for XLIFF 1.2.

Best Regards,

Andrzej Zydroń

---------------------------------------

CTO

XTM International Ltd.

PO Box 2167, Gerrards Cross, SL9 8XF, UK

email: azydron@xtm-intl.com              

Tel: +44 (0)1753 480 467

Mob: +44 (0) 7966 477 181

skype: Zydron

www.xtm-intl.com

 

 

 

 

On 17/02/2012 21:03, Schnabel, Bryan S wrote:

Hello,

 

I've been pondering the issue we discussed regarding eliminating extensibility from XLIFF 2.0 vs. greatly reducing extensibility (in order to better enable interoperability and discourage custom solutions).

 

I've come to the conclusion that we cannot completely remove extensibility, and still support our approved feature, "1.4 Allow XML content in <internal-file> element" (http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking#XLIFF2.0.2BAC8-Feature.2BAC8-InternalFileWithXMLContent.AllowXMLcontentin.3Cinternal-file.3Eelement ).

 

In an email from a long time ago, I mocked up a variety of ways to support this feature (http://lists.oasis-open.org/archives/xliff/200806/msg00005.html ). All of these require namespacing the included XML. I might be overlooking something, but I think if the intent is to embed the source skeleton file, those XML elements (and attributes) will need to be namespaced in.

Bryan Schnabel
Content Management Architect
Phone: 503.627.5282
www.tektronix.com