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

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

 
 

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

  
    

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

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

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

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

  
    

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

Sapna,
That's awesome to hear. Looks like Rogers has beat me to the punch, yet again.
I'm getting old :(
Thanks,

Randy

--- In rss-media@yahoogroups.com, "sapnach" <sapna@...> wrote:
>
> Hi Randy,
>
> 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.
>
> Thanks,
> Sapna
>
>
> --- In rss-media@yahoogroups.com, "randymorin" <randy@> wrote:
> >
> > Let me add my voice to Ryan's proposal to transfer the spec to the RSS
Advisory Board.
> > http://tech.groups.yahoo.com/group/rss-media/message/1193
> > It's nice to see some people at Yahoo! taking an interest, but what happens
when this group moves on as Jeremy did. The spec after Jeremy appeared to have
no ownership at Yahoo! and went thru some hard times where nobody even knew what
the namespace was or who to contact about clarification.
> > Thanks,
> >
> > Randy Charles Morin
> > Chairman of The RSS Advisory Board
> > http://www.rssboard.org/
> >
> > --- In rss-media@yahoogroups.com, "nilesh_gattani" <nileshg@> wrote:
> > >
> > > Hi all,
> > >
> > > Please do let us know your feedback by end of the next week so that we can
freeze on the revised spec and publish it.
> > >
> > > Thanks
> > > -Nilesh
> > >
> > > --- In rss-media@yahoogroups.com, Sapna Chandiramani <sapna@> wrote:
> > > >
> > > > Folks,
> > > >
> > > > As promised, we wanted to share the new spec that we are working on with
you, so you can provide your feedback.
> > > >
> > > > It's version 1.5 uploaded here by Nilesh:
> > > > http://tech.groups.yahoo.com/group/rss-media/files/
> > > >
> > > > Do let us know what you think. This is still also being reviewed
internally.
> > > >
> > > > Thanks,
> > > > Sapna
> > > >
> > > > ________________________________
> > > > From: Sapna Chandiramani
> > > > Sent: Wednesday, August 05, 2009 12:26 PM
> > > > To: 'rss-media@yahoogroups.com'
> > > > Cc: Chris Messina; David Recordan; Joseph Smarr; Allen Tom; Eran
Hammer-Lahav; kevinmarks@; Monica Keller; Mary Hodder
> > > > Subject: RE: [Fwd: Re: [rss-media] Specification currently lists the
wrong namespace]
> > > >
> > > > I don't think anyone at Yahoo! would have an issue of handing over the
custodianship to another body. Once you agree on who it should be, we can take
it forward.
> > > >
> > > > In the meantime, we will try to have the revised spec out for review to
you by the end of the week.
> > > >
> > > > -Sapna
> > > >
> > > >
> > > > ________________________________
> > > > From: rss-media@yahoogroups.com [mailto:rss-media@yahoogroups.com] On
Behalf Of Marc Canter
> > > > Sent: Tuesday, August 04, 2009 10:02 PM
> > > > To: rss-media@yahoogroups.com
> > > > Cc: Chris Messina; David Recordan; Joseph Smarr; Allen Tom; Eran
Hammer-Lahav; kevinmarks@; Monica Keller; Mary Hodder
> > > > Subject: Re: [Fwd: Re: [rss-media] Specification currently lists the
wrong namespace]
> > > >
> > > >
> > > >
> > > > I wouldn't necessarily trust the RSS advisory board any more than Yahoo.
> > > >
> > > > Besides - last I heard RSS 2.0 is already like 4 years old, so even
talking about versions .9 or .91 says it all.
> > > >
> > > > How 'bout you think about combining Media RSS with the efforts on-going
efforts behind Activity Streams and DiSO?
> > > >
> > > > These folks are state-of-the-art and they've been talking about media
meta-data - so NOW is the time to converge Media RSS with those efforts and get
these schemas in sync with microformats, etc.
> > > >
> > > > IMHO
> > > >
> > > > - marc
> > > > On Tue, Aug 4, 2009 at 11:53 AM, Ryan Parman
<ryan.lists.warpshare@<mailto:ryan.lists.warpshare@>> wrote:
> > > >
> > > > Sapna, et al:
> > > >
> > > > Several months back, there was discussion about placing the
custodianship of the Media RSS spec with the RSS Advisory Board. The folks at
Yahoo! at the time had consented that it was a good idea (I believe this was
Jeremy Zawdony, IIRC), but there never seemed to be any forward progress on that
initiative.
> > > >
> > > > My concern stems from the fact that the Media RSS spec has been
broken/incorrect multiple times now under Yahoo!'s custodianship. This is a spec
that many people depend on, and speaking as the developer of the SimplePie RSS
parser, arbitrarily changing the namespace URL substantially affects our ability
to handle Media RSS feeds. (We already have to normalize the two different Media
RSS namespace URLs that are floating around: one with, and one without the
trailing slash -- which was broken for over a year.)
> > > >
> > > > I would really like to see the RSS Advisory Board pass a resolution to
publish the namespace documentation on its site with the proper longtime
namespace URI. Netscape trusted the board to oversee RSS 0.90 and RSS 0.91, and
I would hope that Yahoo! would be able to see that this transfer of
custodianship would be a Good Thing(tm) for the Media RSS community.
> > > >
> > > > Future changes to the spec could be handled by the Media RSS community,
of which Yahoo! and others could be a part.
> > > >
> > > > Thoughts?
> > > >
> > > >
> > > >
> > > > On Jul 28, 2009, at 12:52 AM, Sapna Chandiramani wrote:
> > > >
> > > >
> > > > Folks,
> > > >
> > > > I apologize for the issues on behalf of Yahoo.
> > > > There were indeed some problems with the spec. This happened when we
were moving the spec to the Video Search servers so it would be easier to
respond to issues and requests henceforth.
> > > >
> > > > In any case, we have reverted back the spec. We are also working on a
newer version of the spec that addresses some concerns this group had pointed
out earlier, as well as some enhancements that we felt would be good to have.
> > > >
> > > > We will send that out for review to you soon.
> > > >
> > > > Thanks,
> > > > Sapna
> > > >
> > > > -------- Original Message --------
> > > > Subject: Re: [rss-media] Specification currently lists the wrong
namespace
> > > > Date: Tue, 21 Jul 2009 01:17:48 +0530
> > > > From: Joly MacFie <joly@<mailto:joly%40punkcast.com>>
> > > > Reply-To: rss-media@yahoogroups.com<mailto:rss-media%40yahoogroups.com>
<rss-media@yahoogroups.com<mailto:rss-media%40yahoogroups.com>>
> > > > To: rss-media@yahoogroups.com<mailto:rss-media%40yahoogroups.com>
<rss-media@yahoogroups.com<mailto:rss-media%40yahoogroups.com>>
> > > > References: <h421vv+3t1f@<mailto:h421vv%2B3t1f%40eGroups.com>>
> > > >
<2A6EB872-D3DE-4B36-9206-67902504C3A1@<mailto:2A6EB872-D3DE-4B36-9206-67902504C3\
A1%40gmail.com>>
> > > >
> > > > Earlier discussion:
> > > >
http://tech.groups.yahoo.com/group/rss-media/msearch?query=slash&submit=Search&c\
harset=ISO-8859-1
> > > >
<http://tech.groups.yahoo.com/group/rss-media/msearch?query=slash&submit=Search&\
charset=ISO-8859-1>
> > > >
> > > > Yahoo's neglect is a shame. Wasn't there some talk of moving it out of
> > > > their control?
> > > >
> > > > joly
> > > >
> > > > On Mon, Jul 20, 2009 at 1:52 PM, Ryan Parman
> > > > <ryan.lists.warpshare@<mailto:ryan.lists.warpshare%40gmail.com>
<mailto:ryan.lists.warpshare@<mailto:ryan.lists.warpshare%40gmail.com>>>
> > > > wrote:
> > > >
> > > > It looks like Yahoo once again arbitrarily changed the spec without
> > > > telling anybody.
> > > >
> > > > As of the last update that anybody was aware of, we had:
> > > >
> > > > 03/12/2008 - Namespace corrections: [1.1.2]
> > > >
> > > > * Added trailing slash to namespace
> > > >
> > > > The correct namespace *should* be exactly what you posted.
> > > > Apparently, Yahoo thought it'd be a good idea to change the
> > > > namespace again and break all sorts of parsing software. It is
> > > > embarrassing how badly they've bungled this spec.
> > > >
> > > > Once upon a time it fell to Jeremy Zawdony, but he's left Yahoo
> > > > since then. From what I can tell, nobody at Yahoo is paying
> > > > attention to this spec.
> > > >
> > > > On Jul 20, 2009, at 8:20 AM, James Abley wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I'm putting http://search.yahoo.com/mrss/
> > > > > <http://search.yahoo.com/mrss/> into my browser, which used to
> > > > > display the spec and have the correct namespace on the page. At
> > > > > the moment, I'm getting a 302 back to
> > > > >
> > > > > Location: http://video.search.yahoo.com/mrss
> > > > > <http://video.search.yahoo.com/mrss>
> > > > >
> > > > > and that URL is used as the namespace URI in the rendered
> > > > > specification.
> > > > >
> > > > > Anyone else noticed this and know who to raise it with? I don't
> > > > > want any more ambiguity in the world as to the correct namespace
> > > > > URI for this extension!
> > > > >
> > > > > Cheers,
> > > > >
> > > > > James
> > > > >
> > > >
> > > > --
> > > > ----------------------------------------------------------
> > > > Joly MacFie 917 442 8665 Skype:punkcast
> > > > WWWhatsup NYC - http://wwwhatsup.com <http://wwwhatsup.com>
> > > > http://pinstand.com <http://pinstand.com> - http://punkcast.com
> > > > <http://punkcast.com>
> > > > ----------------------------------------------------------
> > > >
> > >
> >
>

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

--- In rss-media@yahoogroups.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

