Hi Bryan,
The skeleton is tool dependent and will always be unless we enforce a common format for skeleton files. In this particular case, allowing a custom namespace is not an obstacle for exchanging localization material.
We need to forbid custom namespaces in areas that affect interoperability. Skeletons don’t affect it very much.
Regards,
Rodolfo
--
Rodolfo M. Raya
Maxprograms http://www.maxprograms.com
From: [mailto:] On Behalf Of Schnabel, Bryan S
Sent: Friday, February 17, 2012 7:03 PM
To:
Subject: [xliff] We cannot remove *all* extensibility and support 1.4
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
