--- In rss-media@yahoogroups.com, "rcade" <cadenhead@...> wrote:
>
> --- In rss-media@yahoogroups.com, "stuartjmoore" <stuartjmoore@> wrote:
> > Why is MediaRSS only a namespace enhancement for RSS? Why not create
> > a truly unique format for distributing media?
>
> What advantage would creating a new format bring that couldn't be achieved
with a namespace? Thousands of programs support RSS and Atom. They cover the
basics of transmitting chronological updates to web content pretty well and are
stable.
>

The most important advantage would be to get rid of the RSS name and icon. To
most people, if not all, RSS means blog. The orange waves make sense on Gizmodo,
but look out of place and confusing on sites like Hulu and YouTube. Media feeds
should have an icon and name that screams television and radio.

RSS is meant for "transmitting chronological updates to web content" and that's
the problem. TV isn't web content. Blogs never schedule future updates, but
broadcast programs do.

Why clutter a good format like RSS? Why not build a new format for this new
purpose? One that will include the most basic tags.

 
 

--- In rss-media@yahoogroups.com <mailto:rss-media%40yahoogroups.com> , "sapnach" <sapna@...> wrote:
> Like I mentioned earlier, I don't think anyone at Yahoo! would have
> an issue with this transfer. If this group is in agreement that that
> is their preference, then we can start the process.

Sounds good. I'm drafting a proposal with Ryan Parman, another member of the RSS Advisory Board who is active here on RSS-Media, regarding this possibility. I hope to have it posted today or tomorrow, which will begin a two-week period on our mailing lists [1, 2] where we discuss and vote on the proposal.

Do you have a target date for when Media RSS 1.5 will be finalized and published?

1: http://tech.groups.yahoo.com/group/rss-public
2: http://tech.groups.yahoo.com/group/rss-board

  
    

At 2:25 PM +0530 09/09/11, Sapna Chandiramani wrote:
>
>
>I don't have a date yet, but can have one by next week.
>
>Before we start this process, I would like consensus from this group that
moving this to the RSS Board is indeed what they want.
>
>Let me know if you would like to set up a poll for that, or if someone has a
better idea.
>
>Thanks,
>Sapna

Good god, Jim, just get it moving!

Kudos to your and your team, and everyone here, for getting the momentum going
while still maintaining a grass roots approach.

I see great things in the future with MRSS.

cheers.
--
-----------------------------------------------
Cameron Knowlton
iGods Internet Marketing
cameronk@...
www.igods.com
P: 250.382.0226

--- In rss-media@yahoogroups.com, Sapna Chandiramani <sapna@...> wrote:
> Before we start this process, I would like consensus from this group
> that moving this to the RSS Board is indeed what they want.

The proposal we're drafting for the RSS Advisory Board would be for the move to
occur after the final publication of Media RSS 1.5. So that gives you time to
ensure that the members of rss-media want the move to take place.

Once our proposal is posted, our board will take two weeks to discuss it and
vote on it.

If it turned out that the move wasn't supported here, we could just withdraw our
proposal.

I'm having trouble contacting Ryan Parman and Sapna Chandiramani via email --
apparently I don't have current email addresses for either of you.

If you could contact me via the form here ...

http://workbench.cadenhead.org/email

... I'll send you the draft of the proposal.

Hello all,

mRSS-1.5.0 has been published and is available at
http://video.search.yahoo.com/mrss .

The previous version (mRSS-1.1.2) has been archived at :
http://tech.groups.yahoo.com/group/rss-media/files/mrss-1.1.2 .

On behalf of Yahoo! , we would like to thank rss-media for all the
feedback and suggestions for mRSS-1.5.0.

Thanks,
Nilesh Gattani
(Engineer - Yahoo! multimedia Search)

i just launched a new video site for a client of mine and submitted a new mrss
feed to yahoo.

noticed you guys switched up the whole interface and added an email
notification.

just wanted to say thanks!

makes things a bit easier for those of us on this end of things ;)

caio.

I've been going through the 1.5.0 updates at http://video.search.yahoo.com/mrss,
and I see a few issues.