Why is MediaRSS only a namespace enhancement for RSS? Why not create a truly
unique format for distributing media? The MediaRSS namespace is great, and
should be kept around for blogs and other websites that want to attach rich
content to their normal RSS feeds. But what about providers that are only
distributing episodic media? Why are they using a "Rich Site Summary"?

RSS is nothing special, just an XML file, and it has its fair share of problems;
all problems that you're inheriting by using a namespace. People read blogs
differently than they watch media. Nobody reads Engadget in iTunes & nobody
watches TWiT in Google Reader; a podcasting client is far different from an RSS
reader.

By branching off of RSS, you can better control every aspect of your feeds.
People won't have to refer to the feeds as "RSS with enclosures conforming to
the MediaRSS namespace"; they can have a simple name, a unique file extension,
and—most importantly—an icon.

It's time to split MediaRSS in two: keep the namespace (transfered to The RSS
Advisory Board) for blogs and news outlets looking to expand their articles with
video and audio, and create a new format. A new, cleaner format, created for
media from the ground up. We can use MediaRSS, strip-out "media:" from the tags,
add a few more, and have a new format over night.

Hi Randy,

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.

Thanks,
Sapna


--- In rss-media@yahoogroups.com, "randymorin" <randy@...> wrote:
>
> Let me add my voice to Ryan's proposal to transfer the spec to the RSS
Advisory Board.
> http://tech.groups.yahoo.com/group/rss-media/message/1193
> It's nice to see some people at Yahoo! taking an interest, but what happens
when this group moves on as Jeremy did. The spec after Jeremy appeared to have
no ownership at Yahoo! and went thru some hard times where nobody even knew what
the namespace was or who to contact about clarification.
> Thanks,
>
> Randy Charles Morin
> Chairman of The RSS Advisory Board
> http://www.rssboard.org/
>
> --- In rss-media@yahoogroups.com, "nilesh_gattani" <nileshg@> wrote:
> >
> > Hi all,
> >
> > Please do let us know your feedback by end of the next week so that we can
freeze on the revised spec and publish it.
> >
> > Thanks
> > -Nilesh
> >
> > --- In rss-media@yahoogroups.com, Sapna Chandiramani <sapna@> wrote:
> > >
> > > Folks,
> > >
> > > As promised, we wanted to share the new spec that we are working on with
you, so you can provide your feedback.
> > >
> > > It's version 1.5 uploaded here by Nilesh:
> > > http://tech.groups.yahoo.com/group/rss-media/files/
> > >
> > > Do let us know what you think. This is still also being reviewed
internally.
> > >
> > > Thanks,
> > > Sapna
> > >
> > > ________________________________
> > > From: Sapna Chandiramani
> > > Sent: Wednesday, August 05, 2009 12:26 PM
> > > To: 'rss-media@yahoogroups.com'
> > > Cc: Chris Messina; David Recordan; Joseph Smarr; Allen Tom; Eran
Hammer-Lahav; kevinmarks@; Monica Keller; Mary Hodder
> > > Subject: RE: [Fwd: Re: [rss-media] Specification currently lists the wrong
namespace]
> > >
> > > I don't think anyone at Yahoo! would have an issue of handing over the
custodianship to another body. Once you agree on who it should be, we can take
it forward.
> > >
> > > In the meantime, we will try to have the revised spec out for review to
you by the end of the week.
> > >
> > > -Sapna
> > >
> > >
> > > ________________________________
> > > From: rss-media@yahoogroups.com [mailto:rss-media@yahoogroups.com] On
Behalf Of Marc Canter
> > > Sent: Tuesday, August 04, 2009 10:02 PM
> > > To: rss-media@yahoogroups.com
> > > Cc: Chris Messina; David Recordan; Joseph Smarr; Allen Tom; Eran
Hammer-Lahav; kevinmarks@; Monica Keller; Mary Hodder
> > > Subject: Re: [Fwd: Re: [rss-media] Specification currently lists the wrong
namespace]
> > >
> > >
> > >
> > > I wouldn't necessarily trust the RSS advisory board any more than Yahoo.
> > >
> > > Besides - last I heard RSS 2.0 is already like 4 years old, so even
talking about versions .9 or .91 says it all.
> > >
> > > How 'bout you think about combining Media RSS with the efforts on-going
efforts behind Activity Streams and DiSO?
> > >
> > > These folks are state-of-the-art and they've been talking about media
meta-data - so NOW is the time to converge Media RSS with those efforts and get
these schemas in sync with microformats, etc.
> > >
> > > IMHO
> > >
> > > - marc
> > > On Tue, Aug 4, 2009 at 11:53 AM, Ryan Parman
<ryan.lists.warpshare@<mailto:ryan.lists.warpshare@>> wrote:
> > >
> > > Sapna, et al:
> > >
> > > Several months back, there was discussion about placing the custodianship
of the Media RSS spec with the RSS Advisory Board. The folks at Yahoo! at the
time had consented that it was a good idea (I believe this was Jeremy Zawdony,
IIRC), but there never seemed to be any forward progress on that initiative.
> > >
> > > My concern stems from the fact that the Media RSS spec has been
broken/incorrect multiple times now under Yahoo!'s custodianship. This is a spec
that many people depend on, and speaking as the developer of the SimplePie RSS
parser, arbitrarily changing the namespace URL substantially affects our ability
to handle Media RSS feeds. (We already have to normalize the two different Media
RSS namespace URLs that are floating around: one with, and one without the
trailing slash -- which was broken for over a year.)
> > >
> > > I would really like to see the RSS Advisory Board pass a resolution to
publish the namespace documentation on its site with the proper longtime
namespace URI. Netscape trusted the board to oversee RSS 0.90 and RSS 0.91, and
I would hope that Yahoo! would be able to see that this transfer of
custodianship would be a Good Thing(tm) for the Media RSS community.
> > >
> > > Future changes to the spec could be handled by the Media RSS community, of
which Yahoo! and others could be a part.
> > >
> > > Thoughts?
> > >
> > >
> > >
> > > On Jul 28, 2009, at 12:52 AM, Sapna Chandiramani wrote:
> > >
> > >
> > > Folks,
> > >
> > > I apologize for the issues on behalf of Yahoo.
> > > There were indeed some problems with the spec. This happened when we were
moving the spec to the Video Search servers so it would be easier to respond to
issues and requests henceforth.
> > >
> > > In any case, we have reverted back the spec. We are also working on a
newer version of the spec that addresses some concerns this group had pointed
out earlier, as well as some enhancements that we felt would be good to have.
> > >
> > > We will send that out for review to you soon.
> > >
> > > Thanks,
> > > Sapna
> > >
> > > -------- Original Message --------
> > > Subject: Re: [rss-media] Specification currently lists the wrong namespace
> > > Date: Tue, 21 Jul 2009 01:17:48 +0530
> > > From: Joly MacFie <joly@<mailto:joly%40punkcast.com>>
> > > Reply-To: rss-media@yahoogroups.com<mailto:rss-media%40yahoogroups.com>
<rss-media@yahoogroups.com<mailto:rss-media%40yahoogroups.com>>
> > > To: rss-media@yahoogroups.com<mailto:rss-media%40yahoogroups.com>
<rss-media@yahoogroups.com<mailto:rss-media%40yahoogroups.com>>
> > > References: <h421vv+3t1f@<mailto:h421vv%2B3t1f%40eGroups.com>>
> > >
<2A6EB872-D3DE-4B36-9206-67902504C3A1@<mailto:2A6EB872-D3DE-4B36-9206-67902504C3\
A1%40gmail.com>>
> > >
> > > Earlier discussion:
> > >
http://tech.groups.yahoo.com/group/rss-media/msearch?query=slash&submit=Search&c\
harset=ISO-8859-1
> > >
<http://tech.groups.yahoo.com/group/rss-media/msearch?query=slash&submit=Search&\
charset=ISO-8859-1>
> > >
> > > Yahoo's neglect is a shame. Wasn't there some talk of moving it out of
> > > their control?
> > >
> > > joly
> > >
> > > On Mon, Jul 20, 2009 at 1:52 PM, Ryan Parman
> > > <ryan.lists.warpshare@<mailto:ryan.lists.warpshare%40gmail.com>
<mailto:ryan.lists.warpshare@<mailto:ryan.lists.warpshare%40gmail.com>>>
> > > wrote:
> > >
> > > It looks like Yahoo once again arbitrarily changed the spec without
> > > telling anybody.
> > >
> > > As of the last update that anybody was aware of, we had:
> > >
> > > 03/12/2008 - Namespace corrections: [1.1.2]
> > >
> > > * Added trailing slash to namespace
> > >
> > > The correct namespace *should* be exactly what you posted.
> > > Apparently, Yahoo thought it'd be a good idea to change the
> > > namespace again and break all sorts of parsing software. It is
> > > embarrassing how badly they've bungled this spec.
> > >
> > > Once upon a time it fell to Jeremy Zawdony, but he's left Yahoo
> > > since then. From what I can tell, nobody at Yahoo is paying
> > > attention to this spec.
> > >
> > > On Jul 20, 2009, at 8:20 AM, James Abley wrote:
> > >
> > > > Hi,
> > > >
> > > > I'm putting http://search.yahoo.com/mrss/
> > > > <http://search.yahoo.com/mrss/> into my browser, which used to
> > > > display the spec and have the correct namespace on the page. At
> > > > the moment, I'm getting a 302 back to
> > > >
> > > > Location: http://video.search.yahoo.com/mrss
> > > > <http://video.search.yahoo.com/mrss>
> > > >
> > > > and that URL is used as the namespace URI in the rendered
> > > > specification.
> > > >
> > > > Anyone else noticed this and know who to raise it with? I don't
> > > > want any more ambiguity in the world as to the correct namespace
> > > > URI for this extension!
> > > >
> > > > Cheers,
> > > >
> > > > James
> > > >
> > >
> > > --
> > > ----------------------------------------------------------
> > > Joly MacFie 917 442 8665 Skype:punkcast
> > > WWWhatsup NYC - http://wwwhatsup.com <http://wwwhatsup.com>
> > > http://pinstand.com <http://pinstand.com> - http://punkcast.com
> > > <http://punkcast.com>
> > > ----------------------------------------------------------
> > >
> >
>

