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

Re: [svg-developers] Re: Re: SOAP

Expand Messages
  • Robin Berjon
    Hi Ronan, ... That depends on what the rest is and on how much hope we have of it being good on its own, in a reasonably close future. If you allow me, I m
    Message 1 of 25 , Jun 2, 2003
    • 0 Attachment
      Hi Ronan,

      ronan@... wrote:
      > My point is not about whether or not certain methods have a place in ECMA
      > scripting or other technology. my point is that I am concerned that we are
      > bundling too many technologies within the SVG specification. Is it not enough
      > to say 'SVG must support ECMAscript' and leave the rest to ECMAscript?

      That depends on what "the rest" is and on how much hope we have of it being good
      on its own, in a reasonably close future.

      If you allow me, I'm going to push it a bit here, but I think not that much. In
      no way is getURL EcmaScript specific. EcmaScript defines a language. getURL
      belongs in an API.

      Now both EcmaScript and SVG define APIs, so on which side of the fence does it
      fall? You may be tempted to say "on the EcmaScript side, because it belongs in a
      language specification". I won't debate whether that's true or not as it is a
      matter of API design that goes well beyond the scope of this list. I will
      however extend your reasoning: would methods for dealing with points in a 2D
      space, or with 2D geometric forms, belong in a generic library outside of SVG?

      Ideally, probably. In practice, different decisions have to be made to
      compensate for the fact that there isn't a standard consortium working on every
      possible good idea (thank $DEITY).

      > It seems odd to me to have the specification for
      > particular JS methods specified within SVG, rather than specifying them within
      > the technology that SVG relies on.

      Have you looked at the SVG DOM? It specifies a *lot* of methods. I don't think
      we can discuss whether or not it should do that because it's been doing so since
      1.0 and I don't think you are against it any more than I am.

      > Going too far beyond that, we are
      > increasingly running the risk of turning SVG into Mozilla or IE - an unwieldly
      > behemoth that does everything and does nothing well.

      I think we are all aware of that. But because adding stuff may cause bloat
      doesn't mean that adding feature foo will cause bloat.

      Also please remember that someone's bloat is someone else's vital feature. I
      could probably live for instance with less advanced compositing. I do however
      recognize the need for it.

      That leaves the hard task of picking whose "vital features" to take in and whose
      to leave out. I personally think that "having been requested several times" and
      "not possible otherwise" are good indicators for inclusion. A lot of people
      clearly want to use SVG for Web applications, and a number of those have asked
      for better network/HTTP integration, notably for things like DAV interfaces or
      IRC clients.

      > I just don't see where the behaviour of a javascript function falls within the
      > SVG specification. For example, the SVG spec invokes the DOM spec, but does not
      > re-state it.

      I don't believe that you haven't noticed just how much it adds to it!

      > Wouldn't it be cleaner to keep this distinction from becoming to blurry, and
      > perhaps have a user-agent specification?

      In an ideal world, I think every one would be happier with a UA WG doing that
      part of the work. There is no such thing and little hope of it existing that I
      can see.

      But consider this: if it did exist, SVG would likely adopt pretty much
      everything that it would specify. This would lead to SVG still having getURL and
      friends, except they'd be in by reference and not by value. But the net effect
      is the same: they'd be there! So does it really matter if the SVG Rec here and
      there doubles up as a UA Rec? Not much. Other specs are free to reuse parts of
      it, and either way, after references are resolved, SVG remains exactly the same.

      The more I discuss this the more the feeling grows on me that wanting those
      features but wishing they were in a separate spec is an aesthetic wish more than
      anything else.

      > I am not sure what you mean when you say that SVG is not about markup. SVG is
      > 100% about markup and about its interpretation, by definition. SVG *is* XML. To
      > say SVG is not markup is like saying HTML is not (another form of) markup. This
      > seems highly misleading to me, and symptomatic of the XML advocates efforts to
      > make XML seem to be more than it is.

      What I mean is that SVG does extremely little in matters of defining markup,
      especially compared to the rest of what it does. SVG defers all lexical matters
      (well, with exceptions such as the path mini-language) to XML. Regarding markup,
      all it does is say "use XML, and use those element/attribute/etc names". You add
      "interpretation" to it, and I agree. That, however, is not markup. It's what
      happens when markup for element <foo> is seen, which is entirely different,
      especially as you can make the same thing happen simply adding that element
      <foo> to the DOM, and no markup is ever involved.

      I am not pretending that XML does more than it is. /On the contrary/, I'm saying
      that all it does is specify a syntax for markup. SVG specifies a lot more:
      behaviour, rendering, animation, scripting, APIs... Saying, as you did, that
      something shouldn't be in SVG because it has nothing to do with markup is saying
      that SVG is defined by it's DTD, and that we can eliminate the other few hundred
      pages around it saying what happens when an SVG UA reads an SVG document :)

      --
      Robin Berjon <robin.berjon@...>
      Research Engineer, Expway http://expway.fr/
      7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
    • Jim Ley
      wrote in message news:1054555019.3edb3b8b30177@roasp.com... ... such ... I don t see them in any way scripting specific, setTimeout as
      Message 2 of 25 , Jun 2, 2003
      • 0 Attachment
        <ronan@...> wrote in message
        news:1054555019.3edb3b8b30177@......
        > Right. Agreed about the kludge bit.
        >
        > I have to be honest, I do not see why scripting-specific helper functions
        such
        > as getURL/postURL are being put into the SVG spec.

        I don't see them in any way scripting specific, setTimeout as specified
        currently is much worse than those (seen as it requires a parser) but getURL
        is implementable in most languages.

        > They're handy, but are they
        > not part of ECMAScripting land?

        ECMAScript have only ever done core language, there's no I/O of any sort (no
        HTTP, no disk IO, no User input/output methods of any kind)

        > I don't see the association with markup. And
        > let's not forget WHY they are so crippled. HELLO?? SECURITY??

        Not be able to set headers has nothing to do with security, Mozilla and IE
        already offer that functionality, and it's no more insecure than letting
        them do anything else.

        > Dont get me
        > wrong, I'm addicted to get/postURL and parseXML. I can't go without them
        and
        > welcome extensions/improvements/acceptance of these methods. But within
        the SVG
        > spec?

        Neither do I, I don't think RAX should be in SVG's world either, in fact the
        SVG WG seem to take on much which wouldn't in an ideal world be part of
        their remit, however, because they need it to create what us developers
        want, they're forced into doing it or leaving needed functionality out.
        getURL isn't in ECMA TG39's remit (not that they seem to be doing much since
        they got CLI/C# to do aswell) there's no agency anywhere who's remit it is
        in, so the SVG WG would either have to try and get an appropriate group
        chartered within the W3 or just do it themselves. Do it themselves seems
        reasonable.

        Jim.
      • Jim Ley
        wrote in message news:1054556072.3edb3fa8b1829@roasp.com... ... wish ... is ... Which is perfectly possible, you don t need anything that
        Message 3 of 25 , Jun 2, 2003
        • 0 Attachment
          <ronan@...> wrote in message
          news:1054556072.3edb3fa8b1829@......

          > Nevertheless, maybe I want to use getURL to get a decision made for me and
          wish
          > to interpret this decision by running a regex on the result string. This
          is
          > equally feasible.

          Which is perfectly possible, you don't need anything that ECMAScript doesn't
          give you.

          > > postURL is an extension of DOM2 and I think that's ok.
          > > I hope DOM3 will have this without extending the DOM standard.

          postURL is nothing to do with DOM2 or DOM3 and I can't see any DOM ever
          supporting it (DOM relates to XML, postURL has nothing to do with XML)

          Jim.
        • Bernhard Zwischenbrugger
          Hi ... Maybe I m wrong but DOM3 save/load looks like they try to do that kind of things:
          Message 4 of 25 , Jun 2, 2003
          • 0 Attachment
            Hi

            > postURL is nothing to do with DOM2 or DOM3 and I can't see any DOM ever
            > supporting it (DOM relates to XML, postURL has nothing to do with XML)

            Maybe I'm wrong but DOM3 save/load looks like they try to do that kind
            of things:


            http://www.w3.org/TR/2003/WD-DOM-Level-3-LS-20030226/ecma-script-binding.html

            Bernhard
            http://datenkueche.com
          • Jim Ley
            Bernhard Zwischenbrugger wrote in message news:bbfo8p+u7dj@eGroups.com... ... Nope, that s about saving/loading XML - it may have
            Message 5 of 25 , Jun 2, 2003
            • 0 Attachment
              "Bernhard Zwischenbrugger" <datenkueche2001@...> wrote in message
              news:bbfo8p+u7dj@......
              > Hi
              >
              > > postURL is nothing to do with DOM2 or DOM3 and I can't see any DOM ever
              > > supporting it (DOM relates to XML, postURL has nothing to do with XML)
              >
              > Maybe I'm wrong but DOM3 save/load looks like they try to do that kind
              > of things:

              Nope, that's about saving/loading XML - it may have a save/load over HTTP,
              but that's very different to getURL which is at a much lower level.

              Jim.
            • ronan@roasp.com
              Ahh, sorry . I meant an extension in the sense of adding functionality to that of DOM. Not *extending* DOM. Well, getURL s use from our point of view is to
              Message 6 of 25 , Jun 2, 2003
              • 0 Attachment
                Ahh, sorry . I meant an extension in the sense of adding functionality to that
                of DOM. Not *extending* DOM.

                Well, getURL's use from our point of view is to enable us to make DOM calls on
                imported data. In this manner, they are intert-wined imho.

                still mumbling.

                Quoting Jim Ley <jim@...>:

                >
                > <ronan@...> wrote in message
                > news:1054556072.3edb3fa8b1829@......
                >
                > > Nevertheless, maybe I want to use getURL to get a decision made for me and
                > wish
                > > to interpret this decision by running a regex on the result string. This
                > is
                > > equally feasible.
                >
                > Which is perfectly possible, you don't need anything that ECMAScript doesn't
                > give you.
                >
                > > > postURL is an extension of DOM2 and I think that's ok.
                > > > I hope DOM3 will have this without extending the DOM standard.
                >
                > postURL is nothing to do with DOM2 or DOM3 and I can't see any DOM ever
                > supporting it (DOM relates to XML, postURL has nothing to do with XML)
                >
                > Jim.
                >
                >
                >
                >
                >
                > -----
                > To unsubscribe send a message to: svg-developers-unsubscribe@yahoogroups.com
                > -or-
                > visit http://groups.yahoo.com/group/svg-developers and click "edit my
                > membership"
                > ----
                >
                > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                >
                >
                >
              • ronan@roasp.com
                ... With DOM, we have a framework to do a number of complex things using a common API so that us dumb developers do not need to re-learn the methods each time
                Message 7 of 25 , Jun 2, 2003
                • 0 Attachment
                  Quoting Jim Ley <jim@...>:

                  >
                  > <ronan@...> wrote in message
                  > news:1054555019.3edb3b8b30177@......
                  > > Right. Agreed about the kludge bit.
                  > >
                  > > I have to be honest, I do not see why scripting-specific helper functions
                  > such
                  > > as getURL/postURL are being put into the SVG spec.
                  >
                  > I don't see them in any way scripting specific, setTimeout as specified
                  > currently is much worse than those (seen as it requires a parser) but getURL
                  > is implementable in most languages.

                  With DOM, we have a framework to do a number of complex things using a common
                  API so that us dumb developers do not need to re-learn the methods each time we
                  change language.

                  With getURL, we are talking about a couple of helper functions to make our
                  lives easier. Every language has its own flavour of these methods, and in this
                  case they were provided by Adobe for us.

                  They're still helper methods. Granted, we may decide to make
                  YetAnotherSpecialApi that has a bunch of uri handling methods. But if this is
                  the case, then I suggest that a Whole Lot of Thought go into these. For
                  example, why http? Why not another transport method? Why getURL? Why not
                  CreateSocket or something nice and low-level? maybe StartSSH would be a nice
                  one.

                  My point is that this is falling well outside of the scope of SVG and into the
                  scope of infrastructure.

                  >
                  > > They're handy, but are they
                  > > not part of ECMAScripting land?
                  >
                  > ECMAScript have only ever done core language, there's no I/O of any sort (no
                  > HTTP, no disk IO, no User input/output methods of any kind)

                  True. Remember, there's a reason for that. But there are a myriad of clientside
                  languages that we may chose to use through the svg client, depending on our
                  tastes and needs. Some of those which do have interfacing support. And security
                  is a major problem with these.

                  >
                  > > I don't see the association with markup. And
                  > > let's not forget WHY they are so crippled. HELLO?? SECURITY??
                  >
                  > Not be able to set headers has nothing to do with security, Mozilla and IE
                  > already offer that functionality, and it's no more insecure than letting
                  > them do anything else.

                  Agreed. But the reason we are stuck here is because of ASV3's particular
                  implementation. Nothing prevents squiggle from giving us something more
                  profound if the desire is there. OR ASV4. But should it be in the SVG spec? I
                  agree that this gives a common goal post, and that this is a good thing. But
                  are we being short-sighted and are we setting ourseleves up for a nasty
                  surprise in a few years due to specifying too much? maybe not, but I am
                  concerned by this.

                  >
                  > > Dont get me
                  > > wrong, I'm addicted to get/postURL and parseXML. I can't go without them
                  > and
                  > > welcome extensions/improvements/acceptance of these methods. But within
                  > the SVG
                  > > spec?
                  >
                  > Neither do I, I don't think RAX should be in SVG's world either, in fact the
                  > SVG WG seem to take on much which wouldn't in an ideal world be part of
                  > their remit, however, because they need it to create what us developers
                  > want, they're forced into doing it or leaving needed functionality out.
                  > getURL isn't in ECMA TG39's remit (not that they seem to be doing much since
                  > they got CLI/C# to do aswell) there's no agency anywhere who's remit it is
                  > in, so the SVG WG would either have to try and get an appropriate group
                  > chartered within the W3 or just do it themselves. Do it themselves seems
                  > reasonable.

                  It does seem reasonable. This is why I am just mumbling to myself.

                  >
                  > Jim.
                  >

                  Ronan.
                • Robin Berjon
                  ... Every? Not EcmaScript! I wish EcmaScript had LWP, but that s just not the case. I feel we need to address that. ... No. SVG *is* the infrastructure.
                  Message 8 of 25 , Jun 2, 2003
                  • 0 Attachment
                    ronan@... wrote:
                    > With getURL, we are talking about a couple of helper functions to make our
                    > lives easier. Every language has its own flavour of these methods, and in this
                    > case they were provided by Adobe for us.

                    Every? Not EcmaScript! I wish EcmaScript had LWP, but that's just not the case.
                    I feel we need to address that.

                    > My point is that this is falling well outside of the scope of SVG and into the
                    > scope of infrastructure.

                    No. SVG *is* the infrastructure. Resistance is futile.

                    > Agreed. But the reason we are stuck here is because of ASV3's particular
                    > implementation. Nothing prevents squiggle from giving us something more
                    > profound if the desire is there. OR ASV4. But should it be in the SVG spec? I
                    > agree that this gives a common goal post, and that this is a good thing. But
                    > are we being short-sighted and are we setting ourseleves up for a nasty
                    > surprise in a few years due to specifying too much? maybe not, but I am
                    > concerned by this.

                    I understand (and share) your concerns. However for interoperability and inorder
                    to avoid the same balkanisation known to browsers, I much prefer to err on the
                    side of over-specifying than that of under-specifying. We can always relax later.

                    > It does seem reasonable. This is why I am just mumbling to myself.

                    :)

                    --
                    Robin Berjon <robin.berjon@...>
                    Research Engineer, Expway http://expway.fr/
                    7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
                  • Jim Ley
                    wrote in message news:1054566707.3edb69334fefc@roasp.com... ... this ... ECMAScript doesn t have these, and there s no way to write them,
                    Message 9 of 25 , Jun 2, 2003
                    • 0 Attachment
                      <ronan@...> wrote in message
                      news:1054566707.3edb69334fefc@......
                      > With getURL, we are talking about a couple of helper functions to make our
                      > lives easier. Every language has its own flavour of these methods, and in
                      this
                      > case they were provided by Adobe for us.

                      ECMAScript doesn't have these, and there's no way to write them, it's not
                      making out lives easier, it's providing something that is otherwise
                      impossible to do!

                      > For
                      > example, why http? Why not another transport method? Why getURL? Why not
                      > CreateSocket or something nice and low-level? maybe StartSSH would be a
                      nice
                      > one.

                      I hope it's not getURL/postURL in SVG 1.2, I really do, I think they're
                      badly specified, the closest existing thing for HTTP that would be
                      appropriate is the XMLHTTP object provided by MSXML and Mozilla, but HTTP
                      seems a perfectly reasonable protocol to choose, there are many proven
                      implementations that can be secured in existence and it's nothing that SVG
                      UA's don't already need to do.

                      > My point is that this is falling well outside of the scope of SVG and into
                      the
                      > scope of infrastructure.

                      SVG 1.0 already mandates infrastructure things, (like gzip encoding). I
                      agree it's not ideal.

                      > Agreed. But the reason we are stuck here is because of ASV3's particular
                      > implementation.

                      No it's not, the SVG WG do not have to rubber stamp getURL, going for
                      something more capable that can implement getURL will give us few headaches
                      and be a lot more useful, I think they'll need to provide some persuasive
                      reasons for not going down this route. I'd urge you to register your worries
                      on the www-svg mailing list, rather than just here.

                      Jim.
                    • David Nimmons
                      Mark, I have also been interested in developing applications using XUL and SVG. Just have not had the time to pursue. Based on my very limited knowledge of SVG
                      Message 10 of 25 , Jun 2, 2003
                      • 0 Attachment
                        Mark,

                        I have also been interested in developing applications using XUL and SVG.
                        Just have not had the time to pursue. Based on my very limited knowledge of
                        SVG and XUL, I think XBL, part of the XUL framework, offers what you need.
                        Mozilla includes soap functionality. Use SVG to develop the graphical
                        elements and use XBL to bind behaviors to the SVG element. To me, this
                        represents the way to use SVG to develop user interfaces. SVG is used to
                        implement the appearance of a widget and the behavior of the widget is
                        implemented through a User interface markup language ( such as XUL ).
                        I would be interested in following/helping in whatever you are doing.
                        Contact me off list if interested.




                        "mark_hutchinson_cph"
                        <mark_hutchinson_cph@ To: svg-developers@yahoogroups.com
                        yahoo.com> cc:
                        Subject: [svg-developers] SOAP
                        06/02/03 03:22 AM
                        Please respond to
                        svg-developers






                        I have recently implemented an user-interface using Mozilla and XUL
                        which sends/receives SOAP messages etc.

                        I have started to look at SVG for user-interfaces. Is it possible for
                        SVG to implement SOAP (so that clicking on a graphical element will
                        call a JavaScript function to generate and send a SOAP message)?





                        -----
                        To unsubscribe send a message to:
                        svg-developers-unsubscribe@yahoogroups.com
                        -or-
                        visit http://groups.yahoo.com/group/svg-developers and click "edit my
                        membership"
                        ----

                        Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                      • reto00dz
                        It sounds interesting is there something comparable in IE for SOAP is this XMLHTTP? What would be the benefit to use SOAP compared to XMLHTTP, less to code? I
                        Message 11 of 25 , Jun 2, 2003
                        • 0 Attachment
                          It sounds interesting is there something comparable in IE for SOAP is
                          this XMLHTTP? What would be the benefit to use SOAP compared to
                          XMLHTTP, less to code?

                          I found a nice little example for XMLHTTP but I think it only works
                          in IE.
                          http://www.codeproject.com/jscript/refreshpartweb.asp

                          Regards

                          Reto
                          --- In svg-developers@yahoogroups.com, "David Nimmons"
                          <David_Nimmons@H...> wrote:
                          >
                          > Mark,
                          >
                          > I have also been interested in developing applications using XUL
                          and SVG.
                          > Just have not had the time to pursue. Based on my very limited
                          knowledge of
                          > SVG and XUL, I think XBL, part of the XUL framework, offers what
                          you need.
                          > Mozilla includes soap functionality. Use SVG to develop the
                          graphical
                          > elements and use XBL to bind behaviors to the SVG element. To me,
                          this
                          > represents the way to use SVG to develop user interfaces. SVG is
                          used to
                          > implement the appearance of a widget and the behavior of the widget
                          is
                          > implemented through a User interface markup language ( such as
                          XUL ).
                          > I would be interested in following/helping in whatever you are
                          doing.
                          > Contact me off list if interested.
                          >
                          >
                          >
                          >


                          > "mark_hutchinson_cph"


                          > <mark_hutchinson_cph@ To: svg-
                          developers@yahoogroups.com

                          > yahoo.com>
                          cc:

                          > Subject: [svg-
                          developers]
                          SOAP

                          > 06/02/03 03:22
                          AM

                          > Please respond
                          to

                          > svg-
                          developers

                          >


                          >


                          >
                          >
                          >
                          >
                          > I have recently implemented an user-interface using Mozilla and XUL
                          > which sends/receives SOAP messages etc.
                          >
                          > I have started to look at SVG for user-interfaces. Is it possible
                          for
                          > SVG to implement SOAP (so that clicking on a graphical element will
                          > call a JavaScript function to generate and send a SOAP message)?
                          >
                          >
                          >
                          >
                          >
                          > -----
                          > To unsubscribe send a message to:
                          > svg-developers-unsubscribe@yahoogroups.com
                          > -or-
                          > visit http://groups.yahoo.com/group/svg-developers and click "edit
                          my
                          > membership"
                          > ----
                          >
                          > Your use of Yahoo! Groups is subject to
                          http://docs.yahoo.com/info/terms/
                        • Jim Ley
                          reto00dz wrote in message news:bbg7vg+25vk@eGroups.com... ... I have never understood any advantage in SOAP, there may be some, but
                          Message 12 of 25 , Jun 2, 2003
                          • 0 Attachment
                            "reto00dz" <rleutwyler@...> wrote in message
                            news:bbg7vg+25vk@......
                            > It sounds interesting is there something comparable in IE for SOAP is
                            > this XMLHTTP? What would be the benefit to use SOAP compared to
                            > XMLHTTP, less to code?

                            I have never understood any advantage in SOAP, there may be some, but it's
                            never been sold to me, _especially_ in the web-client.

                            > I found a nice little example for XMLHTTP but I think it only works
                            > in IE.
                            > http://www.codeproject.com/jscript/refreshpartweb.

                            http://jibbering.com/2002/4/httprequest.html

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