Um, don't take this the wrong way, but may I ask whether the spec is
fixed in stone?  There are aspects of it which could conceivably
benefit from further development.

Thanks.

- Lucas Gonze

Reading through the spec, I have some questions/remarks:

1. it is unclear to me what is relationship between existing
"enclosure" element and new "media:content". Does it replace or
supplement "enclosure"? In first example you use "enclosure" while in
others you have "media:content" without "enclosure"

2. In example 1 you use non-standard "duration" attribute in
"enclosure". This document does not conform RSS 2 spec. I guess you
can add your attribute using different namespace, but not in default
one.

3. In section "Optional elements" you state: "The following elements
are optional and can either be a sub-element of <item>, <enclosure>,
or <media:content>." I do not think you can add elements under
"enclosure" without breaking RSS 2.0 spec compatibility.

Sincerely,
Vadim

P.S. Related work:
http://www.crocodile.org/lord/RSSenclosures/RSSenclosures.pdf

How about posting links to spec's, background, etc. in the
group's "Links" page?

Hey Lucas - funny meeting you here.

:-)


No I don't think this spec is fixed in stone.  That's why they're
inviting us here.

:-)

OK so Here we go,
with another show
of a punky funky riddim
that inhabits my soul.

Of video we seek,
a grand behind the scenes peek
not a poke or inhibition that
inspires this geek

So I beseech to you,
that we boogaloo
and make this namespace rocking rover
to define our poo.

- marc canter - on the entrance of Yahoo into this grand chess game.

--- In rss-media@yahoogroups.com, "lucas_gonze" <lucas.gonze@g...>
wrote:
>
> Um, don't take this the wrong way, but may I ask whether the spec
is
> fixed in stone?  There are aspects of it which could conceivably
> benefit from further development.
>
> Thanks.
>
> - Lucas Gonze

Hello,

I wanted to introduce myself. I am part of a team developing an
opensource video aggregator called ANT ("ANTs Not Television"). We
plan to release our alpha version soon. For more info, visit:
http://www.antnottv.org

Needless to say, I'm very interested in videoblogging and media
syndication via RSS. Want to learn more about Media RSS, but I think
the first step will be learning how to make this easier for content
authors to provide in their RSS feeds. Right now, enclosures are still
very difficult for the average user.

Look forward to learning more here.

-Joshua Kinberg

Hi folks.

Quick question: shouldn't the attributes be namespace-qualified to be
legal in an RSS 2.0 document?

Cheers,
Danny.

Glad to see this effort. This is something I would be very interested
in supporting this in WordPress[1] if it were to address the
accessibility concerns that nothing else I've seen so far has.

Fortunately, someone has done the hard work for us already:

http://www.w3.org/TR/REC-html40/struct/objects.html#h-13.3

Notice some similarities with <media:content>?

[1] http://wordpress.org/

Hello!

My name is August Trometer, the creator and co-developer of iPodderX,
the podcasting
client for the Mac. The new meda module looks very interesting, and I
like some of what
it's trying to accomplish.

I do have one question: are mutiple files allowed in a single <item>?
While the FAQ shows
that variations of the same file are permissible (such as different
quality levels), it does not
mention files that are different but related.

For example, someone might include show notes along with an audio
file.

Thanks!

August Trometer
iPodderX.com

Ok, I couldn't get my head around the namespace spec+errata, so
decided to try a little code, put my trust in Sun instead. I'm still
not 100% certain, but it does still look to me like the lack of prefix
on the attributes is a bug. I used SAX2 in JDK 1.4, the handler being:

   public void startElement(String namespaceURI, String localName,
       String qName, Attributes attributes) {
     System.out.println("\nElement ns = '" + namespaceURI+"' name = '"
         + localName+"'");
     for (int i = 0; i < attributes.getLength(); i++) {
       System.out.println("attr ns = '" + attributes.getURI(i) + "' name = '"
           + attributes.getLocalName(i) + "'");
     }
   }

