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

[svg-developers] Questions 1 - 8

Expand Messages
  • david dailey
    As threatened in an earlier post, I have several new questions that I ve been toying with. I suspect someone knows. 1. Is there a way, using filters, to take
    Message 1 of 30 , Dec 9, 2005
    View Source
    • 0 Attachment
      As threatened in an earlier post, I have several new questions that
      I've been toying with. I suspect someone knows.

      1. Is there a way, using filters, to take an image A and produce it
      photographic negative A', such that 255-C(A)=C(A') for each channel C
      in {R,G,B)? I've fooled a bit with the filter "feComponentTransfer"
      with some hints of success, but it seems like so natural a thing that
      there must be a straightforward way that I'm just missing.

      2. On a related theme, <feBlend/> has modes including "screen",
      "multiply" etc. Is there a way to create the "difference" between two
      images (as with the Photoshop difference filter) in SVG?

      3. If I deform a simple shape using < feDisplacementMap/> (see for
      example http://srufaculty.sru.edu/david.dailey/svg/eggcloning3.svg
      where the user may unleash fried eggs bouncing and sliding over a
      radial washboard) is there any way to determine exactly how far an
      image has been moved by that transformation? id est what is the
      on-screen locus of a shape deformed by a transformation? If so, then
      I'd be able to determine RGB values of pixels in the underlying image
      and that could prove quite handy for other things. Are there other
      ways to interrogate RGB values of pixels ?

      4. In the above animation, I observe that on slower machines its SMIL
      animation takes precedence over its JavaScript animation. That is, if
      the browser can't keep up with the SMIL (because there is too much
      processing going on) it never begins the JavaScript animation. Is
      there anyway to adjust the relative priorities of these two kinds of events?

      5. Is there any difference between O.setAttributeNS(null, attribute,
      value) and O.setAttribute(attribute, value) ? Both seem to work fine
      in both IE/ASV and Firefox. I've been intermingling them
      superstitiously in my code.

      6. To make a jig-saw puzzle, one may chop up an image into little
      movable chunks using numerous clipPaths applied to numerous copies of
      an image (see for example,
      http://marble.sru.edu/~ddailey/svg/clipembed16.html). The problem is
      that this actually uses lots of RAM. Is there anyway to just grab the
      pixels out of a rectangular section of a bitmap in SVG and move
      (just) them around? I used to do stuff like this in MacPascal a
      couple of decades ago. Again, I think I may just be missing something
      key in the tool set provided.

      7. Has anybody built a "distort" widget which would allow one corner
      of a rectangular bitmap to be grabbed and moved about, hence
      distorting (not just skewing) the associated image? I suppose
      transform="matrix(a,b,c,d,e,f)" will do the trick, but if somebody
      has already done this, it might save me some time.

      8. Does it make sense to submit all these questions as a block or
      would it be better to send seven (8?) e-mails to the list?

      Thanks in advance, and cheers
      David
    • Chris Lilley
      On Friday, December 9, 2005, 7:32:48 PM, Jim wrote: JL ayrton_senna_lives_ok wrote in message JL
      Message 2 of 30 , Dec 9, 2005
      View Source
      • 0 Attachment
        On Friday, December 9, 2005, 7:32:48 PM, Jim wrote:

        JL> "ayrton_senna_lives_ok" <ayrton_senna_lives_ok@...> wrote in message
        JL> news:dnc7d1+i2mh@......
        >> --- In svg-developers@yahoogroups.com, "Leonard Rosenthol"
        >> <leonardr@l...> wrote:
        >> 6. It is relaxing for humans to write. So orderly.
        >>
        >> 7. It is easy for humans to edit. So free of overheads.

        JL> The majority of XML on the internet is neither well-formed or valid, I can't
        JL> see how the easy to author or produce is a good argument, because all
        JL> evidence is that people do an absolutely lousy job of authoring it.

        If its not well formed it isn't XML. I agree that the majority of stuff
        that looks lie XML on the Web is not well formed - its HTML, mostly, or
        'save as web' html-like wordprocessor excretions.

        If its not valid, though, well, valid to what? As Michael
        Sperberg-McQueen said at his talk at XML 2005 this year, being valid is
        not like being married.


        censeo DTDem esse delendam

        --
        Chris Lilley mailto:chris@...
        Chair, W3C SVG Working Group
        W3C Graphics Activity Lead
        Co-Chair, W3C Hypertext CG
        with apologies to Cato
      • Jim Ley
        Chris Lilley wrote in message news:403685417.20051210013501@w3.org... ... I was actually more thinking of RSS and similar, HTML is not and
        Message 3 of 30 , Dec 9, 2005
        View Source
        • 0 Attachment
          "Chris Lilley" <chris@...> wrote in message
          news:403685417.20051210013501@......
          > On Friday, December 9, 2005, 7:32:48 PM, Jim wrote:
          > If its not well formed it isn't XML. I agree that the majority of stuff
          > that looks lie XML on the Web is not well formed - its HTML, mostly, or
          > 'save as web' html-like wordprocessor excretions.

          I was actually more thinking of RSS and similar, HTML is not and should not
          be XML, RSS, SVG etc. is intended to be XML, and that intention is what
          makes it invalid.

          > If its not valid, though, well, valid to what?

          To what the intention was to be valid to, you've just spent a lot of time
          creating things like Section C.3 in the 1.2 mobile draft, which you're now
          saying is irrelevant as SVG content cannot be non-WF as it won't be XML, and
          therefore not SVG?

          Cheers,

          Jim.
        • domenico_strazzullo
          ... Quod censueris faciam. ... message ... valid, I can t ... because all ... authoring it. ... stuff ... mostly, or ... valid is
          Message 4 of 30 , Dec 10, 2005
          View Source
          • 0 Attachment
            --- In svg-developers@yahoogroups.com, Chris Lilley <chris@w...>
            wrote:

            > censeo DTDem esse delendam

            Quod censueris faciam.



            >
            > On Friday, December 9, 2005, 7:32:48 PM, Jim wrote:
            >
            > JL> "ayrton_senna_lives_ok" <ayrton_senna_lives_ok@y...> wrote in
            message
            > JL> news:dnc7d1+i2mh@e...
            > >> --- In svg-developers@yahoogroups.com, "Leonard Rosenthol"
            > >> <leonardr@l...> wrote:
            > >> 6. It is relaxing for humans to write. So orderly.
            > >>
            > >> 7. It is easy for humans to edit. So free of overheads.
            >
            > JL> The majority of XML on the internet is neither well-formed or
            valid, I can't
            > JL> see how the easy to author or produce is a good argument,
            because all
            > JL> evidence is that people do an absolutely lousy job of
            authoring it.
            >
            > If its not well formed it isn't XML. I agree that the majority of
            stuff
            > that looks lie XML on the Web is not well formed - its HTML,
            mostly, or
            > 'save as web' html-like wordprocessor excretions.
            >
            > If its not valid, though, well, valid to what? As Michael
            > Sperberg-McQueen said at his talk at XML 2005 this year, being
            valid is
            > not like being married.
            >
            >
            > censeo DTDem esse delendam
            >
            > --
            > Chris Lilley mailto:chris@w...
            > Chair, W3C SVG Working Group
            > W3C Graphics Activity Lead
            > Co-Chair, W3C Hypertext CG
            > with apologies to Cato
            >
          • Francis Hemsher
            Latine loqui coactus sum... Ad praesens ova cras pullis sunt meliora
            Message 5 of 30 , Dec 10, 2005
            View Source
            • 0 Attachment
              Latine loqui coactus sum...
              Ad praesens ova cras pullis sunt meliora

              --- In svg-developers@yahoogroups.com, "domenico_strazzullo" <nst@d...>
              wrote:
              >
              > --- In svg-developers@yahoogroups.com, Chris Lilley <chris@w...>
              > wrote:
              >
              > > censeo DTDem esse delendam
              >
              > Quod censueris faciam.
              >
              >
            • Garry Haywood
              [author s note: This is a bit of long one, adn not really about developments in SVG, but where SVG fits into the big picture of business and economics and why
              Message 6 of 30 , Dec 12, 2005
              View Source
              • 0 Attachment
                [author's note: This is a bit of long one, adn not really about
                developments in SVG, but where SVG fits into the big picture of
                business and economics and why XML is better (than what?)]

                The argument for XML is not really a technological one, but a
                business and economic one. Which technologies to use is not a
                discussion that business strategists are having right now, and it is
                certainly not one that economists are having either.

                And you should beleive that IT strategists are NOT in the driving
                seat (that was a temporaray blip through dot.com madness), they are
                not even the navigators any longer. The have be backlined to
                technicans seat (again).

                The full investment cycle for business/government is a long time (7-
                11 years) and ask any economist they will tell you that the new
                technology driver is a) expanding the cycle not shortening it and b)
                reinvestment is globally directed at margin extratction not at IT
                investment.

                Info Technology has been (rightly IMHO) demoted back to toolkit. But
                there is an intersting shift here that is important to this
                discussion about XML, as shareholders would like to see the ROI they
                were promised at the the begining of this cycle stabilised to yeild
                (ie coverting their investment into regualar stable dividends).
                Shareholders are saying you have invested our money in all this kit
                that can talk to one and other, so let it talk...

                XML is better because because it makes for interoperability, and in
                the new business world metricification neccesitates interoperability.
                And because XML has validation, it scores highly for interoperability.

                All capitalised Business has two meta-rules: externalise costs;
                internalise revenue. (Any one who operates outside of this rule-set
                is having a laugh a the expense of someone elses' capital reserve.)

                From an economic point of view the metrification of this rule-set is
                the key consolidated reason d'etre of IT. And in a changing global
                economy (rapid expansion of the business footprint globally, to the
                structural tranformation of the business population) requires that
                business units can talk to one and other easily, cost-effectivily and
                transparently.

                Administrators in both Business and government need to share metrics.
                The so-called 'economic miracle' of the dot.com era was that we saw a
                rapidaly expanding number of business transactions, yet the amortised
                cost of the transactions hardly changed - partcualy when the cost of
                IT was discounted against the necessary re-invetment and
                capitalisation. This is what made dot.com so sexy.

                While the spotlight for dot.com was on business-to-consumer
                tranasctions, and the partially exposed business-to-busines model,
                what economic analysts began to see was that the real long term
                benefits of this technology was instrinsic metrification of the whole
                business cycle and producting business descision frameworks that
                were both shorter in timescale and wider in coverage making it
                possible to make more cost-benefical decisisons. This even tirumphs
                over the content-specific industries (new and old) because it is the
                same semantic.

                And this understanding is now being widely adopted at the root of the
                investment cycle: with corporate investors. An emerging consensus has
                appeared that says the ROI for IT is in greater metrification. This
                is the discussion that business strategist and economists are
                having: How we our existing IT investment help use externalise costs
                and internalise revenue?

                Economic gain from IT in the last 25 years (stretching over 4/5 years
                economic cycles) has seem more yield from back-end integration than
                front-office fulfillment. Inverstors would like to see more of this.
                And more of this is delivered through interoperability.

                The business community (and governments) have already started turning
                this super-tanker in the direction of interoprability and XML is due
                North. The investor community now has a healthy cyncisim towards IT-
                hype, and the lag in economic understanding about the what IT does
                for business is closing. We have moved to a paradigm where IT
                investment must now be consolidated by increasing interoperability.

                This is what XML offers. Consolidation of invetment and increased
                operability across business-functions (internally and externally).

                SVG is part of this paradigm. It is a cliche that "one picture can
                speak a thousand words" and thats why you, dear reader, are on this
                list. You know that there is a requirement to present consolidated
                metrics in graphical format - what ever it is you are metrifying.

                My engagement with SVG has been relatively recent - and I'm a weird
                species of econmist/developer/researcher/analyst/strategist - but in
                this period I have seen a very common element to all the workings of
                this community and what you/we are trying to do with XML/SVG: make
                better decisions that cost less yet have more impact.

                Having a common, underlying language/framework that enables to do
                this is why SVG being in XML better.










                Business likes standards - do not let the anti-regulation talk fool
                you - but they are happy to have competeting standards and XML will
                be one of them

                --- In svg-developers@yahoogroups.com, "Francis Hemsher"
                <Francis.Hemsher@M...> wrote:
                >
                > Latine loqui coactus sum...
                > Ad praesens ova cras pullis sunt meliora
                >
                > --- In svg-developers@yahoogroups.com, "domenico_strazzullo"
                <nst@d...>
                > wrote:
                > >
                > > --- In svg-developers@yahoogroups.com, Chris Lilley <chris@w...>
                > > wrote:
                > >
                > > > censeo DTDem esse delendam
                > >
                > > Quod censueris faciam.
                > >
                > >
                >
              • Garry Haywood
                oops, i posted this before I had finished (both argument and proofing) so it s full of typos, poor gramma and some missing syntax! But i hope the trajectory is
                Message 7 of 30 , Dec 12, 2005
                View Source
                • 0 Attachment
                  oops, i posted this before I had finished (both argument and
                  proofing) so it's full of typos, poor gramma and some missing syntax!

                  But i hope the trajectory is clear...

                  --- In svg-developers@yahoogroups.com, "Garry Haywood" <garry@b...>
                  wrote:
                  >
                  > [author's note: This is a bit of long one, adn not really about
                  > developments in SVG, but where SVG fits into the big picture of
                  > business and economics and why XML is better (than what?)]
                  >
                  > The argument for XML is not really a technological one, but a
                  > business and economic one. Which technologies to use is not a
                  > discussion that business strategists are having right now, and it
                  is
                  > certainly not one that economists are having either.
                  >
                  > And you should beleive that IT strategists are NOT in the driving
                  > seat (that was a temporaray blip through dot.com madness), they are
                  > not even the navigators any longer. The have be backlined to
                  > technicans seat (again).
                  >
                  > The full investment cycle for business/government is a long time (7-
                  > 11 years) and ask any economist they will tell you that the new
                  > technology driver is a) expanding the cycle not shortening it and
                  b)
                  > reinvestment is globally directed at margin extratction not at IT
                  > investment.
                  >
                  > Info Technology has been (rightly IMHO) demoted back to toolkit.
                  But
                  > there is an intersting shift here that is important to this
                  > discussion about XML, as shareholders would like to see the ROI
                  they
                  > were promised at the the begining of this cycle stabilised to yeild
                  > (ie coverting their investment into regualar stable dividends).
                  > Shareholders are saying you have invested our money in all this kit
                  > that can talk to one and other, so let it talk...
                  >
                  > XML is better because because it makes for interoperability, and in
                  > the new business world metricification neccesitates
                  interoperability.
                  > And because XML has validation, it scores highly for
                  interoperability.
                  >
                  > All capitalised Business has two meta-rules: externalise costs;
                  > internalise revenue. (Any one who operates outside of this rule-set
                  > is having a laugh a the expense of someone elses' capital reserve.)
                  >
                  > From an economic point of view the metrification of this rule-set
                  is
                  > the key consolidated reason d'etre of IT. And in a changing global
                  > economy (rapid expansion of the business footprint globally, to the
                  > structural tranformation of the business population) requires that
                  > business units can talk to one and other easily, cost-effectivily
                  and
                  > transparently.
                  >
                  > Administrators in both Business and government need to share
                  metrics.
                  > The so-called 'economic miracle' of the dot.com era was that we saw
                  a
                  > rapidaly expanding number of business transactions, yet the
                  amortised
                  > cost of the transactions hardly changed - partcualy when the cost
                  of
                  > IT was discounted against the necessary re-invetment and
                  > capitalisation. This is what made dot.com so sexy.
                  >
                  > While the spotlight for dot.com was on business-to-consumer
                  > tranasctions, and the partially exposed business-to-busines model,
                  > what economic analysts began to see was that the real long term
                  > benefits of this technology was instrinsic metrification of the
                  whole
                  > business cycle and producting business descision frameworks that
                  > were both shorter in timescale and wider in coverage making it
                  > possible to make more cost-benefical decisisons. This even tirumphs
                  > over the content-specific industries (new and old) because it is
                  the
                  > same semantic.
                  >
                  > And this understanding is now being widely adopted at the root of
                  the
                  > investment cycle: with corporate investors. An emerging consensus
                  has
                  > appeared that says the ROI for IT is in greater metrification. This
                  > is the discussion that business strategist and economists are
                  > having: How we our existing IT investment help use externalise
                  costs
                  > and internalise revenue?
                  >
                  > Economic gain from IT in the last 25 years (stretching over 4/5
                  years
                  > economic cycles) has seem more yield from back-end integration than
                  > front-office fulfillment. Inverstors would like to see more of
                  this.
                  > And more of this is delivered through interoperability.
                  >
                  > The business community (and governments) have already started
                  turning
                  > this super-tanker in the direction of interoprability and XML is
                  due
                  > North. The investor community now has a healthy cyncisim towards IT-
                  > hype, and the lag in economic understanding about the what IT does
                  > for business is closing. We have moved to a paradigm where IT
                  > investment must now be consolidated by increasing interoperability.
                  >
                  > This is what XML offers. Consolidation of invetment and increased
                  > operability across business-functions (internally and externally).
                  >
                  > SVG is part of this paradigm. It is a cliche that "one picture can
                  > speak a thousand words" and thats why you, dear reader, are on this
                  > list. You know that there is a requirement to present consolidated
                  > metrics in graphical format - what ever it is you are metrifying.
                  >
                  > My engagement with SVG has been relatively recent - and I'm a weird
                  > species of econmist/developer/researcher/analyst/strategist - but
                  in
                  > this period I have seen a very common element to all the workings
                  of
                  > this community and what you/we are trying to do with XML/SVG: make
                  > better decisions that cost less yet have more impact.
                  >
                  > Having a common, underlying language/framework that enables to do
                  > this is why SVG being in XML better.
                  >
                  >
                  >
                  >
                  >
                  >
                  >
                  >
                  >
                  >
                  > Business likes standards - do not let the anti-regulation talk fool
                  > you - but they are happy to have competeting standards and XML will
                  > be one of them
                  >
                  > --- In svg-developers@yahoogroups.com, "Francis Hemsher"
                  > <Francis.Hemsher@M...> wrote:
                  > >
                  > > Latine loqui coactus sum...
                  > > Ad praesens ova cras pullis sunt meliora
                  > >
                  > > --- In svg-developers@yahoogroups.com, "domenico_strazzullo"
                  > <nst@d...>
                  > > wrote:
                  > > >
                  > > > --- In svg-developers@yahoogroups.com, Chris Lilley
                  <chris@w...>
                  > > > wrote:
                  > > >
                  > > > > censeo DTDem esse delendam
                  > > >
                  > > > Quod censueris faciam.
                  > > >
                  > > >
                  > >
                  >
                • david dailey
                  ... [Questions 1 through 8] I figured out answers to two of my 8 questions and thought I d share: #1. Is there a way, using filters, to take an image A and
                  Message 8 of 30 , Dec 12, 2005
                  View Source
                  • 0 Attachment
                    At 03:13 PM 12/9/2005, Iwrote:
                    >As threatened in an earlier post, I have several new questions that
                    >I've been toying with. I suspect someone knows.
                    [Questions 1 through 8]

                    I figured out answers to two of my 8 questions and thought I'd share:

                    #1. > Is there a way, using filters, to take an image A and produce it
                    photographic negative A', such that 255-C(A)=C(A') for each channel C
                    in {R,G,B)?

                    I'm not sure if this is the easiest way, but the following seems to
                    do it. (at least, adding the result back to the original results in a
                    monochromatic white rectangle, apparently regardless of the initial image):

                    <feComponentTransfer>
                    <feFuncR type="table" tableValues="1 0" />
                    <feFuncG type="table" tableValues="1 0" />
                    <feFuncB type="table" tableValues="1 0" />
                    </feComponentTransfer>

                    #8 > Does it make sense to submit all these questions as a block or
                    would it be better to send seven (8?) e-mails to the list?

                    Anecdotally, it appears the answer is that a block of 8 questions may
                    be too many all at once. I'll revisit some of the remaining questions
                    with some more manageable query-rate.

                    regards,
                    David Dailey
                  • Jim Ley
                    Garry Haywood wrote in message news:dnjps8+2ik9@eGroups.com... ... The problem is your argument is for backend interopabilty, here XML
                    Message 9 of 30 , Dec 12, 2005
                    View Source
                    • 0 Attachment
                      "Garry Haywood" <garry@...> wrote in message
                      news:dnjps8+2ik9@......
                      > XML is better because because it makes for interoperability, and in
                      > the new business world metricification neccesitates interoperability.
                      > And because XML has validation, it scores highly for interoperability.

                      The problem is your argument is for backend interopabilty, here XML scores
                      highly, where it scores very badly is in user-centric content - stuff
                      authored / consumed by users rather than machines, that is where XML falls
                      down so badly - we have much less interopability in the XML web today, than
                      we do in the HTML web.

                      The XML RSS feeds are broken all over the place, the HTML world, well just
                      about anything can render that.

                      There's no obvious reason why the rendering needs to be shipped around as
                      XML.

                      Jim.
                    • Garry Haywood
                      ... well just ... around as ... you are absolutley right, who said SVG was the only rendering system? not me I was talking about why is XML is better for SVG
                      Message 10 of 30 , Dec 12, 2005
                      View Source
                      • 0 Attachment
                        --- In svg-developers@yahoogroups.com, "Jim Ley" <jim@j...> wrote:

                        >
                        > The XML RSS feeds are broken all over the place, the HTML world,
                        well just
                        > about anything can render that.
                        >
                        > There's no obvious reason why the rendering needs to be shipped
                        around as
                        > XML.
                        >
                        > Jim.
                        >

                        you are absolutley right, who said SVG was the only rendering system?
                        not me

                        I was talking about why is XML is better for SVG than any other mark-
                        up, particuarly if SVG is to grow into a mature rendering mark-up
                        that is part of a component based semantic web that replaces HTML,
                        eventually, because HTML needs to be more than just a rendering mark-
                        up. It's not a technical issue. If XML is the common markup for this
                        symantic matrix of data, transformations, queries, etc then SVG, as a
                        mature UI rendering system should be too.

                        Having a common semantic across different functions of the document
                        object model, including rendering, is good: everything is parsed for
                        validation once, by one process, before it gets distributed for
                        construction - standardisation like this should result in
                        less 'rejection' - that fact that we are not making anything does not
                        mean rejects don't cost money. It is, in economic terms and within a
                        broad statistical framework, efficient for SVG to be in XML, as the
                        common rendering markup of the semantic web. That was my point, not
                        that its a technical requirement. And it really is an humble opinion:
                        in preparing this answer I have rehersed the case for and I still
                        think it make sense for SVG to be in XML, and it I think it will
                        become as instrisicin in the prevailing economic mode as fordism
                        was/is to manufacturing era.

                        The only reason to adopt an alternative mark-up for SVG is that
                        current one -XML, what everything else is being shipped in - is not
                        adequate because it is not specialised enough - e.g for Math, CAD,
                        Chemistry, etc - or its verbosity is a source of congestion where
                        something more streamlined might be in order. But if you think
                        otherwise I would like to know has your view is highly regarded here.

                        And that so much RSS is broken hardly matters - its mostly terminated
                        anyway. It arrives at the final consumer and if it's broken but
                        consumable who cares? Not the consumer. However if your repackaging
                        data for forward use - like Reuters RSS feeds for example - the
                        source has to work, it can't be broken... having it comply and
                        validate in XML is necessary thing...

                        But thanks for the challenge, it was interesting to think this through

                        Garry
                      • Jim Ley
                        Garry Haywood wrote in message news:dnl608+oikb@eGroups.com... ... yet your arguments focuses purely on non-human advantages,
                        Message 11 of 30 , Dec 12, 2005
                        View Source
                        • 0 Attachment
                          "Garry Haywood" <garry@...> wrote in message
                          news:dnl608+oikb@......
                          > --- In svg-developers@yahoogroups.com, "Jim Ley" <jim@j...> wrote:

                          > I was talking about why is XML is better for SVG than any other mark-
                          > up,

                          yet your arguments focuses purely on non-human advantages, disregarding the
                          human aspects which make XML a poor choice for SVG.

                          the biggest is the must fail and not show anything under pretty much any
                          error, this is great for machines, it's useless for humans, humans value
                          content over accuracy, "an error occured parsing document X" is bad for a
                          user, they get no value. If however they got the drawing but it was a bit
                          wrong, they'd know it was wrong, but it might only be wrong in a way that
                          didn't effect their access to the content.

                          > particuarly if SVG is to grow into a mature rendering mark-up
                          > that is part of a component based semantic web that replaces HTML,
                          > eventually, because HTML needs to be more than just a rendering mark-
                          > up.

                          No, HTML does not need to be more than rendering, this is the exact mistake
                          of pushing the meaning into the rendering, confusing the 2 does nothing to
                          help. Indeed it's not clear that XML has much traction in the semantic web
                          developments currently existing, the microformats are all in HTML, and RDF
                          has many serialisations only 1 of which is XML

                          > then SVG, as a mature UI rendering system should be too.

                          That's not obvious, you're not going to say it's obvious that video or
                          images are in XML, so why is it obvious that SVG is, or why the path syntax
                          is a format rather than XML?

                          > It is, in economic terms and within a
                          > broad statistical framework, efficient for SVG to be in XML, as the
                          > common rendering markup of the semantic web.

                          I can't see that being so obvious, an XML format for video is not efficient,
                          and the overhead of a seperate parser is certainly not going to enough to
                          make it so, it is not obvious that it would be different for SVG.

                          > And that so much RSS is broken hardly matters - its mostly terminated
                          > anyway. It arrives at the final consumer and if it's broken but
                          > consumable who cares? Not the consumer.

                          They most certainly do care, if the rules of XML are adhered to over failure
                          then the user doesn't get their content.

                          If however the rules of XML are relaxed and errors are recovered, then we
                          lose the benefits of XML in non-user centric languages.

                          > However if your repackaging
                          > data for forward use - like Reuters RSS feeds for example

                          There are lots of people repackaging invalid RSS feeds, they're mostly
                          ignoring the validity constraints of XML, I think this is a bad thing, XML
                          has too many uses to be sullied in this way, but it will happen to all
                          user-centric XML languages, as users care more about content than anything
                          else.

                          There's not an obvious alternative to XML for SVG, but the rules of XML are
                          too strict for SVG.

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