- you don't need a <community> tag; that's a container that serves no purpose. 
just move all the sub-tags up one level.
- community data needs to have element of time; e.g., was this the rating for
the last hour?  the last day?  the last week?  all time?  consider a "period"
attribute that takes a duration from the current time, e.g., "period=1:00", and
assume if it's missing that it's for all time.
- by assuming <starRating>, you can't capture thumbs up/thumbs down, or
"recommended" counts.  consider renaming this to simply <userRating>
- having the contents of <tags> be random string format is arbitrary.  it's
structured data, so use structure.  have a series of <media:tag>A</media:tag>
attributes, and allow a <media:tag weight="3"> attribute if necessary.
- you don't need a <comments> container (you don't have one for <thumbnail>, for
example).  just have <comment> tags.
- the <comment> tag is inadequate.  You should have attributes for "user",
"date", "replyTo" (in combination with an "id"), etc.  It's hard to see the
usefulness of a batch of undated, unattributed comments.
- an example of an <embed> tag isn't a spec; you need to say what attributes are
allowed, and which are reserved vs. free-form
- you don't need the <responses> container
- how is a <response> different from a <comment>?  can you combine these into a
single tag, with a "replyTo" attribute, or a "isResponse' flag?
- you don't need the <backLinks> container
- <backLink> is insufficient for anyone trying to render UI.  You need to at
least allow for a "title" attribute on the tag.
- for the attribute tag in "reason", if you expect this to be machine-processed,
you can't have it either be a URL or text.  you should separate this out into
"message" and "url" attributes, so a processor doesn't have to guess
- with <price> you got it right; you didn't add a <prices> container.  yay!
- you don't need the <scenes> container
- <scene> is too verbose, and doesn't look like <content> or <thumbnail>.  I'd
recommend changing this to <scene title="sceneTitle2" description="sceneDesc2"
startTime="0:57" endTime="1:45"/>
- note that part of supporting NTP is interpreting a value like "105" as 105
seconds; it would be good if you had an example of this in your spec, because as
an MRSS generator, it's always easier to spit out seconds for these values
- it's super common that people want thumbnails attached to scenes.  consider a
"thumbnailUrl" attribute that could be used as a hover-over
- for the <scene> tag, you say all the sub-elements are optional... but that
can't be the case.  at the least, you should require "startTime".
- in general, the 1.5.0 additions seem underspecified.  which attributes are
required?  which attributes are optional?  it sounds like the <media:peerLink>
can be used in place of <media:content>... but can you use the other attributes
on it (e.g., "medium", "bitrate", etc.?)  If you can, how to deal with the
ambiguity of the true type of the file ("video/x-wmv") vs. the bittorrent
wrapper ("application/x-bittorrent").  It seems if you actually threw some devs
at this spec, they'd tear it apart.

 
 

I've been going through the 1.5.0 updates at http://video.search.yahoo.com/mrss, and I see a few issues.

- you don't need a <community> tag; that's a container that serves no purpose.  just move all the sub-tags up one level.
- community data needs to have element of time; e.g., was this the rating for the last hour?  the last day?  the last week?  all time?  consider a "period" attribute that takes a duration from the current time, e.g., "period=1:00", and assume if it's missing that it's for all time.
- by assuming <starRating>, you can't capture thumbs up/thumbs down, or "recommended" counts.  consider renaming this to simply <userRating>
- having the contents of <tags> be random string format is arbitrary.  it's structured data, so use structure.  have a series of <media:tag>A</media:tag> attributes, and allow a <media:tag weight="3"> attribute if necessary.
- you don't need a <comments> container (you don't have one for <thumbnail>, for example).  just have <comment> tags.
- the <comment> tag is inadequate.  You should have attributes for "user", "date", "replyTo" (in combination with an "id"), etc.  It's hard to see the usefulness of a batch of undated, unattributed comments.
- an example of an <embed> tag isn't a spec; you need to say what attributes are allowed, and which are reserved vs. free-form
- you don't need the <responses> container
- how is a <response> different from a <comment>?  can you combine these into a single tag, with a "replyTo" attribute, or a "isResponse' flag?
- you don't need the <backLinks> container
- <backLink> is insufficient for anyone trying to render UI.  You need to at least allow for a "title" attribute on the tag.
- for the attribute tag in "reason", if you expect this to be machine-processed, you can't have it either be a URL or text.  you should separate this out into "message" and "url" attributes, so a processor doesn't have to guess
- with <price> you got it right; you didn't add a <prices> container.  yay!
- you don't need the <scenes> container
- <scene> is too verbose, and doesn't look like <content> or <thumbnail>.  I'd recommend changing this to <scene title="sceneTitle2" description="sceneDesc2" startTime="0:57" endTime="1:45"/>
- note that part of supporting NTP is interpreting a value like "105" as 105 seconds; it would be good if you had an example of this in your spec, because as an MRSS generator, it's always easier to spit out seconds for these values
- it's super common that people want thumbnails attached to scenes.  consider a "thumbnailUrl" attribute that could be used as a hover-over
- for the <scene> tag, you say all the sub-elements are optional... but that can't be the case.  at the least, you should require "startTime".
- in general, the 1.5.0 additions seem underspecified.  which attributes are required?  which attributes are optional?  it sounds like the <media:peerLink> can be used in place of <media:content>... but can you use the other attributes on it (e.g., "medium", "bitrate", etc.?)  If you can, how to deal with the ambiguity of the true type of the file ("video/x-wmv") vs. the bittorrent wrapper ("application/x-bittorrent").  It seems if you actually threw some devs at this spec, they'd tear it apart.

  
    

I understand that it's published, but that doesn't mean anyone has adopted it. 
You still have time to fix this.

You posted the proposal just a few weeks ago, and didn't get a single public
comment or critique from anyone on this group, other that people wishing a
standards body would take it up.  That doesn't meet the bar for a public
standard.

I'm worried you've effectively killed forward progress on MRSS with these
extensions.  No one is going to adopt the 1.5 additions outside of Yahoo,
they're underspecified and syntactically defective, and now we're stuck; nobody
can move forward with a 1.6, because they've got the albatross of 1.5.

Anyway, it's your option to propose a standard that people won't use.  I truly
wish these improvements were better; a <scene> or <chapter> tag is something
we've wanted for a long time, but what's there now is a bloated mess.  My team
won't the 1.5 extensions in their current state; they do violence to the
original spirit of media RSS, which were some light, well-thought-out,
well-reviewed, consistent extensions.

So, please reconsider reopening the 1.5 discussion.