Running this on http://tools.search.yahoo.com/mrss/mrss-4.xml which
contains lines like:

<media:content url="http://www.foo.com/song128kbps.mp3"
fileSize="2000" bitrate="128" type="audio/mpeg" expression="full">

yielded:

Element ns = '' name = 'rss'
attr ns = '' name = 'version'

Element ns = '' name = 'channel'

Element ns = '' name = 'title'

Element ns = '' name = 'link'

Element ns = '' name = 'description'

Element ns = '' name = 'item'

Element ns = '' name = 'title'

Element ns = '' name = 'link'

Element ns = 'http://docs.yahoo.com/mediaModule' name = 'content'
attr ns = '' name = 'url'
attr ns = '' name = 'fileSize'
attr ns = '' name = 'bitrate'
attr ns = '' name = 'type'
attr ns = '' name = 'isDefault'
attr ns = '' name = 'expression'

Element ns = 'http://docs.yahoo.com/mediaModule' name = 'content'
attr ns = '' name = 'url'
attr ns = '' name = 'fileSize'
attr ns = '' name = 'bitrate'
attr ns = '' name = 'type'
attr ns = '' name = 'expression'

Element ns = 'http://docs.yahoo.com/mediaModule' name = 'content'
attr ns = '' name = 'url'
attr ns = '' name = 'fileSize'
attr ns = '' name = 'bitrate'
attr ns = '' name = 'type'
attr ns = '' name = 'expression'

Element ns = 'http://docs.yahoo.com/mediaModule' name = 'people'

Element ns = 'http://docs.yahoo.com/mediaModule' name = 'category'

On Thu, 16 Dec 2004 14:01:02 EST, Svgdeveloper@...
<Svgdeveloper@...> wrote:

>  Aren't namespaces in XML wonderful? :)

Indeed they are!

Cheers,
Danny.

--

http://dannyayers.com

Hello all and welcome to the Media RSS discussion forum.

We just wanted to put a quick post on here while the dust is still
settling.

First of all, thanks for the interest in Media RSS. Our goal for this
forum is to improve upon our original draft so that it supports the
broad range of media syndication applications. We feel that there is
a strong need for this, not just at Yahoo!, but for the entire
community.

We are glad that some of you have already posted feedback about our
draft. We'll try to be a bit more responsive to the posts; but for
now, we want to assure you that these comments aren't going
to /dev/null. We realize that the true success for Media RSS is
taking into consideration the complaints, compliments, and
suggestions from people such as yourself.

Feel free to post any and all ideas on improvements... and please
invite others to join the forum.

More coming soon....

David Hall
Yahoo! Search

--- In rss-media@yahoogroups.com, marc@b... wrote:
>
> Hey Lucas - funny meeting you here.
>
> :-)


(^_^)  yo G!  Things are heating up for sure.  Incredible or what for
Yahoo to be getting in so deep?


> No I don't think this spec is fixed in stone.  That's why they're
> inviting us here.
...
> So I beseech to you,
> that we boogaloo
> and make this namespace rocking rover
> to define our poo.

Let's go, then.  ...wish I could make my comments rhyme.

...
"playerHeight is the height of the window that the playerUrl should be
opened in. It is an optional attribute.

playerWidth is the width of the window that the playerUrl should be
opened in. It is an optional attribute"

It seems to me that this info would be more useful if expressed in
terms of metadata.  That is, it should be the size of the movie,
rather than the size of the player window.  I suggest this change:
   "height is the height of the media item"

(and ditto for playerWidth)

I have many other thoughts, but will stick to just this one to see how
things go.

- Lucas

Hi Vadim -

Here's the answers to your questions/comments:

1. For simplicity sake, we removed any notion of a relationship
between the "enclosure" element and our proposed "media:content".
While their general desires are related, data is not shared between
the two. Our suggestion is that if enclosures don't allow you to
provide all the information you would like, you should choose to also
include a media:content element. Both can be used at the same time
and can be redundant. In fact, regardless of Yahoo!, it might be wise
to continue to do so in order to support existing RSS clients.

We included an example of enclosures because we plan to support
enclosures for the long term. It serves it's purpose of providing a
very simple method of attaching a media object to an "item".

2. This was a silly mistake in one of our revisions that was
unfortunatly pushed live. Thank you for pointing it out. It's been
fixed and is waiting to be published.

3. Yes, another mistake on our part. This is also corrected.

We'll review your "Enhanced Enclosures Support" document more
thoroughly as soon as we can get some time. A quick read of it was
interesting, and there are similar challenges in it that we *wanted*
to address. The difficulty is trying to balance power with simplicity.

Which portions of your document do you feel that we really overlooked
in our draft? In other words, what should we really focus on solving?

Thanks again for your quick feedback-

David Hall
Yahoo! Search

--- In rss-media@yahoogroups.com, lord@c... wrote:
>
> Reading through the spec, I have some questions/remarks:
>
> 1. it is unclear to me what is relationship between existing
> "enclosure" element and new "media:content". Does it replace or
> supplement "enclosure"? In first example you use "enclosure" while
in
> others you have "media:content" without "enclosure"
>
> 2. In example 1 you use non-standard "duration" attribute in
> "enclosure". This document does not conform RSS 2 spec. I guess you
> can add your attribute using different namespace, but not in default
> one.
>
> 3. In section "Optional elements" you state: "The following elements
> are optional and can either be a sub-element of <item>, <enclosure>,
> or <media:content>." I do not think you can add elements under
> "enclosure" without breaking RSS 2.0 spec compatibility.
>
> Sincerely,
> Vadim
>
> P.S. Related work:
> http://www.crocodile.org/lord/RSSenclosures/RSSenclosures.pdf

Hi Lucas -

The answer to your earlier question: No, it's not set in stone, and
we really would like some valuable feedback on how to improve it.

The main notion behind providing a "playerHeight" and "playerWidth"
is to allow another site launching your "playerUrl" to render it with
the correct browser height and width. While the actual media's height
and width are important values, we can extract this from the actual
content. Also, this sort of information isn't really necessary from
the end user's perspective in order to view the content - the end
user's client will determine the correct height and width. One of the
things we really tried to focus on for our first proposal was
allowing others to properly present the wide range of content that
could be available in an RSS feed.

We are definitely trying to figure out ways of allowing RSS feeds to
include such additional meta information without bloating the current
proposal too terribly much. This will prove to be very important in
the cases where only a playerUrl is provided.

In the near future, we'll post some of the ideas we had regarding
this to get your thoughts on it. We welcome your ideas as well.

Thanks-
David Hall
Yahoo! Search

--- In rss-media@yahoogroups.com, "lucas_gonze" <lucas.gonze@g...>
wrote:
>
> --- In rss-media@yahoogroups.com, marc@b... wrote:
> >
> > Hey Lucas - funny meeting you here.
> >
> > :-)
>
>
> (^_^)  yo G!  Things are heating up for sure.  Incredible or what
for
> Yahoo to be getting in so deep?
>
>
> > No I don't think this spec is fixed in stone.  That's why they're
> > inviting us here.
> ...
> > So I beseech to you,
> > that we boogaloo
> > and make this namespace rocking rover
> > to define our poo.
>
> Let's go, then.  ...wish I could make my comments rhyme.
>
> ...
> "playerHeight is the height of the window that the playerUrl should
be
> opened in. It is an optional attribute.
>
> playerWidth is the width of the window that the playerUrl should be
> opened in. It is an optional attribute"
>
> It seems to me that this info would be more useful if expressed in
> terms of metadata.  That is, it should be the size of the movie,
> rather than the size of the player window.  I suggest this change:
>   "height is the height of the media item"
>
> (and ditto for playerWidth)
>
> I have many other thoughts, but will stick to just this one to see
how
> things go.
>
> - Lucas

