Re: [xliff] XLIFF 1.0 issues - Binary elements & <internal-file>

[Mark Levins <mark_levins@ie.ibm.com>]

Note to group, I'm breaking my original email into its constituent parts in a bid to simplify the ongoing discussion. As a suggestion for the future, we should maybe limit proposals/suggestions for changes to the 1.0 specification to one per e-mail, lessening the risk of some points being lost and making any future threads easier to follow.

Hi John, Stephen

The CDATA approach fails here since binary data may easily contain the closing characters for a CDATA section within its content thereby invalidating the XLIFF (and XML) document.
Perhaps, the attributes for the 'form' attribute should be defined and fixed by the specification where one of the options would be 'Base64".
I don't really see why an 'original-format' attribute would be needed in the event of an encoding, encoding and decoding would be a round-trip with no option to decode to a different format.

In answer to Stephen's point on the growing size of an XLIFF document if an encoding is used, did we not decide the file size was not really an issue, being the reason that we are using sensible attribute and element names rather than some obfuscated shorter approach?

Regards,
Mark

From Stephen Holmes:

On point 3 - bear in mind that localisatin/language tools that aspire to
be network-based will find base64 encoded content to be monumentally
large to transfer.  Europe, remember, is still predominantly 56K and we
all remember the hassle involved in FedEx'ing CD's to China - business
reality supercedes specification.

From John Reid:

<jr>How does CDATA fail this purpose? I wouldn't want to restrict this
to just Base64; thus, requiring a conversion for both the producer and
any subsequent processor that may be able to handle the original format
without a problem. Additionally, wouldn't we need an attribute such as
'original-format' if we forced your conversion?</jr>


Original point:

3. Binary elements & <internal-file>
This is kind of a big one. At the moment the specification does not
define the form of the content of the <internal-file> element (although there
is an optional 'form' attribute). The problem is see with this is that the
specification allows users place binary data directly as content - this
binary content may contain the reserved XML characters < > etc which
will cause parsers to choke.
The CDATA section approach is also not good enough to provide a
solution.
My suggestion is that the content of the <internal-file> be restricted
to Base64 or at least stated so.
Also, the description in the spec for the <internal-file> element reads
"The <internal-file> element will contain the data for the skeleton
file." which is technically wrong, it may also contain data for an
<bin-source> or <bin-target> element.