--- In rss-media@yahoogroups.com, Sapna Chandiramani <sapna@...> wrote:
>
> Thanks for your comments.
> Given that the v1.5 spec is already published, we can possibly consider these
in the next revision.
> Nilesh is on vacation this week, and will respond to your comments when he
returns.
>
> Thanks,
> Sapna
>
>
>
>
> On 10/20/09 12:10 PM, "scrungus" <alan.ramaley@...> wrote:
>
>
>
>
>
> I've been going through the 1.5.0 updates at
http://video.search.yahoo.com/mrss, and I see a few issues.
>
> - you don't need a <community> tag; that's a container that serves no purpose.
just move all the sub-tags up one level.
> - community data needs to have element of time; e.g., was this the rating for
the last hour?  the last day?  the last week?  all time?  consider a "period"
attribute that takes a duration from the current time, e.g., "period=1:00", and
assume if it's missing that it's for all time.
> - by assuming <starRating>, you can't capture thumbs up/thumbs down, or
"recommended" counts.  consider renaming this to simply <userRating>
> - having the contents of <tags> be random string format is arbitrary.  it's
structured data, so use structure.  have a series of <media:tag>A</media:tag>
attributes, and allow a <media:tag weight="3"> attribute if necessary.
> - you don't need a <comments> container (you don't have one for <thumbnail>,
for example).  just have <comment> tags.
> - the <comment> tag is inadequate.  You should have attributes for "user",
"date", "replyTo" (in combination with an "id"), etc.  It's hard to see the
usefulness of a batch of undated, unattributed comments.
> - an example of an <embed> tag isn't a spec; you need to say what attributes
are allowed, and which are reserved vs. free-form
> - you don't need the <responses> container
> - how is a <response> different from a <comment>?  can you combine these into
a single tag, with a "replyTo" attribute, or a "isResponse' flag?
> - you don't need the <backLinks> container
> - <backLink> is insufficient for anyone trying to render UI.  You need to at
least allow for a "title" attribute on the tag.
> - for the attribute tag in "reason", if you expect this to be
machine-processed, you can't have it either be a URL or text.  you should
separate this out into "message" and "url" attributes, so a processor doesn't
have to guess
> - with <price> you got it right; you didn't add a <prices> container.  yay!
> - you don't need the <scenes> container
> - <scene> is too verbose, and doesn't look like <content> or <thumbnail>.  I'd
recommend changing this to <scene title="sceneTitle2" description="sceneDesc2"
startTime="0:57" endTime="1:45"/>
> - note that part of supporting NTP is interpreting a value like "105" as 105
seconds; it would be good if you had an example of this in your spec, because as
an MRSS generator, it's always easier to spit out seconds for these values
> - it's super common that people want thumbnails attached to scenes.  consider
a "thumbnailUrl" attribute that could be used as a hover-over
> - for the <scene> tag, you say all the sub-elements are optional... but that
can't be the case.  at the least, you should require "startTime".
> - in general, the 1.5.0 additions seem underspecified.  which attributes are
required?  which attributes are optional?  it sounds like the <media:peerLink>
can be used in place of <media:content>... but can you use the other attributes
on it (e.g., "medium", "bitrate", etc.?)  If you can, how to deal with the
ambiguity of the true type of the file ("video/x-wmv") vs. the bittorrent
wrapper ("application/x-bittorrent").  It seems if you actually threw some devs
at this spec, they'd tear it apart.
>

 
 

I understand that it's published, but that doesn't mean anyone has adopted it.  You still have time to fix this.

You posted the proposal just a few weeks ago, and didn't get a single public comment or critique from anyone on this group, other that people wishing a standards body would take it up.  That doesn't meet the bar for a public standard.

I'm worried you've effectively killed forward progress on MRSS with these extensions.  No one is going to adopt the 1.5 additions outside of Yahoo, they're underspecified and syntactically defective, and now we're stuck; nobody can move forward with a 1.6, because they've got the albatross of 1.5.

Anyway, it's your option to propose a standard that people won't use.  I truly wish these improvements were better; a <scene> or <chapter> tag is something we've wanted for a long time, but what's there now is a bloated mess.  My team won't the 1.5 extensions in their current state; they do violence to the original spirit of media RSS, which were some light, well-thought-out, well-reviewed, consistent extensions.

So, please reconsider reopening the 1.5 discussion.