--- In rss-media@yahoogroups.com, daviddhall@y... wrote:
> The main notion behind providing a "playerHeight" and "playerWidth"
> is to allow another site launching your "playerUrl" to render it with
> the correct browser height and width.
...
> We are definitely trying to figure out ways of allowing RSS feeds to
> include such additional meta information without bloating the current
> proposal too terribly much. This will prove to be very important in
> the cases where only a playerUrl is provided.


Ok, so about the playerURL, this opens the question of what a player
with a URL is.  Why would a particular piece of media be accompanied
by the player?

Thanks.

- Lucas

>  Quick question: shouldn't the attributes be namespace-qualified to be
>  legal in an RSS 2.0 document?

After being told lots of stuff by lots of experts on the Atom list, my
conclusion is that this probably isn't a bug with a capital B,
although it still might well be advisable to qualify those attributes.

Thing is, by having no namespace itself but allowing the use of
namespaces, RSS 2.0 seems to be positioned in the least well-defined
place over the XML specs. Check this from the infoset doc [1]
[[
An attribute information item has the following properties:
    1. [namespace name] The namespace name, if any, of the attribute.
Otherwise, this property has no value.
...
]]
So it's either something or it isn't...

The problem in practice is that libraries (SAX in Java for a start)
may give that no-value namespace a value (the empty string) so it
*looks* like they are in the same namespace as RSS 2.0, with the
potential for clashes with e.g. @url as it is used in the <source>
element.

Cheers,
Danny.

[1] http://www.w3.org/TR/xml-infoset/#infoitem.attribute
--

http://dannyayers.com

I'm the author a podcasting client on the Pocket PC so my
perspective may be different than others.

In general, the attributes should be geared much more to the
*content* and not the *player*. Here are my specific comments:

1)

playerUrl - How is this going to be applicable to all client types?

You will never get podcasters to agree on the url even for any
specific device, or OS, or content type; even if they pick the same
player! Better to stick with mime types or content types and allow
the user and client determine the exact player.


2)

"playerHeight is the height of the window that the playerUrl should
be opened in. It is an optional attribute."
And similar with playerWidth.

Needs to be changed to contentHeight and describe the content, not
the player. The way this is worded, you would have to know all the
menus, interface elements, and skins used for the player.

It seems you are trying to define the User experience. Let the user
and client do that. The 'caster doesn't and couldn't know enough
about all the different clients to specify anything about the
player.

Concentrate on specifying and identifying the content.

3)

The feed should optionally be able specify enough information to A)
supply different alternative versions/formats of the content, B)
supply additional information/pointers to related information to the
content, and C) allow the client to automatically pick and download
the appropriate versions for the client and/or destination device.
D) supply multiple "sets" of content/information with each "set"
being identifyable.

As examples:

A) supplying a 640x480 WMV version of video1 and a 640x480 XViD
version of video1
B) supplying a playlist Url or production notes for video1.
C) supplying a 640x480 version of video1 and a 320x240 version of
video1.
D) supplying "top 3 video winners: video1, video2, video3 and their
production notes Url1, Url2, Url3.


This should be able to allow a vidcaster to supply multiple sizes,
as is often found on web sites supplying video. Traditionally, this
is identified by bitrate, but screen size is also an important
consideration. The reason bitrate has been important in the past is
the user is streaming it now and the file must fit within the
connection speed of the user. With 'casting, this is much less
relavent than user experience of framerate or content pixel size.

In addition, the specification should be flexible enough for a small
amount of client-side editing: video1 with audio track1 or audio
track2. Including identifying the "main" audio track (maybe
isDefault?). This needs to interoperate with identifying
different "sets" of information as in scenario "D".

4)

