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

RE: [svg-developers] SVG in Google...

Expand Messages
  • Michael Bierman
    ... Can someone clarify why is that a low risk? ... To be more accurate, each relaase of Batik and ASV have become increasingly more conformant to the same
    Message 1 of 24 , Jul 1, 2002
    View Source
    • 0 Attachment
      > Doug Schepers wrote:
      >
      >
      > >>As discussed before, the risk for non-interoperable and non-conforming
      > >>full implementations is very low with SVG.

      Can someone clarify why is that a low risk?

      > > Very true... one of many Good Things about SVG. But the devil's in the
      > > details: ASV1-3, Batik, and Mozilla (a bit) all support
      > different feature sets of SVG.

      To be more accurate, each relaase of Batik and ASV have become increasingly
      more conformant to the same implementation and several mobile vendors are
      working toward SVG Mobile.


      > >>Again, I also hope that Adobe continues to support SVG and the ASV.
      > >>
      > > As do I. Or, if not, at least releases the source. <grin/>
      >
      >
      > Yes. Absolutely. It's free (0$), so why not make it free
      > (copyleft, eg GPL)?

      Tobi,

      What are you referring to as free?

      Michael
    • Tobias Reif
      ... It has been discussed on this list. Please read http://groups.yahoo.com/group/svg-developers/message/17505 and
      Message 2 of 24 , Jul 1, 2002
      View Source
      • 0 Attachment
        Michael Bierman wrote:


        >>>>As discussed before, the risk for non-interoperable and non-conforming
        >>>>full implementations is very low with SVG.
        >>>>
        > Can someone clarify why is that a low risk?


        It has been discussed on this list.

        Please read
        http://groups.yahoo.com/group/svg-developers/message/17505
        and
        http://groups.yahoo.com/group/svg-developers/message/17508


        > To be more accurate, each relaase of Batik and ASV have become increasingly
        > more conformant to the same implementation


        you mean "specification"?


        >>Yes. Absolutely. It's free (0$), so why not make it free
        >>(copyleft, eg GPL)?
        >>
        >
        > Tobi,
        >
        > What are you referring to as free?


        I explained it above. If that's not enough, you might have to question
        in more detail; I can't see what you don't understand.

        Free Software gives the users the freedom to run, copy, distribute,
        study, change and improve the software. If a company goes out of
        business, or stops supporting a sofware application, users, communities
        of users, companies, or anyone else can continue to work on it. This
        also requires that the source code is shipped with the app, or is available.

        A FS license is the only way to guarantee that the app will always be
        available, and that it will always be possible to develop it further.

        Here are some pointers:
        GNU
        http://www.gnu.org/philosophy/free-sw.html
        http://www.gnu.org/philosophy/license-list.html
        http://www.gnu.org/philosophy/philosophy.html
        http://www.gnu.org/licenses/gpl-faq.html
        http://www.gnu.org/copyleft/copyleft.html
        http://www.gnu.org/copyleft/gpl.html
        Others
        http://www.opensource.org/licenses/
        http://www.opensource.org/licenses/bsd-license.html
        http://www.apache.org/licenses/

        Tobi


        --
        http://www.pinkjuice.com/
      • mbier
        ... conforming ... Good points, of course SVG does inherently have many things going for it. But I still think there *is* risk at this point as I have
        Message 3 of 24 , Jul 1, 2002
        View Source
        • 0 Attachment
          --- In svg-developers@y..., Tobias Reif <tobiasreif@p...> wrote:
          > Michael Bierman wrote:
          >
          >
          > >>>>As discussed before, the risk for non-interoperable and non-
          conforming
          > >>>>full implementations is very low with SVG.
          > >>>>
          > > Can someone clarify why is that a low risk?
          >
          >
          > It has been discussed on this list.
          >
          > Please read
          > http://groups.yahoo.com/group/svg-developers/message/17505
          > and
          > http://groups.yahoo.com/group/svg-developers/message/17508

          Good points, of course SVG does inherently have many things going for
          it. But I still think there *is* risk at this point as I have
          commented on lately. I'm still hopeful, but concerned.

          > > To be more accurate, each relaase of Batik and ASV have become
          increasingly
          > > more conformant to the same implementation
          >
          > you mean "specification"?

          Yes, that's correct. Sorry, I was distracted.

          > >>Yes. Absolutely. It's free (0$), so why not make it free
          > >>(copyleft, eg GPL)?
          > >>
          > >
          > > Tobi,
          > >
          > > What are you referring to as free?
          >
          >
          > I explained it above. If that's not enough, you might have to
          question
          > in more detail; I can't see what you don't understand.
          >
          > Free Software gives the users the freedom to run, copy, distribute,
          > study, change and improve the software. If a company goes out of
          > business, or stops supporting a sofware application, users,
          communities
          > of users, companies, or anyone else can continue to work on it.
          This
          > also requires that the source code is shipped with the app, or is
          available.
          >
          > A FS license is the only way to guarantee that the app will always
          be
          > available, and that it will always be possible to develop it
          further.

          Tobi,

          I am well aware of Free software and copyleft perspectives. As I have
          explained in the past, ASV is built upon the much of the same IP that
          powers Adobe's key products: Acrobat, Photoshop, Illustrator, etc.
          I'm sure you can understand the difficulty here. I am certain that
          Adobe will never license this code under GNU. Nor do I see why they
          should, honestly.

          I don't want to start an OT discussion of Open Source religion, but
          Adobe invested heavily in creating this intellectual property--ASV.
          Nothing about that effort was free, with the possible exception of
          the SVG Recommendation. But even there, Adobe had staff working on
          that. SVG is an amazing opportunity. But for it to be the success
          we all hope for, there must be a positive feedback loop where
          Companies continue to support SVG, which drives more customers to
          want to buy SVG solutions, which allows more product investment and
          research.

          Michael
        • mbier
          ... conforming ... increasingly ... question ... communities ... This ... available. ... be ... further.
          Message 4 of 24 , Jul 1, 2002
          View Source
          • 0 Attachment
            --- In svg-developers@y..., Tobias Reif <tobiasreif@p...> wrote:
            > Michael Bierman wrote:
            >
            >
            > >>>>As discussed before, the risk for non-interoperable and non-
            conforming
            > >>>>full implementations is very low with SVG.
            > >>>>
            > > Can someone clarify why is that a low risk?
            >
            >
            > It has been discussed on this list.
            >
            > Please read
            > http://groups.yahoo.com/group/svg-developers/message/17505
            > and
            > http://groups.yahoo.com/group/svg-developers/message/17508
            >
            >
            > > To be more accurate, each relaase of Batik and ASV have become
            increasingly
            > > more conformant to the same implementation
            >
            >
            > you mean "specification"?
            >
            >
            > >>Yes. Absolutely. It's free (0$), so why not make it free
            > >>(copyleft, eg GPL)?
            > >>
            > >
            > > Tobi,
            > >
            > > What are you referring to as free?
            >
            >
            > I explained it above. If that's not enough, you might have to
            question
            > in more detail; I can't see what you don't understand.
            >
            > Free Software gives the users the freedom to run, copy, distribute,
            > study, change and improve the software. If a company goes out of
            > business, or stops supporting a sofware application, users,
            communities
            > of users, companies, or anyone else can continue to work on it.
            This
            > also requires that the source code is shipped with the app, or is
            available.
            >
            > A FS license is the only way to guarantee that the app will always
            be
            > available, and that it will always be possible to develop it
            further.
            >
            > Here are some pointers:
            > GNU
            > http://www.gnu.org/philosophy/free-sw.html
            > http://www.gnu.org/philosophy/license-list.html
            > http://www.gnu.org/philosophy/philosophy.html
            > http://www.gnu.org/licenses/gpl-faq.html
            > http://www.gnu.org/copyleft/copyleft.html
            > http://www.gnu.org/copyleft/gpl.html
            > Others
            > http://www.opensource.org/licenses/
            > http://www.opensource.org/licenses/bsd-license.html
            > http://www.apache.org/licenses/
            >
            > Tobi
            >
            >
            > --
            > http://www.pinkjuice.com/
          • Tobias Reif
            ... A very low and controllable one. Interoperability is something to work on (submitting bug reports etc), not something to spread FUD about (you didn t but
            Message 5 of 24 , Jul 1, 2002
            View Source
            • 0 Attachment
              mbier wrote:


              > Good points, of course SVG does inherently have many things going for
              > it. But I still think there *is* risk at this point as I have
              > commented on lately.


              A very low and controllable one. Interoperability is something to work
              on (submitting bug reports etc), not something to spread FUD about (you
              didn't but there's a risk).


              > I am well aware of Free software and copyleft perspectives. As I have
              > explained in the past, ASV is built upon the much of the same IP that
              > powers Adobe's key products: Acrobat, Photoshop, Illustrator, etc.
              > I'm sure you can understand the difficulty here. I am certain that
              > Adobe will never license this code under GNU.


              I also doubt it.

              > Nor do I see why they
              > should, honestly.


              Many people on this list are concerened about Adobe discontinuing
              support for the ASV, and they depend on it.

              So I wrote
              "Free Software gives the users the freedom to run, copy, distribute,
              study, change and improve the software. If a company goes out of
              business, or stops supporting a sofware application, users, communities
              of users, companies, or anyone else can continue to work on it. This
              also requires that the source code is shipped with the app, or is available.

              A FS license is the only way to guarantee that the app will always be
              available, and that it will always be possible to develop it further."


              > I don't want to start an OT discussion of Open Source religion


              We are discussing strategies, licenses, and user's needs, not religion.
              I don't throw you into the "Marketing Religion" corner, do I?


              > Nothing about that effort was free, with the possible exception of
              > the SVG Recommendation. But even there, Adobe had staff working on
              > that. SVG is an amazing opportunity.


              The ASV is being given away for zero $s. I can't see many disadvantages
              of making in GPLd or otherwise copylefted.

              > But for it to be the success
              > we all hope for, there must be a positive feedback loop where
              > Companies continue to support SVG, which drives more customers to
              > want to buy SVG solutions, which allows more product investment and
              > research.


              We're talking about the ASV, which does not cost money. I did not talk
              about licensing Illustrator under the GPL (which would be nice ;)
              nonetheless).

              Tobi

              --
              http://www.pinkjuice.com/
            • Jim Ley
              Tobias Reif ... rather ... Do you have a URL, for this reference implementation, it would be great to see - why are we using these
              Message 6 of 24 , Jul 1, 2002
              View Source
              • 0 Attachment
                "Tobias Reif" <tobiasreif@...>
                > Doug Schepers wrote:
                >
                > > consistant
                > > implementation to code to (I like the context menu extension a lot!),
                rather
                > > than relying on differing partial native implementation in different
                > > browsers, as has happened with CSS.
                >
                >
                > As discussed before, the risk for non-interoperable and non-conforming
                > full implementations is very low with SVG.
                >
                > There's a very concise spec, a test suite and -reports, and reference
                > implementations.

                Do you have a URL, for this reference implementation, it would be great
                to see - why are we using these partial implementations when there's a
                complete one out there!

                >All that is built on the XML concepts of
                > well-formedness and validity.

                Yet conforming viewers are required to render non well-formed documents
                (well they're required to render documents before they can know they are
                well formed, what happens when they discover they're not doesn't seem to
                be covered.)

                I think its clear that there's every bit as much a risk of having a
                non-interopable and non-conforming viewers with SVG as any other similar
                technology what is constraining it at the moment is not the ease of SVG
                development (what's so much harder about XHTML the spec is smaller yet
                you could hardly call that a success in this respect.) The problems that
                lead to non-standard support creaping into implementations are bugwards
                supporting features (where a dominant platform implements something
                wrongly so authors author to the bug not the spec - a number of W3 specs
                are happy to publish erratas on this though.) or from supporting features
                before they are a standard and ending up incorrectly implemented to the
                standard. SVG is so far avoiding these which is great, but I think it's
                luck rather than anything else. (the lack of competition in viewers
                actually helps here.)

                Jim.
              • Tobias Reif
                ... You are deliberately misunderstanding me. I won t further engage in an ironic thread like this. I referenced a post which says:
                Message 7 of 24 , Jul 1, 2002
                View Source
                • 0 Attachment
                  Jim Ley wrote:


                  > Do you have a URL, for this reference implementation, it would be great
                  > to see - why are we using these partial implementations when there's a
                  > complete one out there!


                  You are deliberately misunderstanding me. I won't further engage in an
                  ironic thread like this. I referenced a post which says:
                  http://groups.yahoo.com/group/svg-developers/message/17505
                  "There exist exquisite implementations which, inside the subset they
                  support, can mostly serve as reference: Batik, ASV."


                  > I think its clear that there's every bit as much a risk of having a
                  > non-interopable and non-conforming viewers with SVG as any other similar
                  > technology


                  False.

                  Did you read the posts I referenced?
                  http://groups.yahoo.com/group/svg-developers/message/17508
                  etc.

                  > The problems that
                  > lead to non-standard support creaping into implementations are bugwards
                  > supporting features (where a dominant platform implements something
                  > wrongly


                  test-suite

                  > or from supporting features
                  > before they are a standard and ending up incorrectly implemented to the
                  > standard.


                  test-suite, and developers who are fed up with browser hell, thus won't
                  accept this.

                  > SVG is so far avoiding these which is great, but I think it's
                  > luck rather than anything else.


                  Very untrue. How could it be luck if there are technical reasons?
                  HTML was *very* different than SVG; not just the standard, but the
                  specification and implementation process. The implementation process was
                  incorporated in W3C's SVG strategy.
                  I won't repeat all that's been said.

                  > (the lack of competition in viewers
                  > actually helps here.)


                  Very untrue. There are way more than five viewers.

                  I repeat that yes, interoperability is a challenge that's to be met, and
                  an issue that we should care about (submitting bugreports and test cases
                  is extremely important for us as a community), but there is not reason
                  to spread FUD based on the history of HTML. You can only do so if you
                  ignore the facts.

                  If we would have only one single closed source viewer by a single
                  company, nothing would be solved. Currently, this becomes clear to many.

                  Tobi

                  --
                  http://www.pinkjuice.com/
                • Jim Ley
                  Tobias Reif ... great ... a ... I was indeed, your statement was simply incorrect, there is no reference implementation, you
                  Message 8 of 24 , Jul 1, 2002
                  View Source
                  • 0 Attachment
                    "Tobias Reif" <tobiasreif@...>

                    > Jim Ley wrote:
                    >
                    > > Do you have a URL, for this reference implementation, it would be
                    great
                    > > to see - why are we using these partial implementations when there's
                    a
                    > > complete one out there!
                    >
                    >
                    > You are deliberately misunderstanding me.

                    I was indeed, your statement was simply incorrect, there is no reference
                    implementation, you complain (rightly) about mis-information then you
                    give it.

                    > I won't further engage in an
                    > ironic thread like this. I referenced a post which says:
                    > http://groups.yahoo.com/group/svg-developers/message/17505
                    > "There exist exquisite implementations which, inside the subset they
                    > support, can mostly serve as reference: Batik, ASV."

                    2? Are there not 2 implementations of every part of the spec (meaning
                    that at least 3 implementations need to exist unlee the 2 are complete)
                    You cannot have a reference implementation made up of parts of other
                    implementations, that makes the whole point of a reference implementation
                    nonsensical.

                    Your statement there rightly goes a long way short of calling it a
                    reference implementation.

                    > Did you read the posts I referenced?

                    Yes, I don't think they address my concerns, they do address some
                    concerns of how to create a standard document, but they do not cover the
                    bugwards compatibility problem.
                    > > The problems that
                    > > lead to non-standard support creaping into implementations are
                    bugwards
                    > > supporting features (where a dominant platform implements something
                    > > wrongly
                    >
                    > test-suite

                    How does that solve it? Or are you suggesting that the existence of a
                    test-suite prevents these problems, if it does how - where's the
                    enforcement process, and why do we have non-conformant viewers currently?

                    IE5.something on the Mac fully passes the CSS 1.0 test suite AIUI, yet
                    it's not conformant to the CSS1 Rec. I'd love to see details of the
                    results of SVG against the testsuite (in EARL of course) - then we can
                    also address how test-suites do not solve everything.

                    > > or from supporting features
                    > > before they are a standard and ending up incorrectly implemented to
                    the
                    > > standard.
                    >
                    > test-suite, and developers who are fed up with browser hell, thus won't
                    > accept this.

                    We seem all to be accepting the current SVG viewers, yet they aren't
                    conformant... I don't really understand how you can say that.

                    > > SVG is so far avoiding these which is great, but I think it's
                    > > luck rather than anything else.
                    >
                    > Very untrue. How could it be luck if there are technical reasons?

                    I don't agree there are technical reasons... there some elements of the
                    spec which help (the existence of the spec the tight integration between
                    spec authors and developers.) but those aren't technical ones.

                    > HTML was *very* different than SVG; not just the standard, but the
                    > specification and implementation process. The implementation process
                    was
                    > incorporated in W3C's SVG strategy.

                    I didn't mention HTML, I mentioned XHTML.

                    > Very untrue. There are way more than five viewers.

                    Yes, and how many are actually used to view commercially developed
                    content?

                    > If we would have only one single closed source viewer by a single
                    > company, nothing would be solved. Currently, this becomes clear to
                    many.

                    Whoever said that was desirable? I'm actually re-enforcing your view
                    that interop is hard, but I'm also not deluded into thinking there's a
                    technical solution.

                    Jim.
                  • Tobias Reif
                    Jim, there was a time where this was a friendly community; a time when people did not shout ironic stements at each other. My statement was incomplete, and was
                    Message 9 of 24 , Jul 1, 2002
                    View Source
                    • 0 Attachment
                      Jim,

                      there was a time where this was a friendly community; a time when people
                      did not shout ironic stements at each other.

                      My statement was incomplete, and was completed by a reference to the
                      more detailed and correct stament in the archive; it was was a place
                      holder for that. Since the post was just some weeks old, I did not
                      repeat all of it's content, but instead included the URL.

                      Answers to all of your other questions have either been answered here,
                      ar are available online.

                      If you find anything in any viewer that does not conform to the spec,
                      please report that bug to the developers. that's the "enforcement
                      process"; it works, because you can refer to a concise spec, correctly
                      implemented features, or/and to a test suite. It's up to the developers
                      themselves to submit any issues to the implementers.

                      > I'd love to see details of the
                      > results of SVG against the testsuite

                      Do you mean results of testing against the SVG test suite? Just look for it.

                      > then we can
                      > also address how test-suites do not solve everything.

                      Sure it doesn't; you youself listed "tight integration between spec
                      authors and developers", then there's the test suite, correctly
                      implemented features, and a very concise spec.

                      Tobi
                    • Jim Ley
                      Tobias Reif ... Unfortunately they haven t, like much of the discussion it focuses on technical issues, not human ones. ... for
                      Message 10 of 24 , Jul 1, 2002
                      View Source
                      • 0 Attachment
                        "Tobias Reif" <tobiasreif@...>

                        > Answers to all of your other questions have either been answered here,
                        > ar are available online.

                        Unfortunately they haven't, like much of the discussion it focuses on
                        technical issues, not human ones.

                        > If you find anything in any viewer that does not conform to the spec,
                        > please report that bug to the developers. that's the "enforcement
                        > process"; it works,

                        > > I'd love to see details of the
                        > > results of SVG against the testsuite
                        >
                        > Do you mean results of testing against the SVG test suite? Just look
                        for it.

                        Do you mean http://www.w3.org/Graphics/SVG/Test/BE-ImpStatus.html

                        It's somewhat out of date don't you think? (you also snipped my "in EARL"
                        of course, but that was tongue in cheek.)

                        > > then we can
                        > > also address how test-suites do not solve everything.
                        >
                        > Sure it doesn't; you youself listed "tight integration between spec
                        > authors and developers", then there's the test suite, correctly
                        > implemented features, and a very concise spec.

                        One of my points is that implementors such as IE will probably not have
                        that same tight integration (even within the W3, the developers in IE are
                        generally distinct to those involved for some reason I understand.)
                        We've also only got one version of the spec, once we get Edition 1.2 and
                        2.0 we start to have the larger problem. (that's what happened to HTML
                        for example.)

                        Jim.
                      • Tobias Reif
                        ... Just read what Chris wrote about HTML. I repeat: there is no reason to spread FUD based on the history of HTML. With SVG, a lot of factors are *different*.
                        Message 11 of 24 , Jul 1, 2002
                        View Source
                        • 0 Attachment
                          Jim Ley wrote:


                          > (that's what happened to HTML
                          > for example.)


                          Just read what Chris wrote about HTML. I repeat: there is no reason to
                          spread FUD based on the history of HTML.


                          With SVG, a lot of factors are *different*.

                          Tobi

                          --
                          http://www.pinkjuice.com/
                        • (no author)
                          3D209E3E.2080400@pinkjuice.com Subject: Re: [svg-developers] SVG in Google... Date: Mon, 1 Jul 2002 18:30:27 -0000 MIME-Version: 1.0 Content-Type: text/plain;
                          Message 12 of 24 , Jul 1, 2002
                          View Source
                          • 0 Attachment
                            "Tobias Reif" <tobiasreif@...>
                            > Jim Ley wrote:
                            >
                            > > (that's what happened to HTML for example.)
                            >
                            > Just read what Chris wrote about HTML. I repeat: there is no reason to
                            > spread FUD based on the history of HTML.

                            None of what Chris wrote addresses my concerns and my arguments for why
                            there is a risk of incompatibility coming in, My "that's what happened to
                            HTML for example" highlighted the fact that it wasn't until people wanted
                            to go beyond the initial spec that anyone had any interopability
                            problems.

                            As Chris himself says:

                            "With SVG, on the other hand, the spec came first and was developed
                            with the willing participation of the implementors"

                            Yet, now many people, including me, are advocating support for more
                            viewers with native support in Mozilla, IE, Konquerer etc. the more
                            implementors we have the less people we have involved in that process
                            (and they may balk at certain decisions in the spec like the use
                            text/ecmascript which Netscape/Mozilla are already doing.) and the more
                            likely we are to get bugs and bugwards compatible authoring.

                            How many authors do you think validate their SVG?

                            > With SVG, a lot of factors are *different*.

                            And lots are the same.

                            Jim.
                          Your message has been successfully submitted and would be delivered to recipients shortly.