--- In rss-media@yahoogroups.com <mailto:rss-media%40yahoogroups.com> , Sapna Chandiramani <sapna@...> wrote:
>
> Thanks for your comments.
> Given that the v1.5 spec is already published, we can possibly consider these in the next revision.
> Nilesh is on vacation this week, and will respond to your comments when he returns.
>
> Thanks,
> Sapna
>
>
>
>
> On 10/20/09 12:10 PM, "scrungus" <alan.ramaley@...> wrote:
>
>
>
>
>
> I've been going through the 1.5.0 updates at http://video.search.yahoo.com/mrss, and I see a few issues.
>
> - you don't need a <community> tag; that's a container that serves no purpose.  just move all the sub-tags up one level.
> - community data needs to have element of time; e.g., was this the rating for the last hour?  the last day?  the last week?  all time?  consider a "period" attribute that takes a duration from the current time, e.g., "period=1:00", and assume if it's missing that it's for all time.
> - by assuming <starRating>, you can't capture thumbs up/thumbs down, or "recommended" counts.  consider renaming this to simply <userRating>
> - having the contents of <tags> be random string format is arbitrary.  it's structured data, so use structure.  have a series of <media:tag>A</media:tag> attributes, and allow a <media:tag weight="3"> attribute if necessary.
> - you don't need a <comments> container (you don't have one for <thumbnail>, for example).  just have <comment> tags.
> - the <comment> tag is inadequate.  You should have attributes for "user", "date", "replyTo" (in combination with an "id"), etc.  It's hard to see the usefulness of a batch of undated, unattributed comments.
> - an example of an <embed> tag isn't a spec; you need to say what attributes are allowed, and which are reserved vs. free-form
> - you don't need the <responses> container
> - how is a <response> different from a <comment>?  can you combine these into a single tag, with a "replyTo" attribute, or a "isResponse' flag?
> - you don't need the <backLinks> container
> - <backLink> is insufficient for anyone trying to render UI.  You need to at least allow for a "title" attribute on the tag.
> - for the attribute tag in "reason", if you expect this to be machine-processed, you can't have it either be a URL or text.  you should separate this out into "message" and "url" attributes, so a processor doesn't have to guess
> - with <price> you got it right; you didn't add a <prices> container.  yay!
> - you don't need the <scenes> container
> - <scene> is too verbose, and doesn't look like <content> or <thumbnail>.  I'd recommend changing this to <scene title="sceneTitle2" description="sceneDesc2" startTime="0:57" endTime="1:45"/>
> - note that part of supporting NTP is interpreting a value like "105" as 105 seconds; it would be good if you had an example of this in your spec, because as an MRSS generator, it's always easier to spit out seconds for these values
> - it's super common that people want thumbnails attached to scenes.  consider a "thumbnailUrl" attribute that could be used as a hover-over
> - for the <scene> tag, you say all the sub-elements are optional... but that can't be the case.  at the least, you should require "startTime".
> - in general, the 1.5.0 additions seem underspecified.  which attributes are required?  which attributes are optional?  it sounds like the <media:peerLink> can be used in place of <media:content>... but can you use the other attributes on it (e.g., "medium", "bitrate", etc.?)  If you can, how to deal with the ambiguity of the true type of the file ("video/x-wmv") vs. the bittorrent wrapper ("application/x-bittorrent").  It seems if you actually threw some devs at this spec, they'd tear it apart.
>

  
    

Here's an example that crystallizes the issue.

In the MRSS 1.1.2 spec, here's how you specify multiple thumbnails:

     <media:thumbnail url="http://www.foo.com/keyframe1.jpg" width="100"
height="75" time="12:05:01.123" />
     <media:thumbnail url="http://www.foo.com/keyframe2.jpg" width="100"
height="75" time="24:19:00.456" />

In the MRSS 1.5.0 spec, here's how you specify multiple scenes:

     <media:scenes>
         <media:scene>
             <sceneTitle>sceneTitle1</sceneTitle>
             <sceneDescription>sceneDesc1</sceneDescription>
             <sceneStartTime>00:15</sceneStartTime>
             <sceneEndTime>00:45</sceneEndTime>
         </media:scene>
         <media:scene>
             <sceneTitle>sceneTitle2</sceneTitle>
             <sceneDescription>sceneDesc2</sceneDescription>
             <sceneStartTime>00:57</sceneStartTime>
             <sceneEndTime>01:45</sceneEndTime>
         </media:scene>
     </media:scenes>

Do you see how these are inconsistent approaches?  You don't need to have any
domain knowledge to see that they're arbitrarily and unnecessarily different.

Instead, you should have done multiple scenes like this:

     <media:scene title="sceneTitle1" description="sceneDesc1" startTime="0:15"
endTime="0:45" />
     <media:scene title="sceneTitle2" description="sceneDesc2" startTime="0:57"
endTime="1:45" />

Alternately, if you wanted to keep the plain/html text distinction for the
strings, you would have done this:

     <media:scene startTime="0:15" endTime="0:45" />
         <media:title type="plain">sceneTitle1</media:title>
         <media:description type="plain">sceneDesc1</media:description>
     </media:scene>
     <media:scene startTime="0:57" endTime="1:45" />
         <media:title type="plain">sceneTitle2</media:title>
         <media:description type="plain">sceneDesc2</media:description>
     </media:scene>

Either of these would have been consistent with the 1.1.2 spec.  No matter what,
you shouldn't have done that <media:scenes> container. It's not analogous to
<media:group>; <media:group> serves as a scoping mechanism for giving a group of
<media:content> nodes the same metadata like title, author, etc.  There's no
similar need with scenes.

The spec is littered with serialization inconsistency errors like this.  The
existing MRSS extensions provide a clear template.  There are always boring
arguments when any XML format starts up about whether to use camel-case or
title-case or separated-by-dash names, whether to emphasize attributes or
elements, the case rules for enums, etc.  But those arguments have already
happened for MRSS.

It would have been nice if someone in the group had brought up these issues
earlier.  I only rejoined when I noticed the change in the published spec.  I
don't know why other people who were in the group didn't have the same reaction
to the draft.  Maybe all of the original issues in this thread have sound
counter-arguments, and I'm out in left field here; more likely, I think people
are tuned out or have already privately dismissed this effort.

But I'm hopeful that we can have a discussion that's less about process and
bandwidth and stewardship, all things that won't matter one whit to anybody in 5
years, and more about getting the design right, which will.

