> container format are called. CMML as a timed text codec has a mime > type of text/cmml. Similarly, the textual representation of Kate > should be text/x-kate.Agree, as both of these are text.> When you encode Kate in Ogg, it would not normally be expected to come > without audio or video. Thus, if it's an audio file, it should be > video/ogg - for a video file it should be video/ogg - and if it's a > random other file (such as Kate encoded inside Ogg without anything > else) it should be application/ogg with the mime type text/x-kate > inside skeleton.So, just to confirm, you reckon it'd be text/x-kate in skeleton for the embedded Kate stream in Ogg, though it is 8 bit binary data and not the text source representation ? If so, I'll post an updated patch soon, but I want to make sure we're on the same thing as, from he link I posted, text means "such [extra] software must not be required in order to get the general idea of the content", which is clearly not the case for kate, as text data is often not even byte aligned (something I've wondered about whether it'd be a good idea to autoalign actually, too late now though), and application is "some other kind of data, typically either uninterpreted binary data or information to be processed by a mail-based application." Of course, this is a layman's reading, so if you confirm text/x-kate would be correct for the binary bitstream, I'll change it so. Cheers
To provide you with a proper answer, I'd have to read what you do to the text data to encode it in binary. Haven't got the time for that right now, sorry. But if it is some binary encoding and not just a gzip-type compression, maybe application/x-kate may indeed be appropriate. This would however mean that some specialised application is required to decode the data. I might spend some time tomorrow to properly understand the situation... but have to get sleep now... Regards, Silvia. On Fri, Mar 28, 2008 at 11:02 PM, ogg.k.ogg.k at googlemail.com <ogg.k.ogg.k at googlemail.com> wrote:> > container format are called. CMML as a timed text codec has a mime > > type of text/cmml. Similarly, the textual representation of Kate > > should be text/x-kate. > > Agree, as both of these are text. > > > > When you encode Kate in Ogg, it would not normally be expected to come > > without audio or video. Thus, if it's an audio file, it should be > > video/ogg - for a video file it should be video/ogg - and if it's a > > random other file (such as Kate encoded inside Ogg without anything > > else) it should be application/ogg with the mime type text/x-kate > > inside skeleton. > > So, just to confirm, you reckon it'd be text/x-kate in skeleton for the > embedded Kate stream in Ogg, though it is 8 bit binary data and not > the text source representation ? > > If so, I'll post an updated patch soon, but I want to make sure we're on > the same thing as, from he link I posted, text means "such [extra] software > must not be required in order to get the general idea of the content", > which is clearly not the case for kate, as text data is often not even byte > aligned (something I've wondered about whether it'd be a good idea to > autoalign actually, too late now though), and application is "some other > kind of data, typically either uninterpreted binary data or information to > be processed by a mail-based application." > > Of course, this is a layman's reading, so if you confirm text/x-kate would > be correct for the binary bitstream, I'll change it so. > > Cheers >
> To provide you with a proper answer, I'd have to read what you do to > the text data to encode it in binary. Haven't got the time for that > right now, sorry. But if it is some binary encoding and not just a > gzip-type compression, maybe application/x-kate may indeed be > appropriate. This would however mean that some specialised application > is required to decode the data.In a nutshell, all data is stuffed into an oggpack_buffer. Text data often ends up non byte aligned. A packet's data is unrecognizable as text (and contains a fair amount of non-text data anyway). A specialized program is indeed required (something linking against the libkate API, which does the oggpack stuff). Interesting point about gzip however, I'd have thought gzipped text would use something like application/gzip rather than text/gzip, though I suppose it does make sense to allow programs to auto apply gzip -dc filters and get at the text.> I might spend some time tomorrow to properly understand the > situation... but have to get sleep now...Sure, didn't mean to take up your time, sorry. Cheers
On 3/28/08, Silvia Pfeiffer <silviapfeiffer1 at gmail.com> wrote:> But if it is some binary encoding and not just a > gzip-type compression, maybe application/x-kate may indeed be > appropriate. This would however mean that some specialised application > is required to decode the data.This assumption is correct and, in my understanding of Kate, it does require a "specialised application" (i.e. Ogg parser able to read Kate bitstreams) to deal with it. So, though it was I who brought the issue up, I now think application/x-kate is the correct solution. -Ivo