Awesome!

thanks
chris

--- In rss-media@yahoogroups.com, Nilesh Gattani <nileshg@...> wrote:
>
> Yes. Check
> http://tech.groups.yahoo.com/group/rss-media/files/mrss-1.5.0.html .
>
> Thanks
> -Nilesh
>
<http://f1.grp.yahoofs.com/v1/0PudSt9hlMEsOn5PB7gA9EtBLKca1GMmxz_7lJ22TfpGBVnZ1R\
_Svd6P2hOnagF7leAHO0fdu0dBcAprm3y_wg/mrss-1.5.0.html>
> chrisnew51 wrote:
> >
> >
> > Hi Nilesh,
> >
> > > Then may be something like
> > >
> > > <media:scenes>
> > > <media:scene>
> > > <sceneTitle> </sceneTitle>
> > > <sceneDescription> </sceneDescription>
> > > <sceneStartTime> </sceneStartTime>
> > > <sceneEndTime> </sceneEndTime>
> > > </media:scene>
> > > .
> > > .
> > > .
> > > <media:scenes>
> > >
> > > should work. What do you say?
> >
> > Looks good. Is it ok to include in mRSS 1.5 then?
> >
> > thanks
> > chris
> >
> > --- In rss-media@yahoogroups.com <mailto:rss-media%40yahoogroups.com>,
> > Nilesh Gattani <nileshg@> wrote:
> > >
> > > Hi Chris,
> > >
> > > Then may be something like
> > >
> > > <media:scenes>
> > > <media:scene>
> > > <sceneTitle> </sceneTitle>
> > > <sceneDescription> </sceneDescription>
> > > <sceneStartTime> </sceneStartTime>
> > > <sceneEndTime> </sceneEndTime>
> > > </media:scene>
> > > .
> > > .
> > > .
> > > <media:scenes>
> > >
> > > should work. What do you say?
> > >
> > > Thanks
> > > -Nilesh
> > >
> > >
> > > ----------------------------------------------------------
> > > *From:* chrisnew51 <chris@>
> > > *To:* rss-media@yahoogroups.com <mailto:rss-media%40yahoogroups.com>
> > > *Sent:* Saturday, 29 August, 2009 6:07:25 AM
> > > *Subject:* [rss-media] Re: HTML 5 video and mRSS 1.5 <scene> attribute
> > >
> > >
> > >
> > > Hi Nilesh,
> > >
> > > >Defining a hierarchy of parent mRSS document of entire media - child
> > > mRSS documents of media objects of scenes in mRSS spec would be very
> > > complicated, and it might result in a lot of redundent information
> > which
> > > may not be a good thing to have.
> > >
> > > Sure. Perhaps I was getting a little carried away...
> > >
> > > >On ther other hand, adding one flat <media:scenes> element to the
> > > existing spec is a good idea. But other than "start" and "end", I am
> > > quite unsure of what other properties this element should have.
> > > Actually, in my opinion, it would make more sense if the properties of
> > > this node are in accordance with HTML 5 video object.
> > >
> > > Great.
> > >
> > > In the UK a lot of full length TV programs are put online by the BBC
> > for
> > > use with their iPlayer. I see HTML5 video as a move to make the browser
> > > itself a media player. If a content provider such as the BBC adopts
> > > HTML5 video I can imagine how an RSS feed like this:
> > >
> > > http://feeds. bbc.co.uk/ iplayer/highligh ts/tv
> > > <http://feeds.bbc.co.uk/iplayer/highlights/tv
> > <http://feeds.bbc.co.uk/iplayer/highlights/tv>>
> > >
> > > ...could be presented by a browser plugin as a media stream
> > comprised of
> > > all the media objects rather than a list of content because it is
> > also a
> > > player. I think of mRSS for multiple purposes. Firstly it can be
> > used to
> > > archive information about all of the programs. Secondly it can
> > provide a
> > > standard list of new content additions. Thirdly a meta mRSS feed can be
> > > created which is essentially a playlist. The reason I need the
> > > <media:scenes> element is that I want the user to be able to pick and
> > > choose content from multiple programs to create a new meta mRSS feed
> > > which is used as a playlist to play an entirely new program sequence
> > > that is made up of scenes from all of the other programs.
> > >
> > > The flaw is that with a collection of scenes from different programs
> > > each whole video file will need to be downloaded to just watch an
> > > individual scene which is wasteful. However at least if <media:scenes>
> > > is in mRSS 1.5 I can ask questions about this on the relevant forums.
> > >
> > > On my previous post I don't actually need the HTML5 video tag to have
> > > start and end attributes as long as the mRSS document does have start
> > > and end because a browser plugin will drive the mRSS parsing and so
> > > control the video object directly which does contain the described
> > > playback position variable.
> > >
> > > >HTML 5 still seems to be in its evolution phase, so I would suggest
> > > let HTML5 become more widespread, so that we are fairly aware of all
> > the
> > > properties of video object in HTML5, and then add it to the current
> > mRSS
> > > spec.
> > >
> > > Specs tend to stay fixed for a relatively large period of time so I
> > > think if mRSS 1.5 doesn't include the <media:scenes> element there will
> > > be a long wait for the next one and then all of the following time to
> > > see if content providers adopt it. Firefox 3.5 already supports the
> > > HTML5 video object so if <media:scenes> is included in mRSS 1.5 I think
> > > I can do what I want just with title, description, start and end
> > attributes.
> > >
> > > chris
> > >
> > > --- In rss-media@yahoogrou ps.com <mailto:rss-media%40yahoogroups.com>,
> > > Nilesh Gattani <nilesh_gattani@ ...> wrote:
> > > >
> > > > Hi Chris,
> > > >
> > > > Thanks for your feedback.
> > > >
> > > > Defining a hierarchy of parent mRSS document of entire media - child
> > > mRSS documents of media objects of scenes in mRSS spec would be very
> > > complicated, and it might result in a lot of redundent information
> > which
> > > may not be a good thing to have.
> > > >
> > > > On ther other hand, adding one flat <media:scenes> element to the
> > > existing spec is a good idea. But other than "start" and "end", I am
> > > quite unsure of what other properties this element should have.
> > > Actually, in my opinion, it would make more sense if the properties of
> > > this node are in accordance with HTML 5 video object. HTML 5 still
> > seems
> > > to be in its evolution phase, so I would suggest let HTML5 become more
> > > widespread, so that we are fairly aware of all the properties of video
> > > object in HTML5, and then add it to the current mRSS spec.
> > > >
> > > > Let us know what do you think.
> > > >
> > > > Thanks
> > > > -Nilesh
> > > >
> > > >
> > > >
> > > >
> > > > ____________ _________ _________ __
> > > > From: chrisnew51 <chris@>
> > > > To: rss-media@yahoogrou ps.com <mailto:rss-media%40yahoogroups.com>
> > > > Sent: Sunday, 23 August, 2009 7:18:22 AM
> > > > Subject: [rss-media] HTML 5 video and mRSS 1.5 <scene> attribute
> > > >
> > > >
> > > > Hi,
> > > > the HTML 5 video object includes the facility to set the current
> > > playback position:
> > > >
> > > > http://www.w3. org/TR/html5/ video.html# current-playback -position
> > > >
> > > > I can't find the optional start and end attributes in the spec that
> > > are indicated here:
> > > >
> > > > http://www.w3school s.com/tags/ html5_video. asp
> > > >
> > > > However, if the video tag does eventually include start and end
> > > attributes I'd really like a <scene> tag in mRSS to provide rich
> > > granular detail of the content. In this way each scene itself can be
> > > identified as a media object - maybe even a whole mRSS document for
> > each
> > > scene within the parent mRSS document.
> > > >
> > > > I found a post from 2005 below that worries that this kind of thing
> > > adds additional complexity but I think the sub-document approach
> > > optionally enables flexibility.
> > > >
> > > > I see the 1.5 spec is in review so could this be considered? I'll
> > > research the HTML 5 video tag some more because I can't understand why
> > > start and end values aren't global attributes like width and height.
> > > >
> > > > chris
> > > >
> > > >
> > > > http://tech. groups.yahoo. com/group/ rss-media/ message/680
> > > >
> > > > --- In rss-media@yahoogrou ps.com, "Patrick Schmitz" <cogit@> wrote:
> > > > >
> > > > > There are clipbegin and end mechanisms in many players, but I do not
> > > > > think you want to have player or media specific parameters in a
> > general
> > > > > interchange format like this if you can avoid it. I think we can
> > > specify
> > > > > something quite simple that does the job. We're working on a
> > proposal
> > > > > right now.
> > > > >
> > > > > Patrick
> > > > >
> > > > > -----Original Message-----
> > > > > From: rss-media@yahoogrou ps.com [mailto:rss- media@yahoogroup
> > > s.com] On
> > > > > Behalf Of David Hall
> > > > > Sent: Tuesday, October 25, 2005 9:47 AM
> > > > > To: rss-media@yahoogrou ps.com
> > > > > Subject: [rss-media] Re: indexing into media files? (resend)
> > > > >
> > > > >
> > > > > --- In rss-media@yahoogrou ps.com, "Patrick Schmitz" <cogit@l...>
> > > wrote:
> > > > > >
> > > > > > I think SMIL is much too heavyweight for what Rich (and many
> > others)
> > > > > is
> > > > > > after. We should be able to describe temporal extents within
> > > MediaRSS,
> > > > > > IMO.
> > > > > >
> > > > > > See also http://www.id3. org/drafts/ id3v2_chapters- 2005101201.
> > > txt for
> > > > > > some related work at the ID3 header level.
> > > > > >
> > > > > > Patrick
> > > > >
> > > > > I wrote Rich off list, but isn't there a way for some of the various
> > > > > media types to directly specify where you want the content to start
> > > > > playing? I thought both Real and MS had such capabilities.
> > Either url
> > > > > or playlist based? Then you'd treat the various segments just
> > like any
> > > > > other media type within Media RSS.
> > > > >
> > > > > My fear is the opposite of yours - turning Media RSS into something
> > > > > much too heavyweight for the majority of users and needs.
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > > See the Web&#39;s breaking stories, chosen by people like you. Check
> > > out Yahoo! Buzz. http://in.buzz. yahoo.com/
> > <http://in.buzz.yahoo.com/ <http://in.buzz.yahoo.com/>>
> > > >
> > >
> >
> >
>