Like bitrate, the 'caster should be able to specify additional
parameters: framerate, (audio) frequency, contentHeight,
contentWidth all in support of the items in section 3 above. This
needs further thought to determine whether all attributes *can* be
pre-specified or if a generic way needs to be defined for specifying
various content parameters.

5)

Specify download method. The Url is not enough to uniquely specify
the download method, whether direct download over HTTP or BitTorrent
download or other P2P downloads. Alternative download methods need
to be able to be specified for a given piece of content for the
client/user to select (or pre-select).


Just thoughts off the top of my head. If you can make the
specification such that it can handle these situations, then I think
it will be able to handle the next "level" of content media delivery.

--- In rss-media@yahoogroups.com, Danny Ayers <danny.ayers@g...> wrote:

> After being told lots of stuff by lots of experts on the Atom list, my
> conclusion is that this probably isn't a bug with a capital B,
> although it still might well be advisable to qualify those attributes.

Actually, I think it is a must at least in the first example [1]. As
the specs for RSS 2.0 don't allow a non-namespaced duration attribute
on the enclosure element.

grtz, su.
--
[1] http://tools.search.yahoo.com/mrss/mrss-1.xml

On Fri, 17 Dec 2004 12:51:03 -0000, Suzan Foster <su@...> wrote:

> Actually, I think it is a must at least in the first example [1]. As
> the specs for RSS 2.0 don't allow a non-namespaced duration attribute
> on the enclosure element.

Aaa, now I'd missed that - I think you're right, that usage would be
over the line by any reasonable reckoning. If I understood Sam Ruby
correctly it'd definitely show as an error in the feedvalidator.


> [1] http://tools.search.yahoo.com/mrss/mrss-1.xml
>
>
>
> Yahoo! Groups Links
>
>
>
>
>


--

http://dannyayers.com

> > > Can't wait for Dave's reaction...
> >
> > A reaction[1] popped up in his rss feed last night. He didn't sound
> > like a happy camper about it.

To be honest part of my initial reaction wasn't that far removed from
Dave's. The way this apparently was developed behind closed doors then
presented as a fait accompli when there are active discussions here
and on the rss-dev lists seems very poor style. (Heh, I wouldn't
personally expect the "giants" to give me advance notification when
they moved in the RSS space, though given that I'm in the final stages
of a book on this stuff then it might well have been in their
interests ;-)

Yahoo's technical approach doesn't seem that unreasonable, one or two
tweaks. Give it a couple of weeks then do a bit of XSLT is my own
plan, see how well it all maps onto existing vocabularies.

Cheers,
Danny.

--

http://dannyayers.com

Hi Suzan -

I posted this in a reply to one of the other messages. We never
intended to alter the "enclosure" tag with the "duration" attribute.
It was basically a cut-n-paste mistake that somehow made it live.
It's been corrected but just hasn't been pushed out yet.

Thanks-
David Hall
Yahoo! Search

--- In rss-media@yahoogroups.com, "Suzan Foster" <su@i...> wrote:
>
> --- In rss-media@yahoogroups.com, Danny Ayers <danny.ayers@g...>
wrote:
>
> > After being told lots of stuff by lots of experts on the Atom
list, my
> > conclusion is that this probably isn't a bug with a capital B,
> > although it still might well be advisable to qualify those
attributes.
>
> Actually, I think it is a must at least in the first example [1]. As
> the specs for RSS 2.0 don't allow a non-namespaced duration
attribute
> on the enclosure element.
>
> grtz, su.
> --
> [1] http://tools.search.yahoo.com/mrss/mrss-1.xml

Hi Danny -

Thanks for all the follow ups on this. We'll investigate it further
as well. Certainly, without having to namespace all the attributes,
the spec looks a bit cleaner and less 'scary' for the average Joe...
but we also want to make sure that we don't break anything in the
process.

David Hall
Yahoo! Search

