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:
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
