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

OPML: New Version

Expand Messages
  • rgrieselhuber
    I just read through the mailing list and there seems to be a number of people with concerns about the practicality of using attributes vs. the flexibility in
    Message 1 of 11 , Apr 10, 2003
    • 0 Attachment
      I just read through the mailing list and there seems to be a number
      of people with concerns about the practicality of using attributes
      vs. the flexibility in OPML.
      It seems like this problem would be easily solved with a new version
      of the spec. How about something like this:

      <?xml version="1.0" encoding="ISO-8859-1"?>
      <opml version="2.0">
      <head>
      <title>My Document</title>
      <dateCreated>Thu, 10 Apr 2003 10:07:51 GMT</dateCreated>
      <dateModified>Thu, 10 Apr 2003 10:07:51 GMT</dateModified>
      <ownerName>Owner name</ownerName>
      <ownerEmail>me@...</ownerEmail>
      <expansionState>1</expansionState>
      <vertScrollState>1</vertScrollState>
      <windowTop>5</windowTop>
      <windowLeft>5</windowLeft>
      <windowBottom>455</windowBottom>
      <windowRight>455</windowRight>
      </head>
      <body>
      <outline text="Test" modified="" created="" isBreakpoint=""
      type="todo" url="">
      <note>This is where large amounts of text should go.</note>
      <!-- Items take the place of attributes to allow for
      unlimited extensibility without breaking code that relies on home-
      grown
      dialects of OPML -->
      <item name="complete">false</item>
      <item name="percent">75</item>
      <!-- just an sample possible implementation of ACLs, etc.
      that don't break anyone's models -->
      <item name="ReadACL">CN=Ray Grieselhuber,O=World,
      CN=Groups,O=World</item>
      <outline text="Test" modified="" created=""
      isBreakpoint="" type="todo" url=""/>
      </outline>
      </body>
      </opml>

      I have kept all of the original attributes, etc. (I intend to
      anyway), so that once the minor changes necessary in XSLT
      processors, data binding code etc. is modified, old data can be used
      as is or migrated on the fly.

      Thoughts?
    • Dave Winer
      As usual, if you want to create a format that isn t compatible with OPML, you must call it something other than OPML. Thanks and good luck. Dave [Non-text
      Message 2 of 11 , Apr 10, 2003
      • 0 Attachment
        As usual, if you want to create a format that isn't compatible with OPML, you must call it something other than OPML. Thanks and good luck. Dave



        [Non-text portions of this message have been removed]
      • Iain Truskett
        ... That includes every use of OPML out there. Everyone seems to enjoy making up their own stuff. May as well use OCS for much of what OPML is used for in the
        Message 3 of 11 , Apr 11, 2003
        • 0 Attachment
          * Dave Winer (dave@...) [11 Apr 2003 13:20]:
          > As usual, if you want to create a format that isn't compatible with
          > OPML, you must call it something other than OPML. Thanks and good
          > luck.

          That includes every use of OPML out there. Everyone seems to enjoy
          making up their own stuff. May as well use OCS for much of what OPML is
          used for in the blogging world.


          cheers,
          --
          Iain.
        • Dave Winer
          I don t want to get into a drawn out debate on this, but if you have some examples, please share. The concern is sources that say they re OPML that don t
          Message 4 of 11 , Apr 11, 2003
          • 0 Attachment
            I don't want to get into a drawn out debate on this, but if you have some examples, please share. The concern is sources that say they're OPML that don't conform to the spec. Your statement about "every use of OPML out there" not conforming is false, because aggregators commonly use spec-conforming OPML to share information about subscriptions, and blogging software uses it for blogrolls, aside from outliners like Radio and Omni that I think conform to the spec. If you know otherwise, please make some bug reports. It's important. Of course using OCS is a fine thing to do. No one sees this as a competitive situation, at least they shouldn't. Thanks. Dave

            ----- Original Message -----
            From: Iain Truskett
            To: opml-dev@yahoogroups.com
            Sent: Friday, April 11, 2003 6:00 AM
            Subject: Re: [opml-dev] OPML: New Version


            * Dave Winer (dave@...) [11 Apr 2003 13:20]:
            > As usual, if you want to create a format that isn't compatible with
            > OPML, you must call it something other than OPML. Thanks and good
            > luck.

            That includes every use of OPML out there. Everyone seems to enjoy
            making up their own stuff. May as well use OCS for much of what OPML is
            used for in the blogging world.


            cheers,
            --
            Iain.


            Yahoo! Groups Sponsor
            ADVERTISEMENT




            To unsubscribe from this group, send an email to:
            opml-dev-unsubscribe@egroups.com



            Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


            [Non-text portions of this message have been removed]
          • Jeff Mitchell
            ... Why *are* you so uninterested in extending OPML? You ve defined somethign which is useful and popular, and then stopped it from growing. Very strange. jeff
            Message 5 of 11 , Apr 11, 2003
            • 0 Attachment
              On Thu, 10 Apr 2003, Dave Winer wrote:

              > As usual, if you want to create a format that isn't compatible with
              > OPML, you must call it something other than OPML. Thanks and good
              > luck. Dave

              Why *are* you so uninterested in extending OPML?

              You've defined somethign which is useful and popular, and then
              stopped it from growing. Very strange.

              jeff

              --
              "Have you played Atari today?"
            • Rogers Cadenhead
              ... This isn t the case -- there s a specific way to extend OPML, and all of the extensions I am familiar with follow it. To make up your own stuff in OPML,
              Message 6 of 11 , Apr 11, 2003
              • 0 Attachment
                On Fri, 11 Apr 2003 20:00:04 +1000, Iain Truskett wrote:
                >That includes every use of OPML out there. Everyone seems to enjoy
                >making up their own stuff. May as well use OCS for much of what OPML
                >is used for in the blogging world.

                This isn't the case -- there's a specific way to extend OPML, and all
                of the extensions I am familiar with follow it.

                To "make up your own stuff" in OPML, give the TYPE attribute of the
                OUTLINE element a value that isn't being used elsewhere, then add any
                attributes you like that are required of that type.

                As described in the spec, an OUTLINE element can have any attributes
                you like.

                Here are two examples:

                An RSS subscription in OPML (type="rss"):

                <outline text="Daring Fireball" description="Macintosh punditry and
                curmudgeonry." htmlUrl="http://daringfireball.net/"
                language="unknown" title="Daring Fireball" type="rss" version="RSS"
                xmlUrl="http://daringfireball.net/index.xml"/>

                A song in OPML (type="remotesong"):

                <outline text="Graham Parker - Success" album="The Mona Lisa's
                Sister" artist="Graham Parker" song="Success" type="remoteSong"
                whenPlayed="Mon, 03 Feb 2003 23:41:45 GMT"/>

                TYPE is being used like a namespace, letting OPML consumers know what
                to look for in the attributes of an OUTLINE item.

                I get the impression that this isn't the way an XML dialect is
                normally extended, but it's clearly working for some people, based on
                the number of OPML implementations out there. Aaron Swartz or someone
                else was working on an OPML replacement that used a DTD, but I think
                it was abandoned.
                --
                Rogers Cadenhead, rogers@... on 04/11/2003
                Weblog: http://www.cadenhead.org/workbench
              • Dave Winer
                Jeff, there are no limits to its growth, that I ve seen; and that s the way it works -- once something gets popular, if you change it you break it. I don t
                Message 7 of 11 , Apr 11, 2003
                • 0 Attachment
                  Jeff, there are no limits to its growth, that I've seen; and that's the way it works -- once something gets popular, if you change it you break it. I don't know how much experience you have with this, but I've been through this loop a few times, both ways -- and freezing a popular spec is the only way that fosters continued growth. There's nothing wrong with giving a new name to incompatible formats, the only reason to do it is to siphon off the energy behind something that's working, and all it ever does is create confusion that hurts both the old and the new format/protocol. Anyway when you create a popular format you can try it the other way, and maybe you'll make it work the way you want it to. Dave


                  ----- Original Message -----
                  From: Jeff Mitchell
                  To: opml-dev@yahoogroups.com
                  Sent: Friday, April 11, 2003 7:54 AM
                  Subject: Re: [opml-dev] OPML: New Version


                  On Thu, 10 Apr 2003, Dave Winer wrote:

                  > As usual, if you want to create a format that isn't compatible with
                  > OPML, you must call it something other than OPML. Thanks and good
                  > luck. Dave

                  Why *are* you so uninterested in extending OPML?

                  You've defined somethign which is useful and popular, and then
                  stopped it from growing. Very strange.

                  jeff

                  --
                  "Have you played Atari today?"



                  Yahoo! Groups Sponsor



                  To unsubscribe from this group, send an email to:
                  opml-dev-unsubscribe@egroups.com



                  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


                  [Non-text portions of this message have been removed]
                • Austin Marshall
                  OPML s strength, from my limited experience is it s simplicity. The basic format is simple and easy to use, and easy to keep consistent. It is also a
                  Message 8 of 11 , Apr 11, 2003
                  • 0 Attachment
                    OPML's strength, from my limited experience is it's simplicity. The
                    basic format is simple and easy to use, and easy to keep consistent.
                    It is also a relatively liberal spec that allows you to define your own
                    additional attributes where needed. What more can you really ask for?
                    In the context of outlining, it works quite well.

                    On Friday, April 11, 2003, at 06:54 AM, Jeff Mitchell wrote:

                    > On Thu, 10 Apr 2003, Dave Winer wrote:
                    >
                    > > As usual, if you want to create a format that isn't compatible with
                    > > OPML, you must call it something other than OPML. Thanks and good
                    > > luck. Dave
                    >
                    >       Why *are* you so uninterested in extending OPML?
                    >
                    >       You've defined somethign which is useful and popular, and then
                    > stopped it from growing. Very strange.
                    >
                    >             jeff
                    >
                    > --
                    > "Have you played Atari today?"
                    >
                    >
                    >
                    <image.tiff>
                    >
                    >
                    > To unsubscribe from this group, send an email to:
                    > opml-dev-unsubscribe@egroups.com
                    >
                    >
                    >
                    > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

                    [Non-text portions of this message have been removed]
                  • rgrieselhuber
                    Well again since the basic issue for most people is flexibility vs. a predictable format, and we can add any elements that we want to the outline element, then
                    Message 9 of 11 , Apr 11, 2003
                    • 0 Attachment
                      Well again since the basic issue for most people is flexibility vs. a
                      predictable format, and we can add any elements that we want to the
                      outline element, then I think the problem is solved.

                      Instead of trying to evolve the spec, which is obviously not going to
                      happen, and instead of creating some totally new spec then why don't
                      we just agree on a dialect OPML that is compatible with the
                      specification. As I now understand it, the sample that I proposed
                      yesterday, with the exception of the OPML version number, does exactly
                      that. In it, I tried to incorporate all of the suggestions that I
                      gleaned from the mailining lists. We would then create schema and DTDs
                      that describe this dialect so that applications that rely on schema
                      and DTDs for mapping will be happy and the author of the spec will be
                      happy as well.

                      Well?
                    • Jeff Mitchell
                      ... I m not going to start (another) flameware; Dave has good points; leaving it be is good in a lot of cases. Dave -- you can ignore this; being a lament
                      Message 10 of 11 , Apr 11, 2003
                      • 0 Attachment
                        On Fri, 11 Apr 2003, Austin Marshall wrote:

                        > OPML's strength, from my limited experience is it's simplicity. The
                        > basic format is simple and easy to use, and easy to keep consistent.

                        I'm not going to start (another) flameware; Dave has good
                        points; leaving it be is good in a lot of cases.

                        Dave -- you can ignore this; being a lament means its just idle
                        philosophy.

                        I have no complaints with OPML per se (aside from one person
                        running it, but Dave points out that having one person at leats keeps it
                        sane ;); mostly I have laments, in that my users want something from OPML
                        that it cannot deliver, and its a shame :) People *think* OPML is a
                        comprehensive format, when it is in fact a minimal format.

                        Perhaps the problem is this miscomprehension; perhaps the users
                        shoudl be instructed that really they want on eof the many other formats
                        (that are less common sadly).

                        It does not aid interopability, any more than flat text
                        files do. It does make it easy to work with, so you can add attributes
                        without worry of breaking the spec (Since the spec doesn't limit you in
                        this regard).

                        Does the spec itself suggest this "type" extension? If so, then
                        that is at least one well defined extension mechanism.

                        The main issue I've always had (maybe I'm an idiot ;) is that OPML
                        is simple and flexible (yay!), however does not aid people in sharing info
                        between OPML implementations without much research; I have seen many OPML
                        documents of nearly identical content-type with entirely incompatible OPML
                        layouts, since the attributes are not defined anywhere. You can go through
                        a half dozen websites to find some "common practices", but this doesn't
                        aid the job much.

                        Myself the other day I came across two OPML documents; both were
                        "RSS" type data, thoguh one was for newsfeed/blog stuf,f and the other was
                        something entirely different, just happened to be called an
                        "RSS" document; god help peopel trying to suck it into an RSS OPML
                        handler.

                        So where OPML succeeds is stay out of our way (which is much
                        better than most specs; don't get me wronmg.. OPML is very successfull for
                        good reason).

                        However, I get every other day people asking me to make this or
                        that app OPML compatible, and I can only say "tell me what fields to
                        populate, and we'll talk; there is no OPML outliner spec, or OPML table of
                        contents spec, etc etc".. so one cannot make a OPML reader for
                        outliners.. one can only make a OPML reader for RadioLand version X,
                        etc. One cannot be OPML compatible.. there is no such thing for any but
                        trivial applications.

                        When two unrelated OPML apps read the same file, they can both get
                        title texts if that is in there; the rest of the data is usually lost or
                        ignored (like dates.. there is no OPML date formatting). Its cool the apps
                        can both read and get hierarchical text.. of course, you can do that with
                        CSV, TXT, etc, too :) So two apps read the same document and get differing
                        results.

                        > It is also a relatively liberal spec that allows you to define your own
                        > additional attributes where needed. What more can you really ask for?
                        > In the context of outlining, it works quite well.

                        So does ASCII ;) (Okay, so we get the XML goodness for unicode,
                        and hierarchy well defined as opposed to assuming ASCII and
                        tab-for-indent, etc. You can of course say your document uses tab for
                        indent, and uses unicode with one transport forma, and voila.. you've
                        equalled OPML :)

                        There've been outliners exchanging text for decades (and of
                        course Dave knows more about that than any of us ;).

                        I write a popular outliner; people are always asking me why OPML
                        from it cannot work with such and such other app; I can write an Omni
                        Outliner OPML module, but no bets it'll work with any other app than Omni
                        Outliner.

                        If we made a more formal extension mechanism, perhaps it could.

                        *BUT*, this coudl just all be wishful thiniing. We all know how
                        well interoperration works in practice these days. But we can dream :)

                        Jeff

                        --
                        "Have you played Atari today?"
                      • Rogers Cadenhead
                        ... It could be more clear, but it does in these two lines: type is a string, it says how the other attributes of the are interpreted. There are no
                        Message 11 of 11 , Apr 11, 2003
                        • 0 Attachment
                          On Fri, 11 Apr 2003 12:41:43 -0400 (EDT), Jeff Mitchell wrote:
                          > Does the spec itself suggest this "type" extension? If so, then
                          >that is at least one well defined extension mechanism.

                          It could be more clear, but it does in these two lines:

                          "type is a string, it says how the other attributes of the <outline>
                          are interpreted.

                          "There are no documented limits to the number of attributes an
                          <outline> element can have, or the number of <outline> elements it
                          can contain."

                          http://www.opml.org/spec

                          I've posted more comments about this subject on my weblog:

                          http://www.cadenhead.org/workbench/2003/04/11.html#a638

                          At this point, OPML has enough traction that it's going to continue
                          to be supported, even if the attribute-based extensions drive some
                          XML gurus up the wall.
                          --
                          Rogers Cadenhead, rogers@... on 04/11/2003
                          Weblog: http://www.cadenhead.org/workbench
                        Your message has been successfully submitted and would be delivered to recipients shortly.