--- In rss-media@yahoogroups.com, Danny Ayers <danny.ayers@g...>
wrote:
> >  Quick question: shouldn't the attributes be namespace-qualified
to be
> >  legal in an RSS 2.0 document?
>
> After being told lots of stuff by lots of experts on the Atom list,
my
> conclusion is that this probably isn't a bug with a capital B,
> although it still might well be advisable to qualify those
attributes.
>
> Thing is, by having no namespace itself but allowing the use of
> namespaces, RSS 2.0 seems to be positioned in the least well-defined
> place over the XML specs. Check this from the infoset doc [1]
> [[
> An attribute information item has the following properties:
>    1. [namespace name] The namespace name, if any, of the attribute.
> Otherwise, this property has no value.
> ...
> ]]
> So it's either something or it isn't...
>
> The problem in practice is that libraries (SAX in Java for a start)
> may give that no-value namespace a value (the empty string) so it
> *looks* like they are in the same namespace as RSS 2.0, with the
> potential for clashes with e.g. @url as it is used in the <source>
> element.
>
> Cheers,
> Danny.
>
> [1] http://www.w3.org/TR/xml-infoset/#infoitem.attribute
> --
>
> http://dannyayers.com

Hi Danny -

We certainly understand the gut reactions of some that this might
appear to be some sort of irreversible specification that Yahoo! is
attempting to force upon the community. We want to assure you that
this is not the case. This is simply our proposal for trying to solve
the problem with embedding media within RSS.

I think Yahoo! was facing the same challenges that many have noted
before with RSS. And because of this, we decided to offer our first
stab at a solution to the public. One of the primary reasons for
publishing this draft *was* for the sole purpose of soliciting more
public feedback. We alone won't be able to anticipate everyone's
needs or desires.

I apologize for the "closed doors" feelings one might have. Hopefully
you understand a few of the issues we were dealing with when
attempting to do this.

Soo.... with that said, keep the feedback going. Everyone's comments
so far have been great.

David Hall
Yahoo! Search

--- In rss-media@yahoogroups.com, Danny Ayers <danny.ayers@g...>
wrote:
> > > > Can't wait for Dave's reaction...
> > >
> > > A reaction[1] popped up in his rss feed last night. He didn't
sound
> > > like a happy camper about it.
>
> To be honest part of my initial reaction wasn't that far removed
from
> Dave's. The way this apparently was developed behind closed doors
then
> presented as a fait accompli when there are active discussions here
> and on the rss-dev lists seems very poor style. (Heh, I wouldn't
> personally expect the "giants" to give me advance notification when
> they moved in the RSS space, though given that I'm in the final
stages
> of a book on this stuff then it might well have been in their
> interests ;-)
>
> Yahoo's technical approach doesn't seem that unreasonable, one or
two
> tweaks. Give it a couple of weeks then do a bit of XSLT is my own
> plan, see how well it all maps onto existing vocabularies.
>
> Cheers,
> Danny.
>
> --
>
> http://dannyayers.com

> Hi Danny -

Hi David, thanks for the response, nice to make your acquaintance. Fun
stuff you're doing!

> Thanks for all the follow ups on this. We'll investigate it further
> as well. Certainly, without having to namespace all the attributes,
> the spec looks a bit cleaner and less 'scary' for the average Joe...
> but we also want to make sure that we don't break anything in the
> process.

Hmm, less scary?

<rant>
Let's see, there's the specifications for HTTP, Unicode, XML, XML
Namespaces (+errata), HTML & XHTML, RFC 2396bis, The Nightmare on
RFC3023 Street, all the lesser demons like RFC2045, then there's
Fielding's thesis and now the webarch doc... That's leaving aside more
implementation-specific things like the behaviour of Apache etc,
escaping in MySQL, the endless quirks in the programming languages.
Just because some well-known specs sweep these under the carpet
doesn't mean they aren't all in some way underpinning Media RSS.
Hiding scariness may make for some happier kiddywinks, meanwhile
Freddy and Jason will be picking them off...

