Loading ...
Sorry, an error occurred while loading the content.

RE: [rss-media] Digest Number 37

Expand Messages
  • vlemx
    I d sure like to convert this to a java script for may web page--any ideas? Free Service to Display RSS PR Leap (press release) - Chula Vista,CA,USA
    Message 1 of 1 , Feb 24, 2005
    • 0 Attachment
      I'd sure like to convert this to a java script for may web page--any ideas?
      Free Service to Display RSS
      PR Leap (press release) - Chula Vista,CA,USA
      RSS2HTML.com displays RSS feeds as web pages. In three short steps site
      visitors can convert their RSS feed, into a viewable web page. ...

      Bag Borrow or Steal

      -----Original Message-----
      From: rss-media@yahoogroups.com [mailto:rss-media@yahoogroups.com]
      Sent: Thursday, February 24, 2005 7:34 PM
      To: rss-media@yahoogroups.com
      Subject: [rss-media] Digest Number 37

      There are 4 messages in this issue.

      Topics in this digest:

      1. Re: Latest revision up...
      From: daviddhall@...
      2. Re: Embedding rss-media in HTML/XHTML?
      From: daviddhall@...
      3. Re: Latest revision up...
      From: daviddhall@...
      4. Re: Latest revision up...
      From: Mike Linksvayer <ml@...>


      Message: 1
      Date: Thu, 24 Feb 2005 20:04:28 -0000
      From: daviddhall@...
      Subject: Re: Latest revision up...

      "Markus Strickler" <mstrickler@g...> wrote:

      > As long as the spec does not explicitly forbid it, I would just add
      them. But then the rss media spec could be somewhat more clear
      > about it.
      > Along these lines what would be the difference between:
      > <media:content url="someurl"> <media:title>Title</media:title>
      > </media:content>
      > and
      > <media:content url="abcd">
      > <dc:title>Title</dc:title>
      > </media:content>
      > (given that media and dc are declared)

      Both should theoretically work, but we'd of course prefer
      <media:title>. As a consumer of the feed, we can make sure to
      properly account for Dublin Core's elements, but if we try to go
      about supporting all the various flavors of namespaces, things are
      likely to get dropped.

      When in doubt, use the Media RSS elements. If nothing fits, let us
      know and we can try to add it. And, of course, feel free to use any
      namespaces you want - I just want to make sure we know about them so
      we utilize their values.

      > That's again the different semantics. If you think item = enclosure
      the item's title applies to the enclosure and you won't need a
      > separate title.

      Yes. I really plan on explaining this fully at a later time. For now,
      I don't want to dig into to much if we can avoid it. (My current
      thinking is the spec will guide people to utilize Media RSS in the
      scenarios of blog style syndication, complete media dumps (where
      item=enclosure), etc. )


      Message: 2
      Date: Thu, 24 Feb 2005 20:06:05 -0000
      From: daviddhall@...
      Subject: Re: Embedding rss-media in HTML/XHTML?

      my.yahoo.com will be a consumer of any Media RSS enabled feed, so I
      guess the answer is yes, that it's been considered. From my
      understanding, the way the current spec is laid out, there shouldn't
      be too many problems. Couple issues of course, but nothing that can't
      be sorted out.

      --- In rss-media@yahoogroups.com, Michael Sullivan <sulleleven@g...>
      > you would just build a php script to parse the feed and transform to
      > html... using some template variables you would create.
      > On Wed, 23 Feb 2005 20:14:39 -0500, Bob Wyman <bob@w...> wrote:
      > >
      > > I would like to be able to embed rss-media tags, or something
      very much like
      > > them, in HTML/XHTML web pages. Potentially, this would include
      > > them in the HTML that is carried in an RSS description or as
      content in an
      > > Atom entry.
      > >
      > > With a small bit of coding, I should be able to teach my browser
      and/or news
      > > aggregator to notice these embedded tags and treat them
      specially. For
      > > instance, to display an icon where they appear or let me click on
      them to
      > > play or copy the media. I think that if this data could be
      embedded in pages
      > > (perhaps in hidden divs) and in close proximity to text that
      talks about the
      > > media, it would result in a much more natural interface. (Note: I
      am not
      > > suggesting that the current enclosure-like mechanism is not
      useful.) It
      > > would also mean that the HTML representation of my blog could be
      > > naturally aligned with my blog's feed. (i.e. I would use the same
      HTML in
      > > the feed's description field as I would display on the site.)
      > >
      > > Has any consideration or thought been given to embedding this
      stuff in HTML
      > > rather then just as an extension to RSS's item element? My
      apologies if this
      > > has been discussed before, I have only reviewed a portion of the
      > > history.
      > >
      > > bob wyman
      > >
      > >
      > > Yahoo! Groups Links
      > >
      > >
      > >
      > >
      > >
      > --
      > ~|~|~|~|~|~|~|~|~|~|~|~|~|~|~
      > i n t e r d i g i t a t e . c o m
      > =====================


      Message: 3
      Date: Thu, 24 Feb 2005 20:11:34 -0000
      From: daviddhall@...
      Subject: Re: Latest revision up...

      "Markus Strickler" <mstrickler@g...> wrote:
      > consider using all lower case. Not everyone cares about XML
      attribute names being case sensitive, so you might probably have to
      > expect filessize and isdefault in feeds anyway.

      Pondering that one...

      > I'm still missing a way to specify if a file is downloadable or not.
      > What was the reason not to introduce a boolean attribute "streamed"

      I guess I just didn't understand the use cases for it. I thought I
      replied on this topic awhile back. Shoot me an email directly on
      this, davidh@...

      > What's the default for expression? full?

      I'll fix the spec to explain what the assumed defaults will be.

      > media:text
      > Allows the inclusion of a text transcript, closed captioning, or
      lyrics of the media content.
      > Is this an exclusive list? i.E. a simple description of the
      media:content would not be allowed?

      Correct. Although, I'm guessing it'll be misused sometimes.

      > Where is the difference to using a group and one content for say
      the song as mp3 and one for the song as a plain text file?

      Confused on what the question is. Can you restate?

      > If you have more than one group or content in an item, is a
      sequence implied?

      Good point. In my mind, yes. I'll add that to the spec.



      Message: 4
      Date: Thu, 24 Feb 2005 18:26:33 -0500
      From: Mike Linksvayer <ml@...>
      Subject: Re: Latest revision up...

      On Wed, Feb 23, 2005 at 06:51:18AM -0000, daviddhall@... wrote:
      > 3. Added the optional <media:md5> so that any clients, etc wanting to
      > do binary detection/sharing (or whatever else we aren't thinking of)
      > at least has the possibility of doing so.

      Use of MD5 is ill-advised, see for example

      If you want to hardcode a hash algorithm I'd suggest <media:sha1>
      (SHA1 is MD5's successor, and SHA1 may be in dangerous territory

      However, why not something like <media:cid> (for Content ID), with
      values like urn:md5:{32 char hexstring}, urn:sha1:{32 char
      base32string}, etc? This would accomodate any hashes or other
      identifiers used now or in the future.

      > This generated discussion
      > on our end on how people anticipate creating a hash on streamable
      > media.

      I don't know much about streaming technology. Assuming that it
      doesn't necessarily deliver to the client bit for bit what is on
      the server (to deal with latency or whatever) a full content hash
      isn't going to be very useful. However, a hash tree
      could be useful in streaming contexts, and a <media:cid> element
      would allow publishing arbitrary portions of a hash tree.

      > Any thoughts on what people are most likely going to want to
      > do for that type of file? I have some guesses but most likely am
      > wrong. I would guess that since the publisher most likely has access
      > to the raw file that is being used for the stream, this is what they
      > would fingerprint? If I get some feedback on that, I can add a bit
      > more info on the element to help guide people to correctly use it.

      However, having a hash would be useful in podcasting type situations
      where the client is expected to download the entire file bit-for-bit.
      The hash can be used by the client to verify that they've downloaded
      what they expect, and if they have their downloads handled by a P2P
      client the client could attempt to swarm download from similar
      clients, offloading bandwidth from the server. (I hesitate to point
      out that the client could also check the hash against a database like
      http://bitzi.com to see if anyone had reported the file as malware
      or similar.)

      Mike Linksvayer


      Yahoo! Groups Links


      No virus found in this incoming message.
      Checked by AVG Anti-Virus.
      Version: 7.0.300 / Virus Database: 266.4.0 - Release Date: 2/22/2005

      No virus found in this outgoing message.
      Checked by AVG Anti-Virus.
      Version: 7.0.300 / Virus Database: 266.4.0 - Release Date: 2/22/2005
    Your message has been successfully submitted and would be delivered to recipients shortly.