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


Hi Andrzej,

Hmmm. An interesting approach. Thanks for sharing.

I like your approach, but I still think in order to support "1.4 Allow XML content in <internal-file> element" we will need extensibility in the <internal-file> element.

Thanks,

Bryan
ps. looking forward to seeing you in La Jolla!
________________________________________
From: xliff@lists.oasis-open.org [xliff@lists.oasis-open.org] On Behalf Of Andrzej Zydron [azydron@xtm-intl.com]
Sent: Saturday, February 18, 2012 2:32 AM
To: xliff@lists.oasis-open.org
Subject: Re: [xliff] We cannot remove *all* extensibility and support 1.4

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<mailto:azydron@xtm-intl.com>
Tel: +44 (0)1753 480 467
Mob: +44 (0) 7966 477 181
skype: Zydron
www.xtm-intl.com<http://www.xtm-intl.com/>

[cid:part3.07050608.07040603@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<http://www.tektronix.com/>
[cid:part7.07050408.00030101@xtm-intl.com]<http://www.tek.com/signature/twitter> [cid:part9.01080109.08040408@xtm-intl.com] <http://www.tek.com/signature/rss>  [cid:part11.06020303.06010607@xtm-intl.com] <http://www.tek.com/signature/facebook>  [cid:part13.04070002.05030503@xtm-intl.com] <http://www.tek.com/signature/webstore>
[cid:part15.09040003.01060008@xtm-intl.com]




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