Yes. Check
http://tech.groups.yahoo.com/group/rss-media/files/mrss-1.5.0.html .

Thanks
-Nilesh
<http://f1.grp.yahoofs.com/v1/0PudSt9hlMEsOn5PB7gA9EtBLKca1GMmxz_7lJ22TfpGBVnZ1R\
_Svd6P2hOnagF7leAHO0fdu0dBcAprm3y_wg/mrss-1.5.0.html>
chrisnew51 wrote:
>
>
> Hi Nilesh,
>
> > Then may be something like
> >
> > <media:scenes>
> > <media:scene>
> > <sceneTitle> </sceneTitle>
> > <sceneDescription> </sceneDescription>
> > <sceneStartTime> </sceneStartTime>
> > <sceneEndTime> </sceneEndTime>
> > </media:scene>
> > .
> > .
> > .
> > <media:scenes>
> >
> > should work. What do you say?
>
> Looks good. Is it ok to include in mRSS 1.5 then?
>
> thanks
> chris
>
> --- In rss-media@yahoogroups.com <mailto:rss-media%40yahoogroups.com>,
> Nilesh Gattani <nileshg@...> wrote:
> >
> > Hi Chris,
> >
> > Then may be something like
> >
> > <media:scenes>
> > <media:scene>
> > <sceneTitle> </sceneTitle>
> > <sceneDescription> </sceneDescription>
> > <sceneStartTime> </sceneStartTime>
> > <sceneEndTime> </sceneEndTime>
> > </media:scene>
> > .
> > .
> > .
> > <media:scenes>
> >
> > should work. What do you say?
> >
> > Thanks
> > -Nilesh
> >
> >
> > ----------------------------------------------------------
> > *From:* chrisnew51 <chris@...>
> > *To:* rss-media@yahoogroups.com <mailto:rss-media%40yahoogroups.com>
> > *Sent:* Saturday, 29 August, 2009 6:07:25 AM
> > *Subject:* [rss-media] Re: HTML 5 video and mRSS 1.5 <scene> attribute
> >
> >
> >
> > Hi Nilesh,
> >
> > >Defining a hierarchy of parent mRSS document of entire media - child
> > mRSS documents of media objects of scenes in mRSS spec would be very
> > complicated, and it might result in a lot of redundent information
> which
> > may not be a good thing to have.
> >
> > Sure. Perhaps I was getting a little carried away...
> >
> > >On ther other hand, adding one flat <media:scenes> element to the
> > existing spec is a good idea. But other than "start" and "end", I am
> > quite unsure of what other properties this element should have.
> > Actually, in my opinion, it would make more sense if the properties of
> > this node are in accordance with HTML 5 video object.
> >
> > Great.
> >
> > In the UK a lot of full length TV programs are put online by the BBC
> for
> > use with their iPlayer. I see HTML5 video as a move to make the browser
> > itself a media player. If a content provider such as the BBC adopts
> > HTML5 video I can imagine how an RSS feed like this:
> >
> > http://feeds. bbc.co.uk/ iplayer/highligh ts/tv
> > <http://feeds.bbc.co.uk/iplayer/highlights/tv
> <http://feeds.bbc.co.uk/iplayer/highlights/tv>>
> >
> > ...could be presented by a browser plugin as a media stream
> comprised of
> > all the media objects rather than a list of content because it is
> also a
> > player. I think of mRSS for multiple purposes. Firstly it can be
> used to
> > archive information about all of the programs. Secondly it can
> provide a
> > standard list of new content additions. Thirdly a meta mRSS feed can be
> > created which is essentially a playlist. The reason I need the
> > <media:scenes> element is that I want the user to be able to pick and
> > choose content from multiple programs to create a new meta mRSS feed
> > which is used as a playlist to play an entirely new program sequence
> > that is made up of scenes from all of the other programs.
> >
> > The flaw is that with a collection of scenes from different programs
> > each whole video file will need to be downloaded to just watch an
> > individual scene which is wasteful. However at least if <media:scenes>
> > is in mRSS 1.5 I can ask questions about this on the relevant forums.
> >
> > On my previous post I don't actually need the HTML5 video tag to have
> > start and end attributes as long as the mRSS document does have start
> > and end because a browser plugin will drive the mRSS parsing and so
> > control the video object directly which does contain the described
> > playback position variable.
> >
> > >HTML 5 still seems to be in its evolution phase, so I would suggest
> > let HTML5 become more widespread, so that we are fairly aware of all
> the
> > properties of video object in HTML5, and then add it to the current
> mRSS
> > spec.
> >
> > Specs tend to stay fixed for a relatively large period of time so I
> > think if mRSS 1.5 doesn't include the <media:scenes> element there will
> > be a long wait for the next one and then all of the following time to
> > see if content providers adopt it. Firefox 3.5 already supports the
> > HTML5 video object so if <media:scenes> is included in mRSS 1.5 I think
> > I can do what I want just with title, description, start and end
> attributes.
> >
> > chris
> >
> > --- In rss-media@yahoogrou ps.com <mailto:rss-media%40yahoogroups.com>,
> > Nilesh Gattani <nilesh_gattani@ ...> wrote:
> > >
> > > Hi Chris,
> > >
> > > Thanks for your feedback.
> > >
> > > Defining a hierarchy of parent mRSS document of entire media - child
> > mRSS documents of media objects of scenes in mRSS spec would be very
> > complicated, and it might result in a lot of redundent information
> which
> > may not be a good thing to have.
> > >
> > > On ther other hand, adding one flat <media:scenes> element to the
> > existing spec is a good idea. But other than "start" and "end", I am
> > quite unsure of what other properties this element should have.
> > Actually, in my opinion, it would make more sense if the properties of
> > this node are in accordance with HTML 5 video object. HTML 5 still
> seems
> > to be in its evolution phase, so I would suggest let HTML5 become more
> > widespread, so that we are fairly aware of all the properties of video
> > object in HTML5, and then add it to the current mRSS spec.
> > >
> > > Let us know what do you think.
> > >
> > > Thanks
> > > -Nilesh
> > >
> > >
> > >
> > >
> > > ____________ _________ _________ __
> > > From: chrisnew51 <chris@>
> > > To: rss-media@yahoogrou ps.com <mailto:rss-media%40yahoogroups.com>
> > > Sent: Sunday, 23 August, 2009 7:18:22 AM
> > > Subject: [rss-media] HTML 5 video and mRSS 1.5 <scene> attribute
> > >
> > >
> > > Hi,
> > > the HTML 5 video object includes the facility to set the current
> > playback position:
> > >
> > > http://www.w3. org/TR/html5/ video.html# current-playback -position
> > >
> > > I can't find the optional start and end attributes in the spec that
> > are indicated here:
> > >
> > > http://www.w3school s.com/tags/ html5_video. asp
> > >
> > > However, if the video tag does eventually include start and end
> > attributes I'd really like a <scene> tag in mRSS to provide rich
> > granular detail of the content. In this way each scene itself can be
> > identified as a media object - maybe even a whole mRSS document for
> each
> > scene within the parent mRSS document.
> > >
> > > I found a post from 2005 below that worries that this kind of thing
> > adds additional complexity but I think the sub-document approach
> > optionally enables flexibility.
> > >
> > > I see the 1.5 spec is in review so could this be considered? I'll
> > research the HTML 5 video tag some more because I can't understand why
> > start and end values aren't global attributes like width and height.
> > >
> > > chris
> > >
> > >
> > > http://tech. groups.yahoo. com/group/ rss-media/ message/680
> > >
> > > --- In rss-media@yahoogrou ps.com, "Patrick Schmitz" <cogit@> wrote:
> > > >
> > > > There are clipbegin and end mechanisms in many players, but I do not
> > > > think you want to have player or media specific parameters in a
> general
> > > > interchange format like this if you can avoid it. I think we can
> > specify
> > > > something quite simple that does the job. We're working on a
> proposal
> > > > right now.
> > > >
> > > > Patrick
> > > >
> > > > -----Original Message-----
> > > > From: rss-media@yahoogrou ps.com [mailto:rss- media@yahoogroup
> > s.com] On
> > > > Behalf Of David Hall
> > > > Sent: Tuesday, October 25, 2005 9:47 AM
> > > > To: rss-media@yahoogrou ps.com
> > > > Subject: [rss-media] Re: indexing into media files? (resend)
> > > >
> > > >
> > > > --- In rss-media@yahoogrou ps.com, "Patrick Schmitz" <cogit@l...>
> > wrote:
> > > > >
> > > > > I think SMIL is much too heavyweight for what Rich (and many
> others)
> > > > is
> > > > > after. We should be able to describe temporal extents within
> > MediaRSS,
> > > > > IMO.
> > > > >
> > > > > See also http://www.id3. org/drafts/ id3v2_chapters- 2005101201.
> > txt for
> > > > > some related work at the ID3 header level.
> > > > >
> > > > > Patrick
> > > >
> > > > I wrote Rich off list, but isn't there a way for some of the various
> > > > media types to directly specify where you want the content to start
> > > > playing? I thought both Real and MS had such capabilities.
> Either url
> > > > or playlist based? Then you'd treat the various segments just
> like any
> > > > other media type within Media RSS.
> > > >
> > > > My fear is the opposite of yours - turning Media RSS into something
> > > > much too heavyweight for the majority of users and needs.
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > See the Web&#39;s breaking stories, chosen by people like you. Check
> > out Yahoo! Buzz. http://in.buzz. yahoo.com/
> <http://in.buzz.yahoo.com/ <http://in.buzz.yahoo.com/>>
> > >
> >
>
>

