Thanks
for researching this Mark.
We
probably should have a note on this in
<internal-file>.
-ys
-----Original Message-----
From: Mark Levins
[mailto:]
Sent: Wed, May 14, 2003 2:43
AM
To:
Subject: Re: [xliff] FW:
XLIFF <bin-unit> question
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
