I think the basic answer is that you
don't encode the endian-ness of binary data.
All <bin-unit>s require the mime-type
attribute and this should be sufficient. Our definition for the mime-type
attribute is:
"The
value will depend on each element. A list of preferred values is available
from the MIME specification (http://www.ietf.org/rfc/rfc1341.txt).."
Referring to http://www.ietf.org/rfc/rfc1341.txt
yields the following excerpt which I believe answers the question.
<!--StartFragment-->It should be noted that
email is character-oriented, so that
the mechanisms described
here are mechanisms for encoding
arbitrary byte streams, not bit
streams. If a bit stream is
to be encoded via one of
these mechanisms, it must first be
converted to an 8-bit byte stream
using the network standard
bit order ("big-endian"),
in which the earlier bits in a
stream become the higher-order
bits in a byte. A bit stream
not ending at an 8-bit
boundary must be padded with zeroes.
This document provides a mechanism
for noting the addition
of such padding in the case of
the application Content-Type,
which has a "padding"
parameter.
<!--EndFragment-->
Perhaps we could explicitly state this
in the 1.1 specification.
Regards,
Mark Levins
IBM Software Group,
Dublin Software Laboratory,
Airways Industrial Estate,
Cloghran,
Dublin 17,
Ireland.
Phone: +353 1 704 6676
IBM Tie Line 166676
"Reynolds, Peter"
<>
14/05/2003 08:46
To
"''"
<>
cc
Subject
[xliff] FW: XLIFF <bin-unit>
question
Hi all,
Posted on behalf of Yves.
Peter.
-----------
Hi all,
Here is a very good question from Ram Viswanadha:
> How do I specify the endianess of data encoded in <internal-file>
> element which is a child of <bin-unit>.
>
> The specification does not mention anything about it.
> If endianness is not encoded then, binary data becomes unportable
and
> hence making the XLIFF document unportable.
>
> Best Regards,
We probably should have a solution for this in 1.1. Maybe simply adding
an attribute, or setting the rule that the content of <internal-file>
is
the same endianness as the XLIFF document (not great solution though, an
attribute would be better).
-yves
