Re: RE: [xliff] FW: XLIFF <bin-unit> question

[TONY.JEWTUSHENKO@ORACLE.COM]

Yves and all: 

I assume that a revision to the spec with this note inserted into a revised spec we will not require a review iteration before voting on it.  If anyone disagrees,  please raise a flag.  Otherwise,  as soon as Yves posts the revised spec I'll immediately set up the ballot.

Feel free to object.

Regards,
Tony

---

• From: "Yves Savourel" <ysavourel@translate.com>
• To: xliff@lists.oasis-open.org
• Date: Wed, 14 May 2003 08:51:38 -0600

Thanks for researching this Mark.

We probably should have a note on this in <internal-file>.

-ys

-----Original Message-----
From: Mark Levins [mailto:mark_levins@ie.ibm.com]
Sent: Wed, May 14, 2003 2:43 AM
To: xliff@lists.oasis-open.org
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" <Peter.Reynolds@bowneglobal.ie>

14/05/2003 08:46

To	"'xliff@lists.oasis-open.org'" <xliff@lists.oasis-open.org>
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

---