--- In rss-media@yahoogroups.com, Sapna Chandiramani <sapna@...> wrote:
>
> The spec was sent out for review to this group on August 7th 2009. There were
some comments from this group which have been incorporated. There was some
comments from other companies (where the spec was circulated) and those were
incorporated as well.
>
> The spec was finally published on September 30th 2009, after reminders to this
group to send in any further comments. There were no requests asking us to
extend the timeline.
>
> You have chosen to respond on October 23rd 2009 :-)
>
> I'm afraid my team does not have the bandwidth to make any further revisions
at this time. You are welcome to make comments on the spec that can be discussed
in this group. We are currently in the process to move this over to the RSS
advisory board. We do not plan to make any revisions to the spec until decisions
are made on that front.
>
> -Sapna
>
>
>
> On 10/23/09 10:18 PM, "scrungus" <alan.ramaley@...> wrote:
>
>
>
>
>
> I understand that it's published, but that doesn't mean anyone has adopted it.
You still have time to fix this.
>
> You posted the proposal just a few weeks ago, and didn't get a single public
comment or critique from anyone on this group, other that people wishing a
standards body would take it up.  That doesn't meet the bar for a public
standard.
>
> I'm worried you've effectively killed forward progress on MRSS with these
extensions.  No one is going to adopt the 1.5 additions outside of Yahoo,
they're underspecified and syntactically defective, and now we're stuck; nobody
can move forward with a 1.6, because they've got the albatross of 1.5.
>
> Anyway, it's your option to propose a standard that people won't use.  I truly
wish these improvements were better; a <scene> or <chapter> tag is something
we've wanted for a long time, but what's there now is a bloated mess.  My team
won't the 1.5 extensions in their current state; they do violence to the
original spirit of media RSS, which were some light, well-thought-out,
well-reviewed, consistent extensions.
>
> So, please reconsider reopening the 1.5 discussion.
>
> --- In rss-media@yahoogroups.com <mailto:rss-media%40yahoogroups.com> , Sapna
Chandiramani <sapna@> wrote:
> >
> > Thanks for your comments.
> > Given that the v1.5 spec is already published, we can possibly consider
these in the next revision.
> > Nilesh is on vacation this week, and will respond to your comments when he
returns.
> >
> > Thanks,
> > Sapna
> >
> >
> >
> >
> > On 10/20/09 12:10 PM, "scrungus" <alan.ramaley@> wrote:
> >
> >
> >
> >
> >
> > I've been going through the 1.5.0 updates at
http://video.search.yahoo.com/mrss, and I see a few issues.
> >
> > - you don't need a <community> tag; that's a container that serves no
purpose.  just move all the sub-tags up one level.
> > - community data needs to have element of time; e.g., was this the rating
for the last hour?  the last day?  the last week?  all time?  consider a
"period" attribute that takes a duration from the current time, e.g.,
"period=1:00", and assume if it's missing that it's for all time.
> > - by assuming <starRating>, you can't capture thumbs up/thumbs down, or
"recommended" counts.  consider renaming this to simply <userRating>
> > - having the contents of <tags> be random string format is arbitrary.  it's
structured data, so use structure.  have a series of <media:tag>A</media:tag>
attributes, and allow a <media:tag weight="3"> attribute if necessary.
> > - you don't need a <comments> container (you don't have one for <thumbnail>,
for example).  just have <comment> tags.
> > - the <comment> tag is inadequate.  You should have attributes for "user",
"date", "replyTo" (in combination with an "id"), etc.  It's hard to see the
usefulness of a batch of undated, unattributed comments.
> > - an example of an <embed> tag isn't a spec; you need to say what attributes
are allowed, and which are reserved vs. free-form
> > - you don't need the <responses> container
> > - how is a <response> different from a <comment>?  can you combine these
into a single tag, with a "replyTo" attribute, or a "isResponse' flag?
> > - you don't need the <backLinks> container
> > - <backLink> is insufficient for anyone trying to render UI.  You need to at
least allow for a "title" attribute on the tag.
> > - for the attribute tag in "reason", if you expect this to be
machine-processed, you can't have it either be a URL or text.  you should
separate this out into "message" and "url" attributes, so a processor doesn't
have to guess
> > - with <price> you got it right; you didn't add a <prices> container.  yay!
> > - you don't need the <scenes> container
> > - <scene> is too verbose, and doesn't look like <content> or <thumbnail>. 
I'd recommend changing this to <scene title="sceneTitle2"
description="sceneDesc2" startTime="0:57" endTime="1:45"/>
> > - note that part of supporting NTP is interpreting a value like "105" as 105
seconds; it would be good if you had an example of this in your spec, because as
an MRSS generator, it's always easier to spit out seconds for these values
> > - it's super common that people want thumbnails attached to scenes. 
consider a "thumbnailUrl" attribute that could be used as a hover-over
> > - for the <scene> tag, you say all the sub-elements are optional... but that
can't be the case.  at the least, you should require "startTime".
> > - in general, the 1.5.0 additions seem underspecified.  which attributes are
required?  which attributes are optional?  it sounds like the <media:peerLink>
can be used in place of <media:content>... but can you use the other attributes
on it (e.g., "medium", "bitrate", etc.?)  If you can, how to deal with the
ambiguity of the true type of the file ("video/x-wmv") vs. the bittorrent
wrapper ("application/x-bittorrent").  It seems if you actually threw some devs
at this spec, they'd tear it apart.
> >
>

