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

Re: [opml-dev] OPML: New Version

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