Hi Nilesh,

> Then may be something like
>
> <media:scenes>
>     <media:scene>
>        <sceneTitle> </sceneTitle>
>        <sceneDescription> </sceneDescription>
>        <sceneStartTime> </sceneStartTime>
>         <sceneEndTime> </sceneEndTime>
>    </media:scene>
>    .
>    .
>    .
> <media:scenes>
>
> should work. What do you say?

Looks good. Is it ok to include in mRSS 1.5 then?

thanks
chris


--- In rss-media@yahoogroups.com, Nilesh Gattani <nileshg@...> wrote:
>
> Hi Chris,
>
> Then may be something like
>
> <media:scenes>
>     <media:scene>
>        <sceneTitle> </sceneTitle>
>        <sceneDescription> </sceneDescription>
>        <sceneStartTime> </sceneStartTime>
>         <sceneEndTime> </sceneEndTime>
>    </media:scene>
>    .
>    .
>    .
> <media:scenes>
>
> should work. What do you say?
>
> Thanks
> -Nilesh
>
>
> ------------------------------------------------------------------------
> *From:* chrisnew51 <chris@...>
> *To:* rss-media@yahoogroups.com
> *Sent:* Saturday, 29 August, 2009 6:07:25 AM
> *Subject:* [rss-media] Re: HTML 5 video and mRSS 1.5 <scene> attribute
>
>
>
> Hi Nilesh,
>
>  >Defining a hierarchy of parent mRSS document of entire media - child
> mRSS documents of media objects of scenes in mRSS spec would be very
> complicated, and it might result in a lot of redundent information which
> may not be a good thing to have.
>
> Sure. Perhaps I was getting a little carried away...
>
>  >On ther other hand, adding one flat <media:scenes> element to the
> existing spec is a good idea. But other than "start" and "end", I am
> quite unsure of what other properties this element should have.
> Actually, in my opinion, it would make more sense if the properties of
> this node are in accordance with HTML 5 video object.
>
> Great.
>
> In the UK a lot of full length TV programs are put online by the BBC for
> use with their iPlayer. I see HTML5 video as a move to make the browser
> itself a media player. If a content provider such as the BBC adopts
> HTML5 video I can imagine how an RSS feed like this:
>
> http://feeds. bbc.co.uk/ iplayer/highligh ts/tv
> <http://feeds.bbc.co.uk/iplayer/highlights/tv>
>
> ...could be presented by a browser plugin as a media stream comprised of
> all the media objects rather than a list of content because it is also a
> player. I think of mRSS for multiple purposes. Firstly it can be used to
> archive information about all of the programs. Secondly it can provide a
> standard list of new content additions. Thirdly a meta mRSS feed can be
> created which is essentially a playlist. The reason I need the
> <media:scenes> element is that I want the user to be able to pick and
> choose content from multiple programs to create a new meta mRSS feed
> which is used as a playlist to play an entirely new program sequence
> that is made up of scenes from all of the other programs.
>
> The flaw is that with a collection of scenes from different programs
> each whole video file will need to be downloaded to just watch an
> individual scene which is wasteful. However at least if <media:scenes>
> is in mRSS 1.5 I can ask questions about this on the relevant forums.
>
> On my previous post I don't actually need the HTML5 video tag to have
> start and end attributes as long as the mRSS document does have start
> and end because a browser plugin will drive the mRSS parsing and so
> control the video object directly which does contain the described
> playback position variable.
>
>  >HTML 5 still seems to be in its evolution phase, so I would suggest
> let HTML5 become more widespread, so that we are fairly aware of all the
> properties of video object in HTML5, and then add it to the current mRSS
> spec.
>
> Specs tend to stay fixed for a relatively large period of time so I
> think if mRSS 1.5 doesn't include the <media:scenes> element there will
> be a long wait for the next one and then all of the following time to
> see if content providers adopt it. Firefox 3.5 already supports the
> HTML5 video object so if <media:scenes> is included in mRSS 1.5 I think
> I can do what I want just with title, description, start and end attributes.
>
> chris
>
> --- In rss-media@yahoogrou ps.com <mailto:rss-media%40yahoogroups.com>,
> Nilesh Gattani <nilesh_gattani@ ...> wrote:
>  >
>  > Hi Chris,
>  >
>  > Thanks for your feedback.
>  >
>  > Defining a hierarchy of parent mRSS document of entire media - child
> mRSS documents of media objects of scenes in mRSS spec would be very
> complicated, and it might result in a lot of redundent information which
> may not be a good thing to have.
>  >
>  > On ther other hand, adding one flat <media:scenes> element to the
> existing spec is a good idea. But other than "start" and "end", I am
> quite unsure of what other properties this element should have.
> Actually, in my opinion, it would make more sense if the properties of
> this node are in accordance with HTML 5 video object. HTML 5 still seems
> to be in its evolution phase, so I would suggest let HTML5 become more
> widespread, so that we are fairly aware of all the properties of video
> object in HTML5, and then add it to the current mRSS spec.
>  >
>  > Let us know what do you think.
>  >
>  > Thanks
>  > -Nilesh
>  >
>  >
>  >
>  >
>  > ____________ _________ _________ __
>  > From: chrisnew51 <chris@>
>  > To: rss-media@yahoogrou ps.com <mailto:rss-media%40yahoogroups.com>
>  > Sent: Sunday, 23 August, 2009 7:18:22 AM
>  > Subject: [rss-media] HTML 5 video and mRSS 1.5 <scene> attribute
>  >
>  >
>  > Hi,
>  > the HTML 5 video object includes the facility to set the current
> playback position:
>  >
>  > http://www.w3. org/TR/html5/ video.html# current-playback -position
>  >
>  > I can't find the optional start and end attributes in the spec that
> are indicated here:
>  >
>  > http://www.w3school s.com/tags/ html5_video. asp
>  >
>  > However, if the video tag does eventually include start and end
> attributes I'd really like a <scene> tag in mRSS to provide rich
> granular detail of the content. In this way each scene itself can be
> identified as a media object - maybe even a whole mRSS document for each
> scene within the parent mRSS document.
>  >
>  > I found a post from 2005 below that worries that this kind of thing
> adds additional complexity but I think the sub-document approach
> optionally enables flexibility.
>  >
>  > I see the 1.5 spec is in review so could this be considered? I'll
> research the HTML 5 video tag some more because I can't understand why
> start and end values aren't global attributes like width and height.
>  >
>  > chris
>  >
>  >
>  > http://tech. groups.yahoo. com/group/ rss-media/ message/680
>  >
>  > --- In rss-media@yahoogrou ps.com, "Patrick Schmitz" <cogit@> wrote:
>  > >
>  > > There are clipbegin and end mechanisms in many players, but I do not
>  > > think you want to have player or media specific parameters in a general
>  > > interchange format like this if you can avoid it. I think we can
> specify
>  > > something quite simple that does the job. We're working on a proposal
>  > > right now.
>  > >
>  > > Patrick
>  > >
>  > > -----Original Message-----
>  > > From: rss-media@yahoogrou ps.com [mailto:rss- media@yahoogroup
> s.com] On
>  > > Behalf Of David Hall
>  > > Sent: Tuesday, October 25, 2005 9:47 AM
>  > > To: rss-media@yahoogrou ps.com
>  > > Subject: [rss-media] Re: indexing into media files? (resend)
>  > >
>  > >
>  > > --- In rss-media@yahoogrou ps.com, "Patrick Schmitz" <cogit@l...>
> wrote:
>  > > >
>  > > > I think SMIL is much too heavyweight for what Rich (and many others)
>  > > is
>  > > > after. We should be able to describe temporal extents within
> MediaRSS,
>  > > > IMO.
>  > > >
>  > > > See also http://www.id3. org/drafts/ id3v2_chapters- 2005101201.
> txt for
>  > > > some related work at the ID3 header level.
>  > > >
>  > > > Patrick
>  > >
>  > > I wrote Rich off list, but isn't there a way for some of the various
>  > > media types to directly specify where you want the content to start
>  > > playing? I thought both Real and MS had such capabilities. Either url
>  > > or playlist based? Then you'd treat the various segments just like any
>  > > other media type within Media RSS.
>  > >
>  > > My fear is the opposite of yours - turning Media RSS into something
>  > > much too heavyweight for the majority of users and needs.
>  > >
>  > >
>  >
>  >
>  >
>  >
>  > See the Web&#39;s breaking stories, chosen by people like you. Check
> out Yahoo! Buzz. http://in.buzz. yahoo.com/ <http://in.buzz.yahoo.com/>
>  >
>

Hi Chris,

Then may be something like

<media:scenes>
     <media:scene>
        <sceneTitle> </sceneTitle>
        <sceneDescription> </sceneDescription>
        <sceneStartTime> </sceneStartTime>
         <sceneEndTime> </sceneEndTime>
    </media:scene>
    .
    .
    .
<media:scenes>

should work. What do you say?

Thanks
-Nilesh


------------------------------------------------------------------------
*From:* chrisnew51 <chris@...>
*To:* rss-media@yahoogroups.com
*Sent:* Saturday, 29 August, 2009 6:07:25 AM
*Subject:* [rss-media] Re: HTML 5 video and mRSS 1.5 <scene> attribute



Hi Nilesh,

  >Defining a hierarchy of parent mRSS document of entire media - child
mRSS documents of media objects of scenes in mRSS spec would be very
complicated, and it might result in a lot of redundent information which
may not be a good thing to have.