* rant *
How you can seriously call this a specification without an official xsd is
unbelievable.
How can you possibly expect this to be used for serious applications if there is
no xsd/schema to validate against ?

I could go on...

The RSS Advisory Board has voted 8-0 to become the custodian of the Media RSS
specification:

http://www.rssboard.org/media-rss

The above link is a draft copy of the current version of the spec that still
requires some proofreading. Your help would be appreciated.

The namespace declaration will remain http://search.yahoo.com/mrss/ even though
the board is now publishing the spec.

While I was preparing the document, I fixed some typos, HTML markup errors and
two examples that did not follow the spec. I also added the geoRSS namespace
declaration to the last example.

The specification now has a Table of Contents and internal links to each
element, making it easier to refer to them here on RSS-Media and elsewhere:

http://www.rssboard.org/media-rss#table-of-contents

One thing I could not fix involves this line in the Change Notes:

"Modified ????? to have a URL attribute for better module consistency."

I can't find an older version of the spec that indicates which element was
modified to add a URL attribute.

On behalf of the board, I'd like to thank Sapna Chandiramani and the other
members of Yahoo who have worked on the spec for the past five years.

One thing that is not moving is RSS-Media. This will still be the place to ask
questions, offer feedback and discuss implementations of the namespace.

Congratulations!

Regarding the "???" in the change notes: I went and looked at the original 1.0.0
file and had this:

"Modified <media:thumbnail> to have a url attribute for better module
consistency."

That element name was inadvertently deleted in 1.1.1 release.

--- In rss-media@yahoogroups.com, "David" <daviddhall@...> wrote:
> Congratulations!

Thanks. I'm looking forward to digging further into this. The first thing I'd
like to do is make sure the Feed Validator can validate all of the Media RSS
elements.

> "Modified <media:thumbnail> to have a url attribute for better module
consistency."

Fixed. Where did you find a copy of the 1.0.0 specification?

When i write this:
$xml =
file_get_contents('http://api.5min.com/search/how%20to%20make%20a%20chocolate%20\
cake/videos.xml');

and later i print this $xml variable, i view page-source and see the media tag.

but i want the xml to get info out of media tag, so i used this function below:

$mine = simplexml_load_string($xml);

but it completely skips media tag. can anyone plz help? how can i get media tag?

Hi,

We feel the need to add a GUID attribute to media:content, to define the
uniqueness of a media file. The ability to set a GUID would make it easier to
use MRSS as syndication method for web applications. The rest of the
specification is already perfect for this end.

The GUID-element of the RSS spec itself only allows for one guid per item and
not per file. The <media:hash> element could be used for this, but in theory
there is a slight difference between checking for file consistency and defining
uniqueness.

My suggestion is the addition of an optional "guid"-attribute to the
<media:content> tag. This guid can be either a permalink or just a random unique
hex-hash to define uniqueness of the file. Essentially the use is exactly the
same as that of the guid-element in the RSS 2.0 spec.

The guid-attribute could also be added as an optional attribute to
media:subtitle for the same reason: defining uniqueness of an external file.

Please let me know what you think.

With kind regards,
Ruud

--- In rss-media@yahoogroups.com, "ruudvdl" <ruudvdl@...> wrote:
> We feel the need to add a GUID attribute to media:content, to define the
uniqueness of a media file. The ability to set a GUID would make it easier to
use MRSS as syndication method for web applications. The rest of the
specification is already perfect for this end.

A couple of questions so I can understand your idea better:

1. Why do you need more than one media:content object per item?

2. Isn't the URL attribute of each media:content object already unique?

basically i have a site like friendsfeed.com and for each feed it can have
multiple images or media, cause its group by media type.. anyway thats different
story. i want to know, how can i group multiple media in one item?

ex:
feed id: 43344
feed text: these are all my new photos and i have updated my feed
feed media:
     thumbnail1 content1
     thumbnail2 content2
     thumbnail3 content3
     thumbnail4 content4

--- In rss-media@yahoogroups.com, "Rogers" <cadenhead@...> wrote:

> A couple of questions so I can understand your idea better:
>
> 1. Why do you need more than one media:content object per item?
>
> 2. Isn't the URL attribute of each media:content object already unique?
>



--- In rss-media@yahoogroups.com, "Rogers" <cadenhead@...> wrote:
>
>
>
> --- In rss-media@yahoogroups.com, "ruudvdl" <ruudvdl@> wrote:
> > We feel the need to add a GUID attribute to media:content, to define the
uniqueness of a media file. The ability to set a GUID would make it easier to
use MRSS as syndication method for web applications. The rest of the
specification is already perfect for this end.
>
> A couple of questions so I can understand your idea better:
>
> 1. Why do you need more than one media:content object per item?
>
> 2. Isn't the URL attribute of each media:content object already unique?

Hi,

Sorry for the slow response...

1. I might have been unclear about this. We don't need more than one
media:content. The current structure (media:group and media:content) is perfect!

We just need a way to define a GUID for a video-file. The reason for this is
that our system supports multiple ways of linking to a video. For example there
can be both a progressive downloading link and a 'real streaming' link to (for
example) a flash media server.

The GUID is needed to let the customer format the URL to the material himself.

The MRSS standard perfectly supports everything that is needed to use it as a
syndication method for a Media-CMS, except for this one little thing.

