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

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.