Sure. Perhaps I was getting a little carried away...

  >On ther other hand, adding one flat <media:scenes> element to the
existing spec is a good idea. But other than "start" and "end", I am
quite unsure of what other properties this element should have.
Actually, in my opinion, it would make more sense if the properties of
this node are in accordance with HTML 5 video object.

Great.

In the UK a lot of full length TV programs are put online by the BBC for
use with their iPlayer. I see HTML5 video as a move to make the browser
itself a media player. If a content provider such as the BBC adopts
HTML5 video I can imagine how an RSS feed like this:

http://feeds. bbc.co.uk/ iplayer/highligh ts/tv
<http://feeds.bbc.co.uk/iplayer/highlights/tv>

...could be presented by a browser plugin as a media stream comprised of
all the media objects rather than a list of content because it is also a
player. I think of mRSS for multiple purposes. Firstly it can be used to
archive information about all of the programs. Secondly it can provide a
standard list of new content additions. Thirdly a meta mRSS feed can be
created which is essentially a playlist. The reason I need the
<media:scenes> element is that I want the user to be able to pick and
choose content from multiple programs to create a new meta mRSS feed
which is used as a playlist to play an entirely new program sequence
that is made up of scenes from all of the other programs.

The flaw is that with a collection of scenes from different programs
each whole video file will need to be downloaded to just watch an
individual scene which is wasteful. However at least if <media:scenes>
is in mRSS 1.5 I can ask questions about this on the relevant forums.

On my previous post I don't actually need the HTML5 video tag to have
start and end attributes as long as the mRSS document does have start
and end because a browser plugin will drive the mRSS parsing and so
control the video object directly which does contain the described
playback position variable.

  >HTML 5 still seems to be in its evolution phase, so I would suggest
let HTML5 become more widespread, so that we are fairly aware of all the
properties of video object in HTML5, and then add it to the current mRSS
spec.

Specs tend to stay fixed for a relatively large period of time so I
think if mRSS 1.5 doesn't include the <media:scenes> element there will
be a long wait for the next one and then all of the following time to
see if content providers adopt it. Firefox 3.5 already supports the
HTML5 video object so if <media:scenes> is included in mRSS 1.5 I think
I can do what I want just with title, description, start and end attributes.

chris

--- In rss-media@yahoogrou ps.com <mailto:rss-media%40yahoogroups.com>,
Nilesh Gattani <nilesh_gattani@ ...> wrote:
  >
  > Hi Chris,
  >
  > Thanks for your feedback.
  >
  > Defining a hierarchy of parent mRSS document of entire media - child
mRSS documents of media objects of scenes in mRSS spec would be very
complicated, and it might result in a lot of redundent information which
may not be a good thing to have.
  >
  > On ther other hand, adding one flat <media:scenes> element to the
existing spec is a good idea. But other than "start" and "end", I am
quite unsure of what other properties this element should have.
Actually, in my opinion, it would make more sense if the properties of
this node are in accordance with HTML 5 video object. HTML 5 still seems
to be in its evolution phase, so I would suggest let HTML5 become more
widespread, so that we are fairly aware of all the properties of video
object in HTML5, and then add it to the current mRSS spec.
  >
  > Let us know what do you think.
  >
  > Thanks
  > -Nilesh
  >
  >
  >
  >
  > ____________ _________ _________ __
  > From: chrisnew51 <chris@...>
  > To: rss-media@yahoogrou ps.com <mailto:rss-media%40yahoogroups.com>
  > Sent: Sunday, 23 August, 2009 7:18:22 AM
  > Subject: [rss-media] HTML 5 video and mRSS 1.5 <scene> attribute
  >
  >
  > Hi,
  > the HTML 5 video object includes the facility to set the current
playback position:
  >
  > http://www.w3. org/TR/html5/ video.html# current-playback -position
  >
  > I can't find the optional start and end attributes in the spec that
are indicated here:
  >
  > http://www.w3school s.com/tags/ html5_video. asp
  >
  > However, if the video tag does eventually include start and end
attributes I'd really like a <scene> tag in mRSS to provide rich
granular detail of the content. In this way each scene itself can be
identified as a media object - maybe even a whole mRSS document for each
scene within the parent mRSS document.
  >
  > I found a post from 2005 below that worries that this kind of thing
adds additional complexity but I think the sub-document approach
optionally enables flexibility.
  >
  > I see the 1.5 spec is in review so could this be considered? I'll
research the HTML 5 video tag some more because I can't understand why
start and end values aren't global attributes like width and height.
  >
  > chris
  >
  >
  > http://tech. groups.yahoo. com/group/ rss-media/ message/680
  >
  > --- In rss-media@yahoogrou ps.com, "Patrick Schmitz" <cogit@> wrote:
  > >
  > > There are clipbegin and end mechanisms in many players, but I do not
  > > think you want to have player or media specific parameters in a general
  > > interchange format like this if you can avoid it. I think we can
specify
  > > something quite simple that does the job. We're working on a proposal
  > > right now.
  > >
  > > Patrick
  > >
  > > -----Original Message-----
  > > From: rss-media@yahoogrou ps.com [mailto:rss- media@yahoogroup
s.com] On
  > > Behalf Of David Hall
  > > Sent: Tuesday, October 25, 2005 9:47 AM
  > > To: rss-media@yahoogrou ps.com
  > > Subject: [rss-media] Re: indexing into media files? (resend)
  > >
  > >
  > > --- In rss-media@yahoogrou ps.com, "Patrick Schmitz" <cogit@l...>
wrote:
  > > >
  > > > I think SMIL is much too heavyweight for what Rich (and many others)
  > > is
  > > > after. We should be able to describe temporal extents within
MediaRSS,
  > > > IMO.
  > > >
  > > > See also http://www.id3. org/drafts/ id3v2_chapters- 2005101201.
txt for
  > > > some related work at the ID3 header level.
  > > >
  > > > Patrick
  > >
  > > I wrote Rich off list, but isn't there a way for some of the various
  > > media types to directly specify where you want the content to start
  > > playing? I thought both Real and MS had such capabilities. Either url
  > > or playlist based? Then you'd treat the various segments just like any
  > > other media type within Media RSS.
  > >
  > > My fear is the opposite of yours - turning Media RSS into something
  > > much too heavyweight for the majority of users and needs.
  > >
  > >
  >
  >
  >
  >
  > See the Web&#39;s breaking stories, chosen by people like you. Check
out Yahoo! Buzz. http://in.buzz. yahoo.com/ <http://in.buzz.yahoo.com/>
  >

Hi Nilesh,

>Defining a hierarchy of parent mRSS document of entire media - child mRSS
documents of media objects of scenes in mRSS spec would be very complicated, and
it might result in a lot of redundent information which may not be a good thing
to have.

Sure. Perhaps I was getting a little carried away...

>On ther other hand, adding one flat <media:scenes> element to the existing spec
is a good idea. But other than "start" and "end", I am quite unsure of what
other properties this element should have. Actually, in my opinion, it would
make more sense if the properties of this node are in accordance with HTML 5
video object.

Great.

In the UK a lot of full length TV programs are put online by the BBC for use
with their iPlayer. I see HTML5 video as a move to make the browser itself a
media player. If a content provider such as the BBC adopts HTML5 video I can
imagine how an RSS feed like this:

http://feeds.bbc.co.uk/iplayer/highlights/tv

...could be presented by a browser plugin as a media stream comprised of all the
media objects rather than a list of content because it is also a player. I think
of mRSS for multiple purposes. Firstly it can be used to archive information
about all of the programs. Secondly it can provide a standard list of new
content additions. Thirdly a meta mRSS feed can be created which is essentially
a playlist. The reason I need the <media:scenes> element is that I want the user
to be able to pick and choose content from multiple programs to create a new
meta mRSS feed which is used as a playlist to play an entirely new program
sequence that is made up of scenes from all of the other programs.

The flaw is that with a collection of scenes from different programs each whole
video file will need to be downloaded to just watch an individual scene which is
wasteful. However at least if <media:scenes> is in mRSS 1.5 I can ask questions
about this on the relevant forums.

On my previous post I don't actually need the HTML5 video tag to have start and
end attributes as long as the mRSS document does have start and end because a
browser plugin will drive the mRSS parsing and so control the video object
directly which does contain the described playback position variable.

>HTML 5 still seems to be in its evolution phase, so I would suggest let HTML5
become more widespread, so that we are fairly aware of all the properties of
video object in HTML5, and then add it to the current mRSS spec.

Specs tend to stay fixed for a relatively large period of time so I think if
mRSS 1.5 doesn't include the <media:scenes> element there will be a long wait
for the next one and then all of the following time to see if content providers
adopt it. Firefox 3.5 already supports the HTML5 video object  so if
<media:scenes> is included in mRSS 1.5 I think I can do what I want just with
title, description, start and end attributes.

chris




