OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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.


Thanks for researching this Mark.
We probably should have a note on this in <internal-file>.
-----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.

Perhaps we could explicitly state this in the 1.1 specification.


Mark Levins
IBM Software Group,
Dublin Software Laboratory,
Airways Industrial Estate,
Dublin 17,
Phone: +353 1 704 6676
IBM Tie Line 166676

"Reynolds, Peter" <Peter.Reynolds@bowneglobal.ie>

14/05/2003 08:46

"'xliff@lists.oasis-open.org'" <xliff@lists.oasis-open.org>
[xliff] FW: XLIFF <bin-unit> question

Hi all,

Posted on behalf of Yves.


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).


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]