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] We cannot remove *all* extensibility and support 1.4

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ń



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



Description: Description:




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



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

Twitter RSS Facebook Tektronix Store

Tektronix Logo


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