Example number six on the MRSS-site perfectly demonstrates the problem:
http://video.search.yahoo.com/mrss
Check out example 6: it contains a sample <media:embed> code, containing this:
"id=12345&vid=678912i" ... MRSS supports no way to store these ID's anywhere
else in media:content, and exactly that is what I am looking for: an attribute
"guid" for media:content!

For example:
<media:content
   url="http://url/"
   fileSize="4323119296"
   type="video/quicktime"
   GUID="m4KkhBzR"
   (...) />

We would like to see this addition to MRSS so that we can use this as an open
standard for our media CMS (undoubtedly others will follow). This is really
vital to provide flexibility to our users.

I hope my reasons are clear enough and that you will consider this small
addition. Of course GUID should be an optional addition.

Thanks for considering,
Yours sincerely,
Ruud

--- In rss-media@yahoogroups.com, "Rogers" <cadenhead@...> wrote:
>
>
>
> --- In rss-media@yahoogroups.com, "ruudvdl" <ruudvdl@> wrote:
> > We feel the need to add a GUID attribute to media:content, to define the
uniqueness of a media file. The ability to set a GUID would make it easier to
use MRSS as syndication method for web applications. The rest of the
specification is already perfect for this end.
>
> A couple of questions so I can understand your idea better:
>
> 1. Why do you need more than one media:content object per item?
>
> 2. Isn't the URL attribute of each media:content object already unique?

Hi,

Sorry for the slow response...

1. I might have been unclear about this. We don't need more than one
media:content. The current structure (media:group and media:content) is perfect!

We just need a way to define a GUID for a video-file. The reason for this is
that our system supports multiple ways of linking to a video. For example there
can be both a progressive downloading link and a 'real streaming' link to (for
example) a flash media server.

The GUID is needed to let the customer format the URL to the material himself.

The MRSS standard perfectly supports everything that is needed to use it as a
syndication method for a Media-CMS, except for this one little thing.

Example number six on the MRSS-site perfectly demonstrates the problem:
http://video.search.yahoo.com/mrss
Check out example 6: it contains a sample <media:embed> code, containing this:
"id=12345&vid=678912i" ... MRSS supports no way to store these ID's anywhere
else in media:content, and exactly that is what I am looking for: an attribute
"guid" for media:content!

For example:
<media:content
   url="http://url/"
   fileSize="4323119296"
   type="video/quicktime"
   GUID="m4KkhBzR"
   (...) />

We would like to see this addition to MRSS so that we can use this as an open
standard for our media CMS (undoubtedly others will follow). This is really
vital to provide flexibility to our users.

I hope my reasons are clear enough and that you will consider this small
addition. Of course GUID should be an optional addition.

Thanks for considering,
Yours sincerely,
Ruud

Hello, I'm new to the group but did try to search this out.  There are some
answers from one or two years ago, but nothing recently.

Is there an XSD for Media RSS that I can use for class creation, etc?

Здравствуйте. Я робот. Я получил Ваше письмо и в ближайшее время передам его
содержание Илье Александровичу.
Hello. I'm robot. I have received your letter and in the near future I will
retell its matter to Ilya Aleksandrovich.

