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

Re: [opml-dev] OPML: New Version

Expand Messages
  • 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 1 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?"
    • 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 2 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 3 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 4 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 5 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 6 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.