--- In rss-media@yahoogroups.com, Nilesh Gattani <nilesh_gattani@...> wrote:
>
> Hi Chris,
>
> Thanks for your feedback.
>
> Defining a hierarchy of parent mRSS document of entire media - child mRSS
documents of media objects of scenes in mRSS spec would be very complicated, and
it might result in a lot of redundent information which may not be a good thing
to have.
>
> On ther other hand, adding one flat <media:scenes> element to the existing
spec is a good idea. But other than "start" and "end", I am quite unsure of what
other properties this element should have. Actually, in my opinion, it would
make more sense if the properties of this node are in accordance with HTML 5
video object. HTML 5 still seems to be in its evolution phase, so I would
suggest let HTML5 become more widespread, so that we are fairly aware of all the
properties of video object in HTML5, and then add it to the current mRSS spec.
>
> Let us know what do you think.
>
> Thanks
> -Nilesh
>
>
>
>
> ________________________________
> From: chrisnew51 <chris@...>
> To: rss-media@yahoogroups.com
> Sent: Sunday, 23 August, 2009 7:18:22 AM
> Subject: [rss-media] HTML 5 video and mRSS 1.5 <scene> attribute
>
>
> Hi,
>     the HTML 5 video object includes the facility to set the current playback
position:
>
> http://www.w3. org/TR/html5/ video.html# current-playback -position
>
>     I can't find the optional start and end attributes in the spec that are
indicated here:
>
> http://www.w3school s.com/tags/ html5_video. asp
>
> However, if the video tag does eventually include start and end attributes I'd
really like a <scene> tag in mRSS to provide rich granular detail of the
content. In this way each scene itself can be identified as a media object -
maybe even a whole mRSS document for each scene within the parent mRSS document.
>
> I found a post from 2005 below that worries that this kind of thing adds
additional complexity but I think the sub-document approach optionally enables
flexibility.
>
> I see the 1.5 spec is in review so could this be considered? I'll research the
HTML 5 video tag some more because I can't understand why start and end values
aren't global attributes like width and height.
>
> chris
>
>
> http://tech. groups.yahoo. com/group/ rss-media/ message/680
>
> --- In rss-media@yahoogrou ps.com, "Patrick Schmitz" <cogit@> wrote:
> >
> > There are clipbegin and end mechanisms in many players, but I do not
> > think you want to have player or media specific parameters in a general
> > interchange format like this if you can avoid it. I think we can specify
> > something quite simple that does the job. We're working on a proposal
> > right now.
> >
> > Patrick
> >
> > -----Original Message-----
> > From: rss-media@yahoogrou ps.com [mailto:rss- media@yahoogroup s.com] On
> > Behalf Of David Hall
> > Sent: Tuesday, October 25, 2005 9:47 AM
> > To: rss-media@yahoogrou ps.com
> > Subject: [rss-media] Re: indexing into media files? (resend)
> >
> >
> > --- In rss-media@yahoogrou ps.com, "Patrick Schmitz" <cogit@l...> wrote:
> > >
> > > I think SMIL is much too heavyweight for what Rich (and many others)
> > is
> > > after. We should be able to describe temporal extents within MediaRSS,
> > > IMO.
> > >
> > > See also http://www.id3. org/drafts/ id3v2_chapters- 2005101201. txt for
> > > some related work at the ID3 header level.
> > >
> > > Patrick
> >
> > I wrote Rich off list, but isn't there a way for some of the various
> > media types to directly specify where you want the content to start
> > playing? I thought both Real and MS had such capabilities. Either url
> > or playlist based? Then you'd treat the various segments just like any
> > other media type within Media RSS.
> >
> > My fear is the opposite of yours - turning Media RSS into something
> > much too heavyweight for the majority of users and needs.
> >
> >
>
>
>
>
>       See the Web&#39;s breaking stories, chosen by people like you. Check out
Yahoo! Buzz. http://in.buzz.yahoo.com/
>

> It's nice to see some people at Yahoo! taking an interest, but what
> happens when this group moves on as Jeremy did. The spec after
> Jeremy appeared to have no ownership at Yahoo! and went thru some
> hard times where nobody even knew what the namespace was or who to
> contact about clarification.

Wow, I've already been forgotten and Jeremy has taken my place in ownership
history.

I put in considerable work trying to turn the specification over to a standards
body (a version of w3c "lite") and we had our competitors in agreement with the
plan. However, things were in such a mess at Yahoo, it ultimately became
impossible... and then, as you said, I moved on to other things. Failing to turn
it over is still one of my biggest regrets.

Perhaps with the shakeups that have gone there, now things may be a little
easier to pull the trigger on things like this.

The only benefit I can see to keeping it with Yahoo is that it allowed us to
make fairly rapid changes when things were first ramping up. I'm not sure that's
as important any more.

Let me add my voice to Ryan's proposal to transfer the spec to the RSS Advisory
Board.
http://tech.groups.yahoo.com/group/rss-media/message/1193
It's nice to see some people at Yahoo! taking an interest, but what happens when
this group moves on as Jeremy did. The spec after Jeremy appeared to have no
ownership at Yahoo! and went thru some hard times where nobody even knew what
the namespace was or who to contact about clarification.
Thanks,

Randy Charles Morin
Chairman of The RSS Advisory Board
http://www.rssboard.org/

--- In rss-media@yahoogroups.com, "nilesh_gattani" <nileshg@...> wrote:
>
> Hi all,
>
> Please do let us know your feedback by end of the next week so that we can
freeze on the revised spec and publish it.
>
> Thanks
> -Nilesh
>
> --- In rss-media@yahoogroups.com, Sapna Chandiramani <sapna@> wrote:
> >
> > Folks,
> >
> > As promised, we wanted to share the new spec that we are working on with
you, so you can provide your feedback.
> >
> > It's version 1.5 uploaded here by Nilesh:
> > http://tech.groups.yahoo.com/group/rss-media/files/
> >
> > Do let us know what you think. This is still also being reviewed internally.
> >
> > Thanks,
> > Sapna
> >
> > ________________________________
> > From: Sapna Chandiramani
> > Sent: Wednesday, August 05, 2009 12:26 PM
> > To: 'rss-media@yahoogroups.com'
> > Cc: Chris Messina; David Recordan; Joseph Smarr; Allen Tom; Eran
Hammer-Lahav; kevinmarks@; Monica Keller; Mary Hodder
> > Subject: RE: [Fwd: Re: [rss-media] Specification currently lists the wrong
namespace]
> >
> > I don't think anyone at Yahoo! would have an issue of handing over the
custodianship to another body. Once you agree on who it should be, we can take
it forward.
> >
> > In the meantime, we will try to have the revised spec out for review to you
by the end of the week.
> >
> > -Sapna
> >
> >
> > ________________________________
> > From: rss-media@yahoogroups.com [mailto:rss-media@yahoogroups.com] On Behalf
Of Marc Canter
> > Sent: Tuesday, August 04, 2009 10:02 PM
> > To: rss-media@yahoogroups.com
> > Cc: Chris Messina; David Recordan; Joseph Smarr; Allen Tom; Eran
Hammer-Lahav; kevinmarks@; Monica Keller; Mary Hodder
> > Subject: Re: [Fwd: Re: [rss-media] Specification currently lists the wrong
namespace]
> >
> >
> >
> > I wouldn't necessarily trust the RSS advisory board any more than Yahoo.
> >
> > Besides - last I heard RSS 2.0 is already like 4 years old, so even talking
about versions .9 or .91 says it all.
> >
> > How 'bout you think about combining Media RSS with the efforts on-going
efforts behind Activity Streams and DiSO?
> >
> > These folks are state-of-the-art and they've been talking about media
meta-data - so NOW is the time to converge Media RSS with those efforts and get
these schemas in sync with microformats, etc.
> >
> > IMHO
> >
> > - marc
> > On Tue, Aug 4, 2009 at 11:53 AM, Ryan Parman
<ryan.lists.warpshare@<mailto:ryan.lists.warpshare@>> wrote:
> >
> > Sapna, et al:
> >
> > Several months back, there was discussion about placing the custodianship of
the Media RSS spec with the RSS Advisory Board. The folks at Yahoo! at the time
had consented that it was a good idea (I believe this was Jeremy Zawdony, IIRC),
but there never seemed to be any forward progress on that initiative.
> >
> > My concern stems from the fact that the Media RSS spec has been
broken/incorrect multiple times now under Yahoo!'s custodianship. This is a spec
that many people depend on, and speaking as the developer of the SimplePie RSS
parser, arbitrarily changing the namespace URL substantially affects our ability
to handle Media RSS feeds. (We already have to normalize the two different Media
RSS namespace URLs that are floating around: one with, and one without the
trailing slash -- which was broken for over a year.)
> >
> > I would really like to see the RSS Advisory Board pass a resolution to
publish the namespace documentation on its site with the proper longtime
namespace URI. Netscape trusted the board to oversee RSS 0.90 and RSS 0.91, and
I would hope that Yahoo! would be able to see that this transfer of
custodianship would be a Good Thing(tm) for the Media RSS community.
> >
> > Future changes to the spec could be handled by the Media RSS community, of
which Yahoo! and others could be a part.
> >
> > Thoughts?
> >
> >
> >
> > On Jul 28, 2009, at 12:52 AM, Sapna Chandiramani wrote:
> >
> >
> > Folks,
> >
> > I apologize for the issues on behalf of Yahoo.
> > There were indeed some problems with the spec. This happened when we were
moving the spec to the Video Search servers so it would be easier to respond to
issues and requests henceforth.
> >
> > In any case, we have reverted back the spec. We are also working on a newer
version of the spec that addresses some concerns this group had pointed out
earlier, as well as some enhancements that we felt would be good to have.
> >
> > We will send that out for review to you soon.
> >
> > Thanks,
> > Sapna
> >
> > -------- Original Message --------
> > Subject: Re: [rss-media] Specification currently lists the wrong namespace
> > Date: Tue, 21 Jul 2009 01:17:48 +0530
> > From: Joly MacFie <joly@<mailto:joly%40punkcast.com>>
> > Reply-To: rss-media@yahoogroups.com<mailto:rss-media%40yahoogroups.com>
<rss-media@yahoogroups.com<mailto:rss-media%40yahoogroups.com>>
> > To: rss-media@yahoogroups.com<mailto:rss-media%40yahoogroups.com>
<rss-media@yahoogroups.com<mailto:rss-media%40yahoogroups.com>>
> > References: <h421vv+3t1f@<mailto:h421vv%2B3t1f%40eGroups.com>>
> >
<2A6EB872-D3DE-4B36-9206-67902504C3A1@<mailto:2A6EB872-D3DE-4B36-9206-67902504C3\
A1%40gmail.com>>
> >
> > Earlier discussion:
> >
http://tech.groups.yahoo.com/group/rss-media/msearch?query=slash&submit=Search&c\
harset=ISO-8859-1
> >
<http://tech.groups.yahoo.com/group/rss-media/msearch?query=slash&submit=Search&\
charset=ISO-8859-1>
> >
> > Yahoo's neglect is a shame. Wasn't there some talk of moving it out of
> > their control?
> >
> > joly
> >
> > On Mon, Jul 20, 2009 at 1:52 PM, Ryan Parman
> > <ryan.lists.warpshare@<mailto:ryan.lists.warpshare%40gmail.com>
<mailto:ryan.lists.warpshare@<mailto:ryan.lists.warpshare%40gmail.com>>>
> > wrote:
> >
> > It looks like Yahoo once again arbitrarily changed the spec without
> > telling anybody.
> >
> > As of the last update that anybody was aware of, we had:
> >
> > 03/12/2008 - Namespace corrections: [1.1.2]
> >
> > * Added trailing slash to namespace
> >
> > The correct namespace *should* be exactly what you posted.
> > Apparently, Yahoo thought it'd be a good idea to change the
> > namespace again and break all sorts of parsing software. It is
> > embarrassing how badly they've bungled this spec.
> >
> > Once upon a time it fell to Jeremy Zawdony, but he's left Yahoo
> > since then. From what I can tell, nobody at Yahoo is paying
> > attention to this spec.
> >
> > On Jul 20, 2009, at 8:20 AM, James Abley wrote:
> >
> > > Hi,
> > >
> > > I'm putting http://search.yahoo.com/mrss/
> > > <http://search.yahoo.com/mrss/> into my browser, which used to
> > > display the spec and have the correct namespace on the page. At
> > > the moment, I'm getting a 302 back to
> > >
> > > Location: http://video.search.yahoo.com/mrss
> > > <http://video.search.yahoo.com/mrss>
> > >
> > > and that URL is used as the namespace URI in the rendered
> > > specification.
> > >
> > > Anyone else noticed this and know who to raise it with? I don't
> > > want any more ambiguity in the world as to the correct namespace
> > > URI for this extension!
> > >
> > > Cheers,
> > >
> > > James
> > >
> >
> > --
> > ----------------------------------------------------------
> > Joly MacFie 917 442 8665 Skype:punkcast
> > WWWhatsup NYC - http://wwwhatsup.com <http://wwwhatsup.com>
> > http://pinstand.com <http://pinstand.com> - http://punkcast.com
> > <http://punkcast.com>
> > ----------------------------------------------------------
> >
>