During our work in the Pharos project (
http://www.pharos-audiovisual-search.eu/) , a european collaborative research
project, we have been working and have experimented an extension of mediaRSS for
supporting innovative content access functionalities

Even if, we have been really interested by the new 1.5 specification of the
media RSS schema , we think that they are still oportunities for some usefull
improvements.

I don't know what  would be the most efficient tool to support this discussion 
but this forum might be a good start.
I apologize for the length of the post (- a wiki might have been a better
solution )- but let's start like this

I would really apreciate opinions and feedback about working on such an improved
version of the media RSS schema and about the precise proposition below

best regards

michel plu  ( R&D Engineer at Orange Labs )



Here is the list of Suggestions for improvements extracted from our work in the
pharos project  :

1 <media:scenes>

We think that the name "scene" is not a right name. We think that a right name
could be "segment". In fact there migh be many different types of segments which
can be described and a scene is only just one very specific .
a usefull attribute of this renamed <media:segment> element could thus be a
segmentType with possible values like( shot, speaker turn, audio, music, speech,
...)

In order to improve readability, XPAth selection , and homogenity of the spec,
we also think that this <media:segment> element should have a "start" and "end"
attribute like the <media:text> element  in order to precise the temporal
position of the segment in the described item


2 lang attributes in all textual XML elements
It was found a critical lack not to be able to precise the language of textual
descriptions, being titles, keywords  or descriptions. This attribute would
enable the production of description in multiple languages. It would enable the
inclusion of mutliple version of these textual descriptions - This lang
attribute would enable an adpated presentation of the described items according
to the language of the user and could also reduce "understanding" confusions

3 "source" attribute for keywords
Since keywords are important pieces of information to index and retrieve
contents , it is important to be able to include and distinguish  keywords
provided by multiple sources - Thoses sources can be for example multiple
personnes including end users or personnes having some credit in the production
of the content - Those keywords could also be automatically generated by any
piece of software - All these cases could be distinguished according to the
ascribed value of a "source" attribute.

4 "confidence" and "significance" attributes for keywords
Since those keywords can be produced automatically, including state of the art
media technologies for automated content processing , it could  become important
to provide some confidence measure about these keywords .
In complement, a "significance" attribute could also precise how much a keyword
is representing or being adressed in the described content
These values would be really usefull in order to rank or filter content
descriptions agregated from multiple sources.

Third party added value services could also improve and enrich original feeds by
providing their own values of those attributes for existing or  new  keywords.
UI of RSS readers  could then be free to use their own ranking or filtering
algorithms based of keywords from their selected sources.

5 "category" attribute for keywords
Facet based search is also becoming a major functionality in many content access
services . It allows users to cluster or  filter list of contents according to
their interest. Having more information on the nature of the keywords describing
an item would support this usefull facet based search functionality. We propose
to add a category attribute to <media:keywords> element. Possible values could
be  "person:name" "organisation:name" "location:name" "topic" "music:genre" etc
...    A scheme or method for defining those commonly agreed names can be
discussed  , but adding a new possible  value should be really flexible and
should not violate any schema conformance testing.

6 "media" attribute for keywords
since audio visual content are multi media , it could also be usefull to precise
which part ( media) of an audio visual item is described by a keyword . For
example some keywords can be specific to the audio track ( for example music
description ) whereas some keywords can be specific to images. Once again, this 
extra information would enable the user to navigate and filter list of items
agregated from multiple feeds.


4.7 content identification
A key issue for content aggregator services is to be able to detect and manage
duplicates of contents  coming from the same or different sources.
the mediaRSS schema should include  new XML elements to  precise the
identification of contents. One way is to be able for example to provide a link
to fingerprints ( or signature) wich can be compared  for contents related to
the described item  .
  Of course,to be compared,  all fingerprints must come from the same source.
Once again those trusted source of fingerprints could be provided by new third
party services
  (see for example the audible magic :
http://www.audiblemagic.com/products-services/registration/ )
Access to such  fingerprints, can be achieved by including URLs of a fingerprint
in a <media:fingerprint> XML element.

Inlusion of stadardized identification number (like ISBN for books) in the
<rss:guid> can be also usefull , but a "registrar" atribute for this <rss:guid>
XML element would be meaningfull to compare ids  and be able to publish multiple
ids for a content

8 Keyframes, thumbnail, and snapshot are different
We all know the power of images for seducing and atracting users . Therefore
more and more videos items are presented with more and more keyframes with links
included in the item description of the media feeds.
According to the user interface of the service,  only the best keyframe must be
selected in order to be presented to the user. This selection will not be the
best one if made randomly or automatically. Moreover, also legal impacts can be
raised. Thus, this choice must be an editorial one. This choice must be explicit
and it can be expressed by distinguishing all keyframes of the selected
thumbnail with different XML elements, respectively named keyframe and
thumbnail. Another distinguished XML element can also be added for snapshots.
A snapshot is not a keyframe, since it is not a picture originally coming from
the original content item but rather it is an extract of a keyframe ( for
example a zoomed area ) for emphasing some details present in the described
video item .
9 <media:community>
We didn't understand why the current  sub-elements <media:tags> of the
<media:community> element couldn' be expressed as  keywords element.
In fact it seems to us that the pieces of information contained in that element
are keywords provided by a specific source : "users".
Removing unecessary element would simplify the use and exploitation of the feeds
in mediaRSS .

--- In rss-media@yahoogroups.com, "Rogers" <cadenhead@...> wrote:
>
>
>
> --- In rss-media@yahoogroups.com, "ruudvdl" <ruudvdl@> wrote:
> > We feel the need to add a GUID attribute to media:content, to define the
uniqueness of a media file. The ability to set a GUID would make it easier to
use MRSS as syndication method for web applications. The rest of the
specification is already perfect for this end.
>
> A couple of questions so I can understand your idea better:
>
> 1. Why do you need more than one media:content object per item?
>
> 2. Isn't the URL attribute of each media:content object already unique?

Hi,

Sorry for the slow response...

1. I might have been unclear about this. We don't need more than one
media:content. The current structure (media:group and media:content) is perfect!

We just need a way to define a GUID for a video-file. The reason for this is
that our system supports multiple ways of linking to a video. For example there
can be both a progressive downloading link and a 'real streaming' link to (for
example) a flash media server.

The GUID is needed to let the customer format the URL to the material himself.

The MRSS standard perfectly supports everything that is needed to use it as a
syndication method for a Media-CMS, except for this one little thing.

Example number six on the MRSS-site perfectly demonstrates the problem:
http://video.search.yahoo.com/mrss
Check out example 6: it contains a sample <media:embed> code, containing this:
"id=12345&vid=678912i" ... MRSS supports no way to store these ID's anywhere
else in media:content, and exactly that is what I am looking for: an attribute
"guid" for media:content!

For example:
<media:content
   url="http://url/"
   fileSize="4323119296"
   type="video/quicktime"
   GUID="m4KkhBzR"
   (...) />

We would like to see this addition to MRSS so that we can use this as an open
standard for our media CMS (undoubtedly others will follow). This is really
vital to provide flexibility to our users.

I hope my reasons are clear enough and that you will consider this small
addition. Of course GUID should be an optional addition.

Thanks for considering,
Yours sincerely,
Ruud

• simple "just-put-the-text-on-the-screen" representation (e.g.: film/thriller")
• and/or a formal declaration that enables automated processing (e.g. a language-independent ID for a classification term might be used to retrieve a term name in a target language from a multilingual thesaurus; "smart"  searching would also be facilitated ...)