An average Joe may be able to slap a bit of US-ASCII in a text editor
and hope for the best, in fact it will probably work. But as a general
rule for specs, simple for simple's sake won't do much to avoid
breakage. Keep it as simple as possible, sure, but best not pretend it
can't get scary, IMHO.
</rant>

Cheers,
Danny.

--

http://dannyayers.com

I read a couple of the posts and there seems to be a little bit of
confusion on what exactly we were intending with that field. We'll
have to figure out a better way in our specification to make it more
clear on what our intention is for that attribute.

Essentially, player != client. Our playerUrl is just a normal web page
that shows the media content in the general sense of syndicated web
content. At this time, it's not a means of driving actual client
applications running on the end user's machine outside of the typical
sense of a web browser.

In discussing the needs with assorted partners, it became clear that
often (even at the time of RSS generation, believe it or not) a
direct link to the actual media content is unknown to them or cannot
be generated. This is because of security protections they have in
place, etc. And often, due to licensing reasons, they are unable to
reveal such links anyway.

Here's a live example of what a playerUrl might be:
http://nbc.com/nbc/Video/?c=The_Apprentice/appren_kelly_hired

Hopefully, that makes the reasoning a bit more clear. One of the
problems we want to solve is in the cases that a RSS feed can only
publish the playerUrl (for whatever reason). How do we efficiently
allow the feed to include all interesting meta data about the media
object (such as real height/width)? From the search perspective, we
want this information since we can't actually "touch" the media
object to determine it ourselves.

Solving this problem should also help actual alternative clients
using RSS.

David Hall
Yahoo! Search

On Fri, 17 Dec 2004 20:59:04 -0000, daviddhall@...
<daviddhall@...> wrote:

> I apologize for the "closed doors" feelings one might have. Hopefully
> you understand a few of the issues we were dealing with when
> attempting to do this.

Sure, fine, thanks. I think that dark moment has now passed ;-)

> Soo.... with that said, keep the feedback going.

Right...ok...oh,
        where o where to begin...

Now if I were in the position you're in, what I'd do is have a look at
how this media description material could be expressed in the more
general Resource Description Framework, specifically RDF/XML, even
more specifically RSS 1.0.

There are several reasons I'd suggest this, the big ones being -

* the (entity/relationship) modelling of the constructs in RDF is an
extremely good sanity check
* any future extensions (additional metadata) will be easier to build
* you'd enable a very wide range of interop (to pick one out of the
hat, the library community with Dublin Core)
* you'd get the RSS 1.0 and more general RDF communities onside
* you'd almost immediately be able to plug into some of the cool
hackishness around FOAF
* you'd be able to wear a "We're on the Semantic Web" button
* that time I would have spent on syntax-untangling will be devoted to
making a kitten happy instead

If you check recent archives of rss-dev, there's been quite a lot of
related discussion recently, and I'm sure there are plenty of people
around rss-dev (and www-rdf-interest and the foaf rdfweb-dev list)
that would be willing to help.

This isn't about RSS 1.0 vs RSS 2.0 or even vs Atom (that's a point,
any modelling you do would help use this in Atom as well). It doesn't
really matter if the feeds are predominantly RSS 2.0 or anything else
for that matter (Altogether now: "Syntax Doesn't Matter, We Have
XSLT..."). Just that in the headlong rush for rapid deployment you
bear in mind that there is an awful lot of low-hanging network-effect
fruit nearby, and virtually no effort or cost you can make it easier
to pick, in everyone's mutual interests.

I'd better stop before I start sounding like that Canter dude ;-)

Cheers,
Danny.


--

http://dannyayers.com

On Dec 17, 2004, at 10:29 PM, daviddhall@... wrote:

> Essentially, player != client. Our playerUrl is just a normal web page
> that shows the media content in the general sense of syndicated web
> content. At this time, it's not a means of driving actual client
> applications running on the end user's machine outside of the typical
> sense of a web browser.
>
> In discussing the needs with assorted partners, it became clear that
> often (even at the time of RSS generation, believe it or not) a
> direct link to the actual media content is unknown to them or cannot
> be generated. This is because of security protections they have in
> place, etc. And often, due to licensing reasons, they are unable to
> reveal such links anyway.
>
> Here's a live example of what a playerUrl might be:
> http://nbc.com/nbc/Video/?c=The_Apprentice/appren_kelly_hired

So basically you need a way to express that a resource has an url, but
that it isn't downloadable. Or to put it another way: you have a class
of resource which must be handled differently than a resource of class
Enclosure so that podcatchers aren't trying to download it in vain.
Correct?

grtz, su.

Well, mostly. Yes, in the sense that podcatchers shouldn't waste
their time downloading it because it's effectively useless to them.
The primary objective of the attribute is to allow owners of the RSS
feed to encourage the proper resolution of their media when being
viewed within a browser.

For instance, in the example I gave with the NBC Apprentice link, I
seriously doubt NBC would want to publicly expose a direct link to
the media object. They would prefer to have end users view it within
their video player - with all the additional html markup. And while
it can be argued that this still doesn't protect the stream fully,
large content providers are much more comfortable with this rather
than letting just anyone get directly at the url to the media object.

Ideally, from the search perspective, we'd much prefer that the
content provider include both a direct link (url) as well as a player
link (playerUrl). That way, we could harvest all the meta information
from the real content, while still delivering the experience to the
end user that the content provider prefers and/or requires.

From the perspective of what something might look like in a My Yahoo!
inclusion sort of way, I'd predict that you'd have the typical look
of current RSS feed inclusion. However, if the end user wanted to
click off and view the specific media attached to the item – they
would be sent to the value enclosed in the playerUrl attribute.

And of course, if the RSS feed creator doesn't care about such
notions of playerUrls, they would just not use the optional attribute.

It would be interesting if we could tie in the notion of
"transport"
that I saw in Vadim's Enhanced Enclosures support document.
The "transport" would be the method in which to view/get the
media
object. Whether it be bitTorrent, our playerUrl (html), or some other
alternative client or method.

David Hall
Yahoo! Search

--- In rss-media@yahoogroups.com, Suzan Foster <su@i...> wrote:
> On Dec 17, 2004, at 10:29 PM, daviddhall@y... wrote:
>
> > Essentially, player != client. Our playerUrl is just a normal web
page
> > that shows the media content in the general sense of syndicated
web
> > content. At this time, it's not a means of driving actual client
> > applications running on the end user's machine outside of the
typical
> > sense of a web browser.
> >
> > In discussing the needs with assorted partners, it became clear
that
> > often (even at the time of RSS generation, believe it or not) a
> > direct link to the actual media content is unknown to them or
cannot
> > be generated. This is because of security protections they have in
> > place, etc. And often, due to licensing reasons, they are unable
to
> > reveal such links anyway.
> >
> > Here's a live example of what a playerUrl might be:
> > http://nbc.com/nbc/Video/?c=The_Apprentice/appren_kelly_hired
>
> So basically you need a way to express that a resource has an url,
but
> that it isn't downloadable. Or to put it another way: you have a
class
> of resource which must be handled differently than a resource of
class
> Enclosure so that podcatchers aren't trying to download it in vain.
> Correct?
>
> grtz, su.

On Dec 18, 2004, at 12:52 AM, daviddhall@... wrote:

> It would be interesting if we could tie in the notion of
> "transport"
> that I saw in Vadim's Enhanced Enclosures support document.
> The "transport" would be the method in which to view/get the
> media
> object. Whether it be bitTorrent, our playerUrl (html), or some other
> alternative client or method.

Isn't that what you already get from the mime-type in the type
attribute?

grtz, su.