[ogg-dev] The use for an XML based metadata format

[Silvia Pfeiffer]

Hi Daniel.

On 9/10/07, Daniel Aleksandersen <aleksandersen+xiphlists at runbox.com> wrote:
> Yeah, I tried that. I must admit I was much smarter before killing all those
> brain cells trying to understand CMML. But I got a potted version from
> someone one the email list earlier! Think I get the basics from Wikipedia's
> article too.
>
> And responding to all your arguments on CMML: It simply is not good enough.

> * There is no way to extend it. (That would have required a version number
> and name space. According to everything I know about any XML based format.)

That's total crap and tells me that you have not read anything about
it. There is a version number and name space. And also: the format has
not been formally finalised, so there is all potential to change it.

> * The current version is hard to change. (Again because there is no version
> number and name space. Changing the format would break all earlier adoption
> because they could not tell the new and old versions appear.)

Why are you repeating the same wrong argument?

> * Format intended for movies. (At least I have not seen it be very friendly
> towards audio recordings yet)

The very first version that was implemented was for audio only. No,
there is nothing making it specific to video only.

> * Format fails to provide methods for describing resources in any great
> extent. Suffers from same limits/boundaries as Vorbis comment. Though it is
> much better than Vorbis comment, it is not 'thinking big enough'.

Ah, that tells me that you have not understood it at all. It is
lacking any of the sort of detailed specifications for music that you
are proposing - but that was not the point. As I mentioned earlier: it
is focusing on time-continuous annotations, not on the type of
annotations that you are suggesting for music.


> These parent elements (audio, video, text, image, ...) are intended to say
> what kind of media the resource being described is. Another thing of
> creating separate elements for various media types where that it would be
> much easier to create media type specific elements. I just thought of
> images as media resources.I did not know images could not be store in Oggs.

They can, but there is no currently wide adpoted specification of it.;

> > We will need to make it possible to cover at minimum creative commons.
> > How would you suggest doing so?
>
> Simple:
>
> <rights date="2009-04" uri="http://creativecommons.org/licenses/by/4.0/">℗
> 2009 Rights holder. Some Rights reserved.</rights>
>
> Of course the data could be represented as child elements of the parent
> rights element. The idea I had was to make it quite simple. I personally
> believe a much simplified version of the RDF method could prove useful.
> (Please keep in mind that sample description I sent using many different
> name spaces and how cluttered it was.)
> <entities>
> <organisation role="rightsholder" uri="http://somecompany.com/"
> id="somecompany">Some Company</organisation></entities>
> <rights>
> <date>2019-05-03</date>
> <human-readable>℗ 2019 Some Company. Some Rights
> reserved.</human-readable>
> <license uri="http://flf.org/licenses/whiteHouseLawn" /></rights>

Ok, that's looking more complete. :)

> > Yes, these are all good goals. Subtitles are time-continuous textual
> > annotations towards a piece of video/audio, so they should be
> > encapsulated in a time-continuous text codec, which is what CMML is.
> > Thus the suggestion to include this data with CMML - create a new
> > "subtitle" tag.
>
> Well, CMML would be the subtitle. M3F would be the format describing the
> subtitle and the video it is shown below.

Ah! Nice!

> > > I am probably not the right person to lead this. But I am apparently
> > > the only one motivated enough to do it. So if anyone else is unemployed
> > > at the time...do help. Anyone else are free to contribute as well! ;-)
> >
> > There is no such thing as the "right" person. The person who does it
> > and drives it is the "right" person. This is how open source and open
> > communities work. So, you are the right person. :-) Go lead it and
> > help will be given. Just be open to criticism - it's not always
> > negative, but often constructive. You just need to keep an open mind.
>
> Most replies in this emailing list have not been constructive. I
> think 'destructive' would be a better word for it. But I see your point as
> I hope you see mine.

That was your interpretation of the emails, not what they were written to be.


> The right person would be able to read RFCs and understand their gibberish,
> lawyer-like language. (What ever happen to plain English, people?) I am
> talking from experience with the XMPP and various URI RFCs. But I am doing
> the best I can.

Yes, somebody who can read specifications is indeed required to author
new ones. If you don't think you can find the time to learn this,
maybe this exercise is pointless. It is indeed turning into a waste of
my time.

Sorry to be sounding harsh this time, but I've not received much
constructiveness from you.

Regards,
Silvia.