Hi all,

Please do let us know your feedback by end of the next week so that we can
freeze on the revised spec and publish it.

Thanks
-Nilesh

--- In rss-media@yahoogroups.com, Sapna Chandiramani <sapna@...> wrote:
>
> Folks,
>
> As promised, we wanted to share the new spec that we are working on with you,
so you can provide your feedback.
>
> It's version 1.5 uploaded here by Nilesh:
> http://tech.groups.yahoo.com/group/rss-media/files/
>
> Do let us know what you think. This is still also being reviewed internally.
>
> Thanks,
> Sapna
>
> ________________________________
> From: Sapna Chandiramani
> Sent: Wednesday, August 05, 2009 12:26 PM
> To: 'rss-media@yahoogroups.com'
> Cc: Chris Messina; David Recordan; Joseph Smarr; Allen Tom; Eran Hammer-Lahav;
kevinmarks@...; Monica Keller; Mary Hodder
> Subject: RE: [Fwd: Re: [rss-media] Specification currently lists the wrong
namespace]
>
> I don't think anyone at Yahoo! would have an issue of handing over the
custodianship to another body. Once you agree on who it should be, we can take
it forward.
>
> In the meantime, we will try to have the revised spec out for review to you by
the end of the week.
>
> -Sapna
>
>
> ________________________________
> From: rss-media@yahoogroups.com [mailto:rss-media@yahoogroups.com] On Behalf
Of Marc Canter
> Sent: Tuesday, August 04, 2009 10:02 PM
> To: rss-media@yahoogroups.com
> Cc: Chris Messina; David Recordan; Joseph Smarr; Allen Tom; Eran Hammer-Lahav;
kevinmarks@...; Monica Keller; Mary Hodder
> Subject: Re: [Fwd: Re: [rss-media] Specification currently lists the wrong
namespace]
>
>
>
> I wouldn't necessarily trust the RSS advisory board any more than Yahoo.
>
> Besides - last I heard RSS 2.0 is already like 4 years old, so even talking
about versions .9 or .91 says it all.
>
> How 'bout you think about combining Media RSS with the efforts on-going
efforts behind Activity Streams and DiSO?
>
> These folks are state-of-the-art and they've been talking about media
meta-data - so NOW is the time to converge Media RSS with those efforts and get
these schemas in sync with microformats, etc.
>
> IMHO
>
> - marc
> On Tue, Aug 4, 2009 at 11:53 AM, Ryan Parman
<ryan.lists.warpshare@...<mailto:ryan.lists.warpshare@...>> wrote:
>
> Sapna, et al:
>
> Several months back, there was discussion about placing the custodianship of
the Media RSS spec with the RSS Advisory Board. The folks at Yahoo! at the time
had consented that it was a good idea (I believe this was Jeremy Zawdony, IIRC),
but there never seemed to be any forward progress on that initiative.
>
> My concern stems from the fact that the Media RSS spec has been
broken/incorrect multiple times now under Yahoo!'s custodianship. This is a spec
that many people depend on, and speaking as the developer of the SimplePie RSS
parser, arbitrarily changing the namespace URL substantially affects our ability
to handle Media RSS feeds. (We already have to normalize the two different Media
RSS namespace URLs that are floating around: one with, and one without the
trailing slash -- which was broken for over a year.)
>
> I would really like to see the RSS Advisory Board pass a resolution to publish
the namespace documentation on its site with the proper longtime namespace URI.
Netscape trusted the board to oversee RSS 0.90 and RSS 0.91, and I would hope
that Yahoo! would be able to see that this transfer of custodianship would be a
Good Thing(tm) for the Media RSS community.
>
> Future changes to the spec could be handled by the Media RSS community, of
which Yahoo! and others could be a part.
>
> Thoughts?
>
>
>
> On Jul 28, 2009, at 12:52 AM, Sapna Chandiramani wrote:
>
>
> Folks,
>
> I apologize for the issues on behalf of Yahoo.
> There were indeed some problems with the spec. This happened when we were
moving the spec to the Video Search servers so it would be easier to respond to
issues and requests henceforth.
>
> In any case, we have reverted back the spec. We are also working on a newer
version of the spec that addresses some concerns this group had pointed out
earlier, as well as some enhancements that we felt would be good to have.
>
> We will send that out for review to you soon.
>
> Thanks,
> Sapna
>
> -------- Original Message --------
> Subject: Re: [rss-media] Specification currently lists the wrong namespace
> Date: Tue, 21 Jul 2009 01:17:48 +0530
> From: Joly MacFie <joly@...<mailto:joly%40punkcast.com>>
> Reply-To: rss-media@yahoogroups.com<mailto:rss-media%40yahoogroups.com>
<rss-media@yahoogroups.com<mailto:rss-media%40yahoogroups.com>>
> To: rss-media@yahoogroups.com<mailto:rss-media%40yahoogroups.com>
<rss-media@yahoogroups.com<mailto:rss-media%40yahoogroups.com>>
> References: <h421vv+3t1f@...<mailto:h421vv%2B3t1f%40eGroups.com>>
>
<2A6EB872-D3DE-4B36-9206-67902504C3A1@...<mailto:2A6EB872-D3DE-4B36-9206-6790250\
4C3A1%40gmail.com>>
>
> Earlier discussion:
>
http://tech.groups.yahoo.com/group/rss-media/msearch?query=slash&submit=Search&c\
harset=ISO-8859-1
>
<http://tech.groups.yahoo.com/group/rss-media/msearch?query=slash&submit=Search&\
charset=ISO-8859-1>
>
> Yahoo's neglect is a shame. Wasn't there some talk of moving it out of
> their control?
>
> joly
>
> On Mon, Jul 20, 2009 at 1:52 PM, Ryan Parman
> <ryan.lists.warpshare@...<mailto:ryan.lists.warpshare%40gmail.com>
<mailto:ryan.lists.warpshare@...<mailto:ryan.lists.warpshare%40gmail.com>>>
> wrote:
>
> It looks like Yahoo once again arbitrarily changed the spec without
> telling anybody.
>
> As of the last update that anybody was aware of, we had:
>
> 03/12/2008 - Namespace corrections: [1.1.2]
>
> * Added trailing slash to namespace
>
> The correct namespace *should* be exactly what you posted.
> Apparently, Yahoo thought it'd be a good idea to change the
> namespace again and break all sorts of parsing software. It is
> embarrassing how badly they've bungled this spec.
>
> Once upon a time it fell to Jeremy Zawdony, but he's left Yahoo
> since then. From what I can tell, nobody at Yahoo is paying
> attention to this spec.
>
> On Jul 20, 2009, at 8:20 AM, James Abley wrote:
>
> > Hi,
> >
> > I'm putting http://search.yahoo.com/mrss/
> > <http://search.yahoo.com/mrss/> into my browser, which used to
> > display the spec and have the correct namespace on the page. At
> > the moment, I'm getting a 302 back to
> >
> > Location: http://video.search.yahoo.com/mrss
> > <http://video.search.yahoo.com/mrss>
> >
> > and that URL is used as the namespace URI in the rendered
> > specification.
> >
> > Anyone else noticed this and know who to raise it with? I don't
> > want any more ambiguity in the world as to the correct namespace
> > URI for this extension!
> >
> > Cheers,
> >
> > James
> >
>
> --
> ----------------------------------------------------------
> Joly MacFie 917 442 8665 Skype:punkcast
> WWWhatsup NYC - http://wwwhatsup.com <http://wwwhatsup.com>
> http://pinstand.com <http://pinstand.com> - http://punkcast.com
> <http://punkcast.com>
> ----------------------------------------------------------
>