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

PHP wonks? Wordpress enclosure hack needed

Expand Messages
  • elefantman@ozemail.com.au
    So it seems WordPress generates enclosure code for every media file in your blog post. And this causes problems for some?/many?/most? readers/aggregators as
    Message 1 of 20 , May 30, 2005
      So it seems WordPress generates enclosure code for every media file in your blog post. And this causes problems for some?/many?/most? readers/aggregators as they only allow one enclosure.

      WordPress doesn't allow you to switch this feature off or delete the tags and judging by posts to the Wordpress forums the developers are giving no indication they're going to change it.

      Someone suggested hacking WordPress so it only spits out enclosure code where the rel="enclosure" attribute is used when linking to the media file. This makes sense to me.

      The .php file concerned seems to be "functions" in wpincludes but I'm not sure whether a fix would be as simple as altering that file. Can anyone see a straightforward coding solution?

      Waz
      www.crashtestkitchen.com


      This message was sent through MyMail http://www.mymail.com.au
    • Clint Sharp
      ... I ve never had a problem working around this by simply removing the extra custom fields. You still are unable, on Wordpress 1.5.1 to delete the extra
      Message 2 of 20 , May 30, 2005
        elefantman@... wrote:

        > So it seems WordPress generates enclosure code for every media file in
        > your blog post. And this causes problems for some?/many?/most?
        > readers/aggregators as they only allow one enclosure.
        >
        > WordPress doesn't allow you to switch this feature off or delete the
        > tags and judging by posts to the Wordpress forums the developers are
        > giving no indication they're going to change it.
        >
        > Someone suggested hacking WordPress so it only spits out enclosure
        > code where the rel="enclosure" attribute is used when linking to the
        > media file. This makes sense to me.
        >
        > The .php file concerned seems to be "functions" in wpincludes but I'm
        > not sure whether a fix would be as simple as altering that file. Can
        > anyone see a straightforward coding solution?
        >
        > Waz
        > www.crashtestkitchen.com
        >
        >
        > This message was sent through MyMail http://www.mymail.com.au
        >
        >
        I've never had a problem working around this by simply removing the
        extra custom fields. You still are unable, on Wordpress 1.5.1 to delete
        the extra custom fields?

        Clint
      • Joshua Kinberg
        An aggregator should not choke if you have multiple enclosures per item. It may not download all the enclosures though. -josh
        Message 3 of 20 , May 30, 2005
          An aggregator should not choke if you have multiple enclosures per item.
          It may not download all the enclosures though.

          -josh


          On 5/30/05, elefantman@... <elefantman@...> wrote:
          > So it seems WordPress generates enclosure code for every media file in your blog post. And this causes problems for some?/many?/most? readers/aggregators as they only allow one enclosure.
          >
          > WordPress doesn't allow you to switch this feature off or delete the tags and judging by posts to the Wordpress forums the developers are giving no indication they're going to change it.
          >
          > Someone suggested hacking WordPress so it only spits out enclosure code where the rel="enclosure" attribute is used when linking to the media file. This makes sense to me.
          >
          > The .php file concerned seems to be "functions" in wpincludes but I'm not sure whether a fix would be as simple as altering that file. Can anyone see a straightforward coding solution?
          >
          > Waz
          > www.crashtestkitchen.com
          >
          >
          > This message was sent through MyMail http://www.mymail.com.au
          >
          >
          >
          >
          >
          > Yahoo! Groups Links
          >
          >
          >
          >
          >
          >
          >
        • dnadig
          Huh. Wierd. I do enclosures by manually entering the custome field enclosure and the url I want. I ve never had it do anything automatically, nor would I
          Message 4 of 20 , May 30, 2005
            Huh. Wierd.

            I do enclosures by manually entering the custome field "enclosure" and
            the url I want. I've never had it do anything automatically, nor would
            I even know how. I can guarantee you though that even with mutliple
            links to other files, it only ever grabs the one I specifically link...
          • Clint Sharp
            ... This is a feature of Wordpress 1.5. It checks every full link (including http://) in a post and checks the mime-type. If any of them are video or audio
            Message 5 of 20 , May 30, 2005
              dnadig wrote:
              Huh. Wierd.

              I do enclosures by manually entering the custome field "enclosure" and
              the url I want.  I've never had it do anything automatically, nor would
              I even know how.  I can guarantee you though that even with mutliple
              links to other files, it only ever grabs the one I specifically link...


              This is a feature of Wordpress 1.5.  It checks every full link (including http://) in a post and checks the mime-type.  If any of them are video or audio types it'll add them as an enclosure automatically.

              Clint

            • dnadig
              This is wierd. I can tell you from my feed that if you enter enclosure manually, it s definately NOT adding any WMV files a second time (hey, that s a good
              Message 6 of 20 , May 31, 2005
                This is wierd. I can tell you from my feed that if you enter
                enclosure manually, it's definately NOT adding any WMV files a
                second time (hey, that's a good thing!)

                For what it's worth, most of the RSS wonkinators are pretty hardcore
                about the "there's only one enclosure for each item."

                http://www.reallysimplesyndication.com/2004/12/21

                There are many problems with multiple enclosures, not the least of
                which is that you can't seperately specify ANY metadata about the
                enclosure. The last thing you want to do is specify multiple
                formats of the same file as multiple enclosures (or even in the same
                feed). Can you imagine downloading 5 different versions of the same
                rocketboom episode just because you dragged the and feed in?

                And once these multiple enclosures are in, say, fireant, how is
                fireant supposed to know what to play when you click a title?



                --- In videoblogging@yahoogroups.com, Clint Sharp <clint@t...> wrote:
                > This is a feature of Wordpress 1.5. It checks every full link
                > (including http://) in a post and checks the mime-type. If any of
                them
                > are video or audio types it'll add them as an enclosure
                automatically.
                >
                > Clint
              • Andreas Haugstrup
                ... Dump the element and use Yahoo Media RSS. FureANT should have settings so the user can decide (Something like Prefer QT over WMV content and
                Message 7 of 20 , May 31, 2005
                  On Tue, 31 May 2005 13:27:42 +0200, dnadig <dnadig@...> wrote:

                  > And once these multiple enclosures are in, say, fireant, how is
                  > fireant supposed to know what to play when you click a title?

                  Dump the <enclosure> element and use Yahoo Media RSS. FureANT should have
                  settings so the user can decide (Something like "Prefer QT over WMV
                  content" and "Prefer video over other media").

                  - Andreas
                  --
                  <URL:http://www.solitude.dk/>
                  Commentary on media, communication, culture and technology.
                • dnadig
                  ... element and use Yahoo Media RSS. FureANT should have ... Sigh. The beauty of RSS lies in it s simplicity - I m already annoyed and frustrated
                  Message 8 of 20 , May 31, 2005
                    --- In videoblogging@yahoogroups.com, "Andreas Haugstrup" <> Dump the
                    <enclosure> element and use Yahoo Media RSS. FureANT should have
                    > settings so the user can decide (Something like "Prefer QT over WMV
                    > content" and "Prefer video over other media").

                    Sigh. The beauty of RSS lies in it's simplicity - I'm already annoyed
                    and frustrated by the number of feed-varient issues that are out
                    there. The single standard RSS enclosure tag work's REALLY well if
                    both sides just stick to the spec.

                    I'd much rather be able to simply subscribe to the feed I want (QT,
                    WMV, whatever) than rely on my specific aggregator's implementation of
                    a constantly-evolving Yahoo! spec. (last mod in February, but why
                    should I believe it will stay locked?)
                  • Frank Carver
                    ... I completely agree. IMHO the only good thing about the yahoo media feed stuff is that it s from Yahoo, and that has got people talking about this sort of
                    Message 9 of 20 , May 31, 2005
                      Tuesday, May 31, 2005, 1:14:50 PM, dnadig wrote:

                      > Sigh.  The beauty of RSS lies in it's simplicity - I'm already annoyed
                      > and frustrated by the number of feed-varient issues that are out
                      > there.  The single standard RSS enclosure tag work's REALLY well if
                      > both sides just stick to the spec.

                      > I'd much rather be able to simply subscribe to the feed I want (QT,
                      > WMV, whatever)

                      I completely agree. IMHO the only good thing about the yahoo media
                      feed stuff is that it's from Yahoo, and that has got people talking
                      about this sort of thing. The actual format seems really clunky, the
                      kind of thing people new to XML scribble down in a lunchtime.

                      Really, I feel that we should be pressing the blog software makers for
                      better support for multiple feeds, not multiple enclosures per post.

                      Imagine the wonderful world if (for example) Wordpress allowed the
                      site admin to simply configure multiple feeds such that one feed got
                      all the "raw" blog text with no enclosure processing, one feed got the
                      text and any WMV files as encloures, one feed got the text with any QT
                      files as enclosures. Maybe also feeds with a "preference", like one
                      that would take a QT as an enclosure only if the WMV was not available.
                      That way all a videoblogger would need to do would be to refer to
                      content in whatever formats he or she likes, and let the _subscribers_
                      choose which format they want.

                      In the real blue sky world, of course, the blog software would do
                      (on-the-fly-but-cached) format conversion too. So subscribers could
                      specify things like wrapper formats and codec/compression preferences
                      as part of the feed URL, and just get what they ask for.

                      Sigh.

                      --
                      Frank Carver http://www.makevideo.org.uk
                    • Joshua Kinberg
                      You can do this very easily with MovableType and the MTEnclosures plugin. You can create new RSS templates and edit a filter setting in the plugin tag to only
                      Message 10 of 20 , May 31, 2005
                        You can do this very easily with MovableType and the MTEnclosures plugin.
                        You can create new RSS templates and edit a filter setting in the
                        plugin tag to only create enclosures for certain mime-types (i.e. only
                        .mov, or only .wmv).

                        -Josh


                        On 5/31/05, Frank Carver <frank@...> wrote:
                        > Tuesday, May 31, 2005, 1:14:50 PM, dnadig wrote:
                        >
                        > > Sigh. The beauty of RSS lies in it's simplicity - I'm already annoyed
                        > > and frustrated by the number of feed-varient issues that are out
                        > > there. The single standard RSS enclosure tag work's REALLY well if
                        > > both sides just stick to the spec.
                        >
                        > > I'd much rather be able to simply subscribe to the feed I want (QT,
                        > > WMV, whatever)
                        >
                        > I completely agree. IMHO the only good thing about the yahoo media
                        > feed stuff is that it's from Yahoo, and that has got people talking
                        > about this sort of thing. The actual format seems really clunky, the
                        > kind of thing people new to XML scribble down in a lunchtime.
                        >
                        > Really, I feel that we should be pressing the blog software makers for
                        > better support for multiple feeds, not multiple enclosures per post.
                        >
                        > Imagine the wonderful world if (for example) Wordpress allowed the
                        > site admin to simply configure multiple feeds such that one feed got
                        > all the "raw" blog text with no enclosure processing, one feed got the
                        > text and any WMV files as encloures, one feed got the text with any QT
                        > files as enclosures. Maybe also feeds with a "preference", like one
                        > that would take a QT as an enclosure only if the WMV was not available.
                        > That way all a videoblogger would need to do would be to refer to
                        > content in whatever formats he or she likes, and let the _subscribers_
                        > choose which format they want.
                        >
                        > In the real blue sky world, of course, the blog software would do
                        > (on-the-fly-but-cached) format conversion too. So subscribers could
                        > specify things like wrapper formats and codec/compression preferences
                        > as part of the feed URL, and just get what they ask for.
                        >
                        > Sigh.
                        >
                        > --
                        > Frank Carver http://www.makevideo.org.uk
                        >
                        >
                        >
                        >
                        > Yahoo! Groups Links
                        >
                        >
                        >
                        >
                        >
                        >
                        >
                      • Andreas Haugstrup
                        ... No, the standard enclosure element doesn t work at all if both sides stick to the spec. The standard enclosure element only allows for one enclosure per
                        Message 11 of 20 , May 31, 2005
                          On Tue, 31 May 2005 14:14:50 +0200, dnadig <dnadig@...> wrote:

                          > Sigh. The beauty of RSS lies in it's simplicity - I'm already annoyed
                          > and frustrated by the number of feed-varient issues that are out
                          > there. The single standard RSS enclosure tag work's REALLY well if
                          > both sides just stick to the spec.

                          No, the standard enclosure element doesn't work at all if both sides stick
                          to the spec. The standard enclosure element only allows for one enclosure
                          per item, making the whole thing totally unfit for blogging. It's like
                          having a word processor that only allows you to use one picture per
                          document, or an e-mail client that only allows for one attached file per
                          e-mail. It's stupid, without vision and useless for blogs.

                          When Yahoo Media RSS (mRSS) was being drafted I lobbied for breaking it
                          into two specs. One for general enclosure structure - a bare minimum, and
                          another which contained the audio/video metadata. Unfortunately they
                          couldn't/wouldn't accomodate me. You can still see my proposal at: <URL:
                          http://www.solitude.dk/archives/20050208-0045/ >

                          What they did make sure of, and this is what makes mRSS the best thing to
                          hit RSS in a long time, was that all the audio/video specific data is
                          optional. If you read the spec you'll see that there are hardly any
                          mandatory elements in mRSS. That means the mRSS is *very* simple, and very
                          versatile. It *can* function as a basic enclosure structure where you can
                          attach any type of file, multiple files and in multiple versions.

                          mRSS fixes the one thing that makes the standard enclosure element unfit
                          for blogs: It allows for more than one enclosure per item. And it fixes an
                          issue that makes everyone's life easier: It allows for multiple versions
                          of the same enclosure (like an EPS and a PNG version of the same image.
                          One for print, one for web).

                          - Andreas
                          --
                          <URL:http://www.solitude.dk/>
                          Commentary on media, communication, culture and technology.
                        • Frank Carver
                          ... Hmm. I agree that there _might_ be situations where it would make sense to associate more than one enclosure with a blog post. I think it s a bit extreme
                          Message 12 of 20 , May 31, 2005
                            Tuesday, May 31, 2005, 2:52:20 PM, Andreas Haugstrup wrote:

                            > No, the standard enclosure element doesn't work at all if both sides stick 
                            > to the spec. The standard enclosure element only allows for one enclosure 
                            > per item, making the whole thing totally unfit for blogging. It's like 
                            > having a word processor that only allows you to use one picture per 
                            > document, or an e-mail client that only allows for one attached file per 
                            > e-mail. It's stupid, without vision and useless for blogs.

                            Hmm. I agree that there _might_ be situations where it would make sense
                            to associate more than one enclosure with a blog post. I think it's a
                            bit extreme to claim it as "useless for blogs", though. There's always
                            the option of posting several items at the same time.

                            One thing I think it's important to notice, is that so far _none_
                            of the suggestions (apart from the original one enclosure per entry)
                            contain any real concept of sequence. No kind of ordering or timestamp is
                            associated with enclosures, only with the RSS item as a whole.
                            If sequence is at all important, the only way is still one enclosure per RSS
                            item. More on this below.

                            > When Yahoo Media RSS (mRSS) was being drafted I lobbied for breaking it 
                            > into two specs. One for general enclosure structure - a bare minimum, and 
                            > another which contained the audio/video metadata. Unfortunately they 
                            > couldn't/wouldn't accomodate me. You can still see my proposal at: <URL: 
                            > http://www.solitude.dk/archives/20050208-0045/ >

                            Your proposal is interesting, but still suffers from some of the same
                            problems as mRSS. Assuming that the mime type of an enclosure is
                            enough to distinguish it fails even in your own examples. You write:

                            <enclosure title="Rocketboom: Casual Friday" xmlns="http://www.solitude.dk/syndication/enclosures/">
                            <link type="video/quicktime" length="100" url="http://www.rocketboom.com/rb_05_feb_04.mov" />
                            <link type="video/x-ms-wmv" length="100" url="http://www.rocketboom.com/video/rb_05_feb_04.wmv" />
                            <link type="application/x-bittorrent" length="100" url="http://www.rocketboom.com/rb_05_feb_04.mov.torrent" />
                            </enclosure>

                            But is that bittorrent enclosure actually any use? How would I tell a
                            WMV from a MOV if they are both delivered via bittorrent?

                            You also fall into the trap of assuming that position in an XML
                            document imples any sort of ordering. You write:

                            <enclosure title="Photo in a series" xmlns="http://www.solitude.dk/syndication/enclosures/">
                            <link type="image/jpg" length="52200" url="http://www.domain.com/photo1.jpg" />
                            <link type="image/jpg" length="1100" url="http://www.domain.com/photo1_small.jpg" title="Thumbnail" />
                            </enclosure>
                            <enclosure title="Another photo" xmlns="http://www.solitude.dk/syndication/enclosures/">
                            <link type="image/jpg" length="52200" url="http://www.domain.com/photo2.jpg" />
                            <link type="image/jpg" length="1100" url="http://www.domain.com/photo2_small.jpg" title="Thumbnail" />
                            </enclosure>
                            <enclosure title="Ane one more photo" xmlns="http://www.solitude.dk/syndication/enclosures/">
                            <link type="image/jpg" length="52200" url="http://www.domain.com/photo2.jpg" />
                            <link type="image/jpg" length="1100" url="http://www.domain.com/photo2_small.jpg" title="Thumbnail" />
                            </enclosure>

                            From your text, I assume that these photos are a sequence.
                            Unfortunately, to an XML parser they are an unordered group. Merely
                            stating in the specification (as mRSS does, and you seem to assume)
                            that order is significant is not enough to change the behaviour of
                            standards-compliant XML parsers. If you want things to be treated as a
                            sequence, give them some sort sequence numbers or timestamps. That's
                            what RSS does.

                            > mRSS fixes the one thing that makes the standard enclosure element unfit 
                            > for blogs: It allows for more than one enclosure per item. And it fixes an 
                            > issue that makes everyone's life easier: It allows for multiple versions 
                            > of the same enclosure (like an EPS and a PNG version of the same image. 
                            > One for print, one for web).

                            Well, it certainly allows more than one enclosure, but (IMHO) not in a
                            way that makes it much more use than simply following the path of
                            least resistance and handling multiple RSS2.0 enclosures (which some
                            software does already).

                            Some examples:

                            * The mRSS "group" tag has no attributes to indicate what _sort_ of
                            group it is. Is it _always_ a set of alternates, or might it be an
                            ordered or unordered sequence, or some other grouping? It also has
                            not attributes to indicate what aspect of the alternatives might be
                            significant in choosing between them, forcing software to make naive
                            assumptions (such as they must all be different mime types)

                            * The mRSS "media:adult" tag is laughable and should have used a much
                            more generic mechanism to allow for filtering on any other sort of
                            criteria. You might be happy with certain swear words in a video or
                            podcast, I might not. I may be happy with "bush bashing", you might
                            not. "Adult" content is merely one example of a filter criterion, and
                            even then varies widely by culture. Modern designs support arbitrary
                            tags.

                            * using XML attributes for a long list of media-specific details is
                            both clumsy and incomplete. It's clumsy because the specific list of
                            attributes has to be built in to the spec, with no extensibility, and
                            its incomplete because there are blatantly many kinds of information
                            about enclosures that are not covered. Say I enclose two PDFs, one at
                            "print" resolution, one at "screen" resolution. Do the current set of
                            attributes help? Say I enclose two Quicktime movies, one using the
                            (presently Mac-only) h264 codec and one using the old Sorensen 3
                            codec. Do the current set of attributes help?

                            Good practice when designing a usable XML standard is to make it
                            extensible without modifying the core standard. I definately agree
                            with your proposal on this aspect. I can't see the current form of
                            mRSS thriving as it is, simply because it makes too many assumtions
                            about the kinds of enclosures people want to use, and how they want to
                            use them.

                            Wouldn't it be nicer to have something really simple, but ultimately
                            flexible. To help you see what I mean, here's a few examples I
                            have just thrown together. They are not intended to be complete or
                            particularly workable (in particular, I'd usually recommend sticking
                            with "dublin core" for general metadata formats), but I still feel
                            they would be more directly useful than mRSS.

                            Example 1, a photo sequence

                            <group type='ordered' key='timestamp'>
                            <enclosure URL='http://www.domain.com/photo1.jpg'>
                            <attribute name='timestamp' value='00001243462594'/>
                            </enclosure>
                            <enclosure URL='http://www.domain.com/photo2.jpg'>
                            <attribute name='timestamp' value='00001243462602'/>
                            </enclosure>
                            </group>

                            Example two, PDFs at different resolutions

                            <group type='alternate' key='resolution'>
                            <enclosure URL='http://www.example.com/pr/brochure-large.pdf'>
                            <attribute name='resolution' value='print'/>
                            </enclosure>
                            <enclosure URL='http://www.example.com/pr/brochure-small.pdf'>
                            <attribute name='resolution' value='screen'/>
                            </enclosure>
                            </group>

                            Example three, time-dependent information

                            <group type='conditional' key='now() >= from && now() <= to'>
                            <enclosure URL='http://www.example.com/pr/brochure-2004.pdf'>
                            <attribute name='from' value='2004/01/01'/>
                            <attribute name='to' value='2004/12/31'/>
                            </enclosure>
                            <enclosure URL='http://www.example.com/pr/brochure-2005.pdf'>
                            <attribute name='from' value='2005/01/01'/>
                            <attribute name='to' value='2005/12/31'/>
                            </enclosure>
                            </group>


                            These examples require just three tags:

                            <group> - alows grouping of enclosures or other nested groups.
                            two mandatory attributes
                            type (ordered, unordered, alternate, conditional)
                            key (attribute to consider in sequencing,
                            attribute to use as user choice in alternate,
                            or expression to evaluate at load time for conditional

                            <enclosure> - reference an enclosure
                            one mandatory attribute
                            URL where to get it.
                            two optional attributes
                            size (if the server can not provide size info)
                            mime type (if the server might not provide correct type info)

                            <attribute> - associate an attribute with an enclosure or group
                            two mandatory attributes
                            name
                            value

                            A spec should define a "core" set of attributes, but support arbitrary
                            others. Admittedly the "expression in conditional" bit is a bit
                            off-the-wall but it shows the kinds of things that might actually be
                            useful in the future.

                            That was a bit longer than I intended. Can you see what I'm getting
                            at, though?

                            --
                            Frank Carver http://www.makevideo.org.uk
                          • Joshua Kinberg
                            This is worth posting in the rss-media Yahoo group where David Hall and others from Yahoo are accepting feedback on their RFC. -josh
                            Message 13 of 20 , May 31, 2005
                              This is worth posting in the rss-media Yahoo group where David Hall
                              and others from Yahoo are accepting feedback on their RFC.

                              -josh


                              On 5/31/05, Frank Carver <frank@...> wrote:
                              > Tuesday, May 31, 2005, 2:52:20 PM, Andreas Haugstrup wrote:
                              >
                              > > No, the standard enclosure element doesn't work at all if both sides stick
                              > > to the spec. The standard enclosure element only allows for one enclosure
                              > > per item, making the whole thing totally unfit for blogging. It's like
                              > > having a word processor that only allows you to use one picture per
                              > > document, or an e-mail client that only allows for one attached file per
                              > > e-mail. It's stupid, without vision and useless for blogs.
                              >
                              > Hmm. I agree that there _might_ be situations where it would make sense
                              > to associate more than one enclosure with a blog post. I think it's a
                              > bit extreme to claim it as "useless for blogs", though. There's always
                              > the option of posting several items at the same time.
                              >
                              > One thing I think it's important to notice, is that so far _none_
                              > of the suggestions (apart from the original one enclosure per entry)
                              > contain any real concept of sequence. No kind of ordering or timestamp is
                              > associated with enclosures, only with the RSS item as a whole.
                              > If sequence is at all important, the only way is still one enclosure per RSS
                              > item. More on this below.
                              >
                              > > When Yahoo Media RSS (mRSS) was being drafted I lobbied for breaking it
                              > > into two specs. One for general enclosure structure - a bare minimum, and
                              > > another which contained the audio/video metadata. Unfortunately they
                              > > couldn't/wouldn't accomodate me. You can still see my proposal at: <URL:
                              > > http://www.solitude.dk/archives/20050208-0045/ >
                              >
                              > Your proposal is interesting, but still suffers from some of the same
                              > problems as mRSS. Assuming that the mime type of an enclosure is
                              > enough to distinguish it fails even in your own examples. You write:
                              >
                              > <enclosure title="Rocketboom: Casual Friday" xmlns="http://www.solitude.dk/syndication/enclosures/">
                              > <link type="video/quicktime" length="100" url="http://www.rocketboom.com/rb_05_feb_04.mov" />
                              > <link type="video/x-ms-wmv" length="100" url="http://www.rocketboom.com/video/rb_05_feb_04.wmv" />
                              > <link type="application/x-bittorrent" length="100" url="http://www.rocketboom.com/rb_05_feb_04.mov.torrent" />
                              > </enclosure>
                              >
                              > But is that bittorrent enclosure actually any use? How would I tell a
                              > WMV from a MOV if they are both delivered via bittorrent?
                              >
                              > You also fall into the trap of assuming that position in an XML
                              > document imples any sort of ordering. You write:
                              >
                              > <enclosure title="Photo in a series" xmlns="http://www.solitude.dk/syndication/enclosures/">
                              > <link type="image/jpg" length="52200" url="http://www.domain.com/photo1.jpg" />
                              > <link type="image/jpg" length="1100" url="http://www.domain.com/photo1_small.jpg" title="Thumbnail" />
                              > </enclosure>
                              > <enclosure title="Another photo" xmlns="http://www.solitude.dk/syndication/enclosures/">
                              > <link type="image/jpg" length="52200" url="http://www.domain.com/photo2.jpg" />
                              > <link type="image/jpg" length="1100" url="http://www.domain.com/photo2_small.jpg" title="Thumbnail" />
                              > </enclosure>
                              > <enclosure title="Ane one more photo" xmlns="http://www.solitude.dk/syndication/enclosures/">
                              > <link type="image/jpg" length="52200" url="http://www.domain.com/photo2.jpg" />
                              > <link type="image/jpg" length="1100" url="http://www.domain.com/photo2_small.jpg" title="Thumbnail" />
                              > </enclosure>
                              >
                              > From your text, I assume that these photos are a sequence.
                              > Unfortunately, to an XML parser they are an unordered group. Merely
                              > stating in the specification (as mRSS does, and you seem to assume)
                              > that order is significant is not enough to change the behaviour of
                              > standards-compliant XML parsers. If you want things to be treated as a
                              > sequence, give them some sort sequence numbers or timestamps. That's
                              > what RSS does.
                              >
                              > > mRSS fixes the one thing that makes the standard enclosure element unfit
                              > > for blogs: It allows for more than one enclosure per item. And it fixes an
                              > > issue that makes everyone's life easier: It allows for multiple versions
                              > > of the same enclosure (like an EPS and a PNG version of the same image.
                              > > One for print, one for web).
                              >
                              > Well, it certainly allows more than one enclosure, but (IMHO) not in a
                              > way that makes it much more use than simply following the path of
                              > least resistance and handling multiple RSS2.0 enclosures (which some
                              > software does already).
                              >
                              > Some examples:
                              >
                              > * The mRSS "group" tag has no attributes to indicate what _sort_ of
                              > group it is. Is it _always_ a set of alternates, or might it be an
                              > ordered or unordered sequence, or some other grouping? It also has
                              > not attributes to indicate what aspect of the alternatives might be
                              > significant in choosing between them, forcing software to make naive
                              > assumptions (such as they must all be different mime types)
                              >
                              > * The mRSS "media:adult" tag is laughable and should have used a much
                              > more generic mechanism to allow for filtering on any other sort of
                              > criteria. You might be happy with certain swear words in a video or
                              > podcast, I might not. I may be happy with "bush bashing", you might
                              > not. "Adult" content is merely one example of a filter criterion, and
                              > even then varies widely by culture. Modern designs support arbitrary
                              > tags.
                              >
                              > * using XML attributes for a long list of media-specific details is
                              > both clumsy and incomplete. It's clumsy because the specific list of
                              > attributes has to be built in to the spec, with no extensibility, and
                              > its incomplete because there are blatantly many kinds of information
                              > about enclosures that are not covered. Say I enclose two PDFs, one at
                              > "print" resolution, one at "screen" resolution. Do the current set of
                              > attributes help? Say I enclose two Quicktime movies, one using the
                              > (presently Mac-only) h264 codec and one using the old Sorensen 3
                              > codec. Do the current set of attributes help?
                              >
                              > Good practice when designing a usable XML standard is to make it
                              > extensible without modifying the core standard. I definately agree
                              > with your proposal on this aspect. I can't see the current form of
                              > mRSS thriving as it is, simply because it makes too many assumtions
                              > about the kinds of enclosures people want to use, and how they want to
                              > use them.
                              >
                              > Wouldn't it be nicer to have something really simple, but ultimately
                              > flexible. To help you see what I mean, here's a few examples I
                              > have just thrown together. They are not intended to be complete or
                              > particularly workable (in particular, I'd usually recommend sticking
                              > with "dublin core" for general metadata formats), but I still feel
                              > they would be more directly useful than mRSS.
                              >
                              > Example 1, a photo sequence
                              >
                              > <group type='ordered' key='timestamp'>
                              > <enclosure URL='http://www.domain.com/photo1.jpg'>
                              > <attribute name='timestamp' value='00001243462594'/>
                              > </enclosure>
                              > <enclosure URL='http://www.domain.com/photo2.jpg'>
                              > <attribute name='timestamp' value='00001243462602'/>
                              > </enclosure>
                              > </group>
                              >
                              > Example two, PDFs at different resolutions
                              >
                              > <group type='alternate' key='resolution'>
                              > <enclosure URL='http://www.example.com/pr/brochure-large.pdf'>
                              > <attribute name='resolution' value='print'/>
                              > </enclosure>
                              > <enclosure URL='http://www.example.com/pr/brochure-small.pdf'>
                              > <attribute name='resolution' value='screen'/>
                              > </enclosure>
                              > </group>
                              >
                              > Example three, time-dependent information
                              >
                              > <group type='conditional' key='now() >= from && now() <= to'>
                              > <enclosure URL='http://www.example.com/pr/brochure-2004.pdf'>
                              > <attribute name='from' value='2004/01/01'/>
                              > <attribute name='to' value='2004/12/31'/>
                              > </enclosure>
                              > <enclosure URL='http://www.example.com/pr/brochure-2005.pdf'>
                              > <attribute name='from' value='2005/01/01'/>
                              > <attribute name='to' value='2005/12/31'/>
                              > </enclosure>
                              > </group>
                              >
                              >
                              > These examples require just three tags:
                              >
                              > <group> - alows grouping of enclosures or other nested groups.
                              > two mandatory attributes
                              > type (ordered, unordered, alternate, conditional)
                              > key (attribute to consider in sequencing,
                              > attribute to use as user choice in alternate,
                              > or expression to evaluate at load time for conditional
                              >
                              > <enclosure> - reference an enclosure
                              > one mandatory attribute
                              > URL where to get it.
                              > two optional attributes
                              > size (if the server can not provide size info)
                              > mime type (if the server might not provide correct type info)
                              >
                              > <attribute> - associate an attribute with an enclosure or group
                              > two mandatory attributes
                              > name
                              > value
                              >
                              > A spec should define a "core" set of attributes, but support arbitrary
                              > others. Admittedly the "expression in conditional" bit is a bit
                              > off-the-wall but it shows the kinds of things that might actually be
                              > useful in the future.
                              >
                              > That was a bit longer than I intended. Can you see what I'm getting
                              > at, though?
                              >
                              > --
                              > Frank Carver http://www.makevideo.org.uk
                              >
                              >
                              >
                              >
                              > Yahoo! Groups Links
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                            • johngaltsjournal
                              ... I agree the simple in RSS is flying out the window. You knew it would happen though; everyone wants your feed to go through them . Heaven forbid we can
                              Message 14 of 20 , May 31, 2005
                                --- In videoblogging@yahoogroups.com, "dnadig" <dnadig@y...> wrote:
                                > Sigh. The beauty of RSS lies in it's simplicity - I'm already annoyed
                                > and frustrated by the number of feed-varient issues that are out
                                > there. The single standard RSS enclosure tag work's REALLY well if
                                > both sides just stick to the spec.

                                I agree the "simple" in RSS is flying out the window. You knew it would happen though;
                                everyone wants your feed to go through "them".

                                Heaven forbid we can all be standardized for simplicity
                                schlomo
                                http://schlomolog.blogspot.com
                              • Joshua Kinberg
                                ... Well... you know what the great thing about standards is... there s always so many to choose from! Enclosures are good for simplicity, but bad for any
                                Message 15 of 20 , May 31, 2005
                                  > Heaven forbid we can all be standardized for simplicity

                                  Well... you know what the great thing about standards is... there's
                                  always so many to choose from!

                                  Enclosures are good for simplicity, but bad for any purpose beyond the
                                  most simple.
                                  Basically, the easy stuff should be easy, and the hard stuff should be possible.
                                  This is not so with the current enclosure spec. The hard stuff is not
                                  possible at all. That is not good.
                                  Perhaps Media RSS will help make this hard stuff possible. Perhaps it
                                  still has a ways to go. Its already a nice step forward from
                                  enclosures, and being supported by Yahoo, FeedBurner and others
                                  certainly helps.

                                  -josh


                                  On 5/31/05, johngaltsjournal <schlomo@...> wrote:
                                  > --- In videoblogging@yahoogroups.com, "dnadig" <dnadig@y...> wrote:
                                  > > Sigh. The beauty of RSS lies in it's simplicity - I'm already annoyed
                                  > > and frustrated by the number of feed-varient issues that are out
                                  > > there. The single standard RSS enclosure tag work's REALLY well if
                                  > > both sides just stick to the spec.
                                  >
                                  > I agree the "simple" in RSS is flying out the window. You knew it would happen though;
                                  > everyone wants your feed to go through "them".
                                  >
                                  > Heaven forbid we can all be standardized for simplicity
                                  > schlomo
                                  > http://schlomolog.blogspot.com
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  > Yahoo! Groups Links
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                • Andreas Haugstrup
                                  On Tue, 31 May 2005 17:50:35 +0200, Frank Carver ... Yes, I do. I agree with you completely - you know a lot more than me about how to
                                  Message 16 of 20 , May 31, 2005
                                    On Tue, 31 May 2005 17:50:35 +0200, Frank Carver <frank@...>
                                    wrote:

                                    > That was a bit longer than I intended. Can you see what I'm getting
                                    > at, though?

                                    Yes, I do. I agree with you completely - you know a lot more than me about
                                    how to future-proof XML files. I'm glad the syndication talk is here
                                    again. I also think you should take Josh's advice and repost your e-mail
                                    to the Media RSS Yahoo Group. <URL:
                                    http://groups.yahoo.com/group/rss-media/ >

                                    In a perfect world we'd use the notation you have presented here. There
                                    are stupid reasons for why that isn't going to happen. Like I said I
                                    lobbied for breaking up the Media RSS spec into a general enclosure spec
                                    and audio/video spec. By the time I found out about the RSS-Media Yahoo
                                    Group the spec was very close to being finalized (in version 1.0) so I
                                    didn't have a lot of luck. I did get the issue on the agenda, and I
                                    believe that the current compromise (where all audio/video items are
                                    optional) is the best we can hope for. Having the backing of a corporation
                                    like Yahoo is a very nice thing.

                                    I've placed some more or less random comments below.

                                    > Hmm. I agree that there _might_ be situations where it would make sense
                                    > to associate more than one enclosure with a blog post. I think it's a
                                    > bit extreme to claim it as "useless for blogs", though. There's always
                                    > the option of posting several items at the same time.

                                    We'll disagree on this I think. To me being told that I can only put one
                                    picture in my blog post, or that I can't put a stillshot and a video file
                                    in my blog post because of the syndication format's limitations does make
                                    the syndication format useless. If it represent my content it's no good.

                                    > One thing I think it's important to notice, is that so far _none_
                                    > of the suggestions (apart from the original one enclosure per entry)
                                    > contain any real concept of sequence. No kind of ordering or timestamp is
                                    > associated with enclosures, only with the RSS item as a whole.
                                    > If sequence is at all important, the only way is still one enclosure per
                                    > RSS
                                    > item. More on this below.
                                    >
                                    > Your proposal is interesting, but still suffers from some of the same
                                    > problems as mRSS. Assuming that the mime type of an enclosure is
                                    > enough to distinguish it fails even in your own examples.

                                    It probably isn't enough, but in a general enclosure proposal it's the
                                    only way. Any other way will be type specific (like bitrate or frames per
                                    second).

                                    > From your text, I assume that these photos are a sequence.
                                    > Unfortunately, to an XML parser they are an unordered group. Merely
                                    > stating in the specification (as mRSS does, and you seem to assume)
                                    > that order is significant is not enough to change the behaviour of
                                    > standards-compliant XML parsers. If you want things to be treated as a
                                    > sequence, give them some sort sequence numbers or timestamps. That's
                                    > what RSS does.

                                    The photos in the example wasn't thought as a sequence, but as a
                                    collection. But your point is still valid. I didn't address sequences in
                                    my proposal. You could handle this in the spec. You can put down in the
                                    spec that the order the enclosures arrive in the XML source does matter. I
                                    haven't met a parser who can't handle this kind of ordering.

                                    You see the same thing in XHTML. Multiple paragraphs are handled in the
                                    order they appear in the XHTML source, even though each paragraph doesn't
                                    have an identifying mark that details it's place in the list of
                                    paragraphs. If the parser didn't do this your paragraphs could be
                                    seriously jumbled up by the time they reached your reader, and that'd
                                    suck. :o)

                                    Anyway, if you are very dependent on the exact sequence, wouldn't you
                                    enclose a playlist (like an XSPF file) and not the individual media files?
                                    That's what I'd do...

                                    > Well, it certainly allows more than one enclosure, but (IMHO) not in a
                                    > way that makes it much more use than simply following the path of
                                    > least resistance and handling multiple RSS2.0 enclosures (which some
                                    > software does already).

                                    My original proposal was to ammend the RSS 2.0 spec to allow for multiple
                                    instances of the enclosure element. Winer has frozen RSS so that's not
                                    possible. The next best thing seems to be a small jump up the complexity
                                    ladder to mRSS where you can have the same thing if you want (just type
                                    <media:content> instead of <enclosure>), but you can also do multiple
                                    versions with the <media:group>.

                                    > * The mRSS "group" tag has no attributes to indicate what _sort_ of
                                    > group it is. Is it _always_ a set of alternates, or might it be an
                                    > ordered or unordered sequence, or some other grouping?

                                    The spec is very clear. Media:group is *always* a set of alternates. From
                                    the spec:

                                    "<media:group> is a sub-element of <item>. It allows grouping of
                                    <media:content> elements that are effectively the same content, yet
                                    different representations. For instance: the same song recorded in both
                                    the WAV and MP3 format. It's an optional element that must only be used
                                    for this purpose."

                                    > It also has
                                    > not attributes to indicate what aspect of the alternatives might be
                                    > significant in choosing between them, forcing software to make naive
                                    > assumptions (such as they must all be different mime types)

                                    The software has to deal with this anyway. The user's software is the only
                                    thing that can make useful choices for the user anyway. That's the beauty
                                    of it. mRSS supplies the metadata, and the user can then setup his
                                    aggregator to filter what he pulls down.

                                    > * The mRSS "media:adult" tag is laughable and should have used a much
                                    > more generic mechanism to allow for filtering on any other sort of
                                    > criteria.

                                    No kidding. You should've been on the media-rss mailing list during
                                    developement. No one liked this element, but it was forced through. It's
                                    useless right now, but fortunately it's also harmless. You should've seen
                                    some of the suggestions for this element...
                                    It's impossible to set down some sort of categorization that works for
                                    this kind of content. The differences on both culture and obscenity
                                    legislation alone... What is obscene and culturally repulsive in Alabama
                                    might be on prime time broadcast TV in Western Europe. At least the
                                    current element is harmless.

                                    > * using XML attributes for a long list of media-specific details is
                                    > both clumsy and incomplete. It's clumsy because the specific list of
                                    > attributes has to be built in to the spec, with no extensibility, and
                                    > its incomplete because there are blatantly many kinds of information
                                    > about enclosures that are not covered.

                                    You can add sub-elements to <media:content> with your own extensions. I
                                    remember there was some confusion on the rss-media list about what to
                                    include as attributes and what to include as sub-elements. I *think* the
                                    current amount of attributes was chosen to make it look the most like the
                                    rest of RSS 2.0 (which is littered with attributes here and there). I
                                    don't really remember though.

                                    > Say I enclose two PDFs, one at
                                    > "print" resolution, one at "screen" resolution. Do the current set of
                                    > attributes help?

                                    No, because they're all audio/video centered. You'd create your own
                                    namespace to fit this other type of syndication. This is exactly why I
                                    wanted a generic enclosure spec, and then a seperate audio/video spec.

                                    > Say I enclose two Quicktime movies, one using the
                                    > (presently Mac-only) h264 codec and one using the old Sorensen 3
                                    > codec. Do the current set of attributes help?

                                    I don't know if supplying codes information is useful for sorting (other
                                    than for this specific example). I think you should take it to the
                                    rss-media group though.

                                    > I can't see the current form of
                                    > mRSS thriving as it is, simply because it makes too many assumtions
                                    > about the kinds of enclosures people want to use, and how they want to
                                    > use them.

                                    I'm hoping. The advantage is that Yahoo and Feedburner is backing the
                                    spec. That means a whole lot. And the basic building blocks do exist
                                    there. You can use mRSS for all types of content.

                                    > Wouldn't it be nicer to have something really simple, but ultimately
                                    > flexible. To help you see what I mean, here's a few examples I
                                    > have just thrown together.

                                    I think you should definately take this to the rss-media group! I really
                                    like the way you think.

                                    > A spec should define a "core" set of attributes, but support arbitrary
                                    > others.

                                    I agree completely.

                                    - Andreas
                                    --
                                    <URL:http://www.solitude.dk/>
                                    Commentary on media, communication, culture and technology.
                                  • dnadig
                                    First, I really appreciate Andreas deep response on the technology/media RSS front. Out of all of it, the bit I think is actually most relevant is the concept
                                    Message 17 of 20 , May 31, 2005
                                      First, I really appreciate Andreas deep response on the
                                      technology/media RSS front.

                                      Out of all of it, the bit I think is actually most relevant is the
                                      concept of "playlist" - that is - what follows what. To say this is
                                      just "date" doesn't work. If you produce, say, a 3 hour piece with
                                      interstitial ads, or, perhaps, an album of music thats designed to be
                                      played in order, the current spec does nothing for you at all.

                                      But that said, I still subscribe to the one format per feed design.
                                    • Andreas Haugstrup
                                      ... While it can seem nice, that model fails too quickly to be useful for all but the most narrow blogs. It only works if you only push down one type of media
                                      Message 18 of 20 , Jun 1, 2005
                                        On Wed, 01 Jun 2005 05:01:48 +0200, dnadig <dnadig@...> wrote:

                                        > But that said, I still subscribe to the one format per feed design.

                                        While it can seem nice, that model fails too quickly to be useful for all
                                        but the most narrow blogs. It only works if you only push down one type of
                                        media (audio, video etc.) and only if you have the formats defined before
                                        you begin.

                                        Let's say you have a blog where you use this model to push out your video.
                                        What happens the day you put up an audio file? Does the MP3 file go in the
                                        Quicktime feed or the WMV feed? Which feed does the Ogg Vorbis file go
                                        into? What happens when you put up a PDF and a Word version of the same
                                        document? What goes where?

                                        By using that model (or by having technology where this model is the only
                                        model available) is putting unnecessary limits on your content.

                                        - Andreas
                                        --
                                        <URL:http://www.solitude.dk/>
                                        Commentary on media, communication, culture and technology.
                                      • dnadig
                                        ... go in the ... file go ... same ... Well, I understand this argument - and it s the fundamental argument for mRSS. I just think it puts a lot of burden on
                                        Message 19 of 20 , Jun 1, 2005
                                          --- In videoblogging@yahoogroups.com, "Andreas Haugstrup"
                                          <solitude@s...> wrote:
                                          > What happens the day you put up an audio file? Does the MP3 file
                                          go in the
                                          > Quicktime feed or the WMV feed? Which feed does the Ogg Vorbis
                                          file go
                                          > into? What happens when you put up a PDF and a Word version of the
                                          same
                                          > document? What goes where?

                                          Well, I understand this argument - and it's the fundamental argument
                                          for mRSS. I just think it puts a lot of burden on the aggregator to
                                          impose selection and logic to the process. Let's say someone uses
                                          mRSS to post coverage of a speech. They post the audio as WAV, MP3,
                                          WMV and FLAC. They post the video as MOV, WMV, MP4, and say AVI.
                                          It's all the same "item." (this is a stretch I know, but entirely
                                          within spec as I understand it).

                                          Now my aggregator needs to decide what to grab. Both audio and
                                          video? Preference rules? Now which format: do I impose a cascade on
                                          it? What if the contents in 3 different resolutions, and WMV is the
                                          highest, but I prefer MOV most of the time?

                                          It can get ugly fast, and forcing the user to choose for each item
                                          is a terrible solution, as it defeats all of the advantages of
                                          caching. Downloading everything is obviously a hugely innefficient
                                          answer too.

                                          So the response is likely "well its up to the content owner to be
                                          really logical about how they package their stuff"

                                          Which leads us back to 'why not just use one format per feed.'

                                          Life would be so much easier if someone (deus ex machina) picked a
                                          format for us, but then, that would be cowtowing to someone like
                                          MSFT...
                                        • Andreas Haugstrup
                                          ... It puts the burden on the aggregator and the reader. Who else should the burden be on? The alternative is to not mix and match media in blogs, and that
                                          Message 20 of 20 , Jun 1, 2005
                                            On Wed, 01 Jun 2005 16:17:45 +0200, dnadig <dnadig@...> wrote:

                                            > Well, I understand this argument - and it's the fundamental argument
                                            > for mRSS. I just think it puts a lot of burden on the aggregator to
                                            > impose selection and logic to the process.

                                            It puts the burden on the aggregator and the reader. Who else should the
                                            burden be on? The alternative is to not mix and match media in blogs, and
                                            that would be very sad.

                                            > It can get ugly fast, and forcing the user to choose for each item
                                            > is a terrible solution, as it defeats all of the advantages of
                                            > caching. Downloading everything is obviously a hugely innefficient
                                            > answer too.

                                            You say 'ugly' I say 'beautiful'. :o)
                                            The idea of pre-fetching the content (overnight or whatever) is not
                                            something I'm a fan of to begin with. For the very reason you outline: My
                                            computer *can't* always guess what I want. It can do it some of the time.
                                            The pre-fetching started with podcasting, and their
                                            I'll-just-send-you-this-1-hour-audio-file-radio-show-deal. For blogging
                                            it's just not necessary. I don't pre-fetch Eric Rice's audio blog posts,
                                            there's just no need. I don't pre-fetch videoblog, there's no need. I
                                            click play, wait a second, and the video begins playing while it downloads.

                                            Pre-fetching would be a bigger waste of bandwidth, since I'd be
                                            downloading a lot of video I'd never see.

                                            Anyway, I say beautiful because I imagine a more clever aggregator that
                                            would serve me my options for reading/viewing/listening with each blog
                                            post. A little sidebar with links to the mp3, wav, mov and wmv files. One
                                            day I'll want to watch on my computer and I'll grab the mov from the
                                            aggregator, the next day I'm going biking so I'll load the mp3 to my iPod.

                                            > So the response is likely "well its up to the content owner to be
                                            > really logical about how they package their stuff"

                                            Can't do that. I don't even know what I'm having for dinner tomorrow,
                                            there's no way I can tell you what kinds of files I'll be posting to my
                                            blog next month. I've sent weird stuff like Photoshop files and even an
                                            RSS file as enclosures in the past. Who knows what tomorrow brings?

                                            - Andreas
                                            --
                                            <URL:http://www.solitude.dk/>
                                            Commentary on media, communication, culture and technology.
                                          Your message has been successfully submitted and would be delivered to recipients shortly.