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

SOAP

Expand Messages
  • mark_hutchinson_cph
    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.
    Message 1 of 25 , Jun 2, 2003
    View Source
    • 0 Attachment
      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)?
    • Jim Ley
      mark_hutchinson_cph wrote in message news:bbf1fq+on7f@eGroups.com... ... An interesting diversion... ... Not in any existing
      Message 2 of 25 , Jun 2, 2003
      View Source
      • 0 Attachment
        "mark_hutchinson_cph" <mark_hutchinson_cph@...> wrote in message
        news:bbf1fq+on7f@......
        > I have recently implemented an user-interface using Mozilla and XUL
        > which sends/receives SOAP messages etc.

        An interesting diversion...

        > 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)?

        Not in any existing implementations that I know of (well maybe the GET
        bindings).

        Jim.
      • ronan@roasp.com
        Caon t you just send the soap message using http? This is one of the SOAP transports, after all. Ronan.
        Message 3 of 25 , Jun 2, 2003
        View Source
        • 0 Attachment
          Caon't you just send the soap message using http? This is one of the SOAP
          transports, after all.

          Ronan.

          Quoting Jim Ley <jim@...>:

          >
          > "mark_hutchinson_cph" <mark_hutchinson_cph@...> wrote in message
          > news:bbf1fq+on7f@......
          > > I have recently implemented an user-interface using Mozilla and XUL
          > > which sends/receives SOAP messages etc.
          >
          > An interesting diversion...
          >
          > > 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)?
          >
          > Not in any existing implementations that I know of (well maybe the GET
          > bindings).
          >
          > 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/
          >
          >
          >
        • Jim Ley
          wrote in message news:1054546947.3edb1c031c8f6@roasp.com... ... Of course you can, but the HTTP support from javascript within SVG is woeful.
          Message 4 of 25 , Jun 2, 2003
          View Source
          • 0 Attachment
            <ronan@...> wrote in message
            news:1054546947.3edb1c031c8f6@......
            > Caon't you just send the soap message using http? This is one of the SOAP
            > transports, after all.

            Of course you can, but the HTTP support from javascript within SVG is
            woeful. You can't set the SOAPAction Header for example,
            http://www.w3.org/2001/tag/doc/ws-uri.html and similar may be able to do
            it, but to me they so hobble SOAP so as to make little point in using it (if
            there is any point).

            Jim.
          • Bernhard Zwischenbrugger
            Hi ... SOAP ... You can try something like this. I don t know it is working or not, but this is the way I would try it. I give a 50% chance to that. This is
            Message 5 of 25 , Jun 2, 2003
            View Source
            • 0 Attachment
              Hi

              > Caon't you just send the soap message using http? This is one of the
              SOAP
              > transports, after all.

              You can try something like this. I don't know it is working or not,
              but this is the way I would try it. I give a 50% chance to that.
              This is not copy/paste code, it is just an idea.
              If it is working you still have to do something with the
              result and that can be hard with javascript.

              Can you give feedback?


              -----------------------
              function postSOAP()
              {
              var SOAP=
              <![CDATA[
              <env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
              <env:Header xmlns:env="http://www.w3.org/2001/12/soap-envelope" >
              <t:Transaction xmlns:t="http://example.org/2001/06/tx" >
              5
              </t:Transaction>
              </env:Header>
              <env:Body>
              <r:GetLastTradePrice
              env:encodingStyle="http://www.w3.org/2001/12/soap-encoding"
              xmlns:r="http://example.org/2001/06/quotes">
              <r:Symbol>DEF</r:Symbol>
              </r:GetLastTradePrice>
              </env:Body>
              </env:Envelope>
              ]]>
              postURL("http://somewhere/soap.jsp",SOAP,soapreceiver,"text/xml","");

              }

              function soapreceiver()
              {
              alert(result.content);
              }

              Bernhard
              http://datenkueche.com
            • Jim Ley
              Bernhard Zwischenbrugger wrote in message news:bbf88k+neug@eGroups.com... ... javascript can talk soap easily enough, the OP was
              Message 6 of 25 , Jun 2, 2003
              View Source
              • 0 Attachment
                "Bernhard Zwischenbrugger" <datenkueche2001@...> wrote in message
                news:bbf88k+neug@......
                > Hi
                >
                > > Caon't you just send the soap message using http? This is one of the
                > SOAP
                > > transports, after all.
                >
                > You can try something like this. I don't know it is working or not,
                > but this is the way I would try it. I give a 50% chance to that.
                > This is not copy/paste code, it is just an idea.
                > If it is working you still have to do something with the
                > result and that can be hard with javascript.

                javascript can talk soap easily enough, the OP was already doing it in
                javascript! My problem with your code is that you don't have a SOAPAction
                header see http://www.w3.org/TR/SOAP/
                "An HTTP client MUST use this header field when issuing a SOAP HTTP
                Request."

                There are other bindings now which transport SOAP over HTTP without that
                requirement, I don't believe any have standard status yet, but I could be
                wrong.

                ASV as no ability to set arbitrary headers, I would hope that SVG 1.2 has
                the ability if it decides to include HTTP functionality within the
                javascript environment.

                Jim.
              • ronan@roasp.com
                Hi Jim, First of all - let me be clear that I have only minimal SOAP exposure. I ve experimented with it but that s it. No indepth knowledge. It strikes me
                Message 7 of 25 , Jun 2, 2003
                View Source
                • 0 Attachment
                  Hi Jim,

                  First of all - let me be clear that I have only minimal SOAP exposure. I've
                  experimented with it but that's it. No indepth knowledge.

                  It strikes me that the SOAPAction header can easily enough be faked using a
                  post/get with a simple transmogrifyer on the other side to catch the kludge.

                  Not strictly soap-compliant, but so what? Until we can get 100% support for
                  arbitrary header generation we can crawl along if we choose to use SOAP (Like
                  you said I'm not sure either why one would use soap. It's rather redundant.
                  (1
                  Question, though. Why do you think this is an SVG (1.2) language issue, rather
                  than a scripting/viewer (read implementatio) issue?

                  Ronan


                  Quoting Jim Ley <jim@...>:

                  >
                  > "Bernhard Zwischenbrugger" <datenkueche2001@...> wrote in message
                  > news:bbf88k+neug@......
                  > > Hi
                  > >
                  > > > Caon't you just send the soap message using http? This is one of the
                  > > SOAP
                  > > > transports, after all.
                  > >
                  > > You can try something like this. I don't know it is working or not,
                  > > but this is the way I would try it. I give a 50% chance to that.
                  > > This is not copy/paste code, it is just an idea.
                  > > If it is working you still have to do something with the
                  > > result and that can be hard with javascript.
                  >
                  > javascript can talk soap easily enough, the OP was already doing it in
                  > javascript! My problem with your code is that you don't have a SOAPAction
                  > header see http://www.w3.org/TR/SOAP/
                  > "An HTTP client MUST use this header field when issuing a SOAP HTTP
                  > Request."
                  >
                  > There are other bindings now which transport SOAP over HTTP without that
                  > requirement, I don't believe any have standard status yet, but I could be
                  > wrong.
                  >
                  > ASV as no ability to set arbitrary headers, I would hope that SVG 1.2 has
                  > the ability if it decides to include HTTP functionality within the
                  > javascript environment.
                  >
                  > 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/
                  >
                  >
                  >
                • Jim Ley
                  wrote in message news:1054553582.3edb35ee858a8@roasp.com... ... a ... kludge. Of course it can, but then you can do any such kludge to talk
                  Message 8 of 25 , Jun 2, 2003
                  View Source
                  • 0 Attachment
                    <ronan@...> wrote in message
                    news:1054553582.3edb35ee858a8@......
                    > It strikes me that the SOAPAction header can easily enough be faked using
                    a
                    > post/get with a simple transmogrifyer on the other side to catch the
                    kludge.

                    Of course it can, but then you can do any such kludge to talk anything
                    anywhere, so you're not talking SOAP in SVG, your server is talking SOAP, I
                    generally see SOAP as a way of getting rid of the server dependancies so you
                    can drop in any backend you want anywhere.

                    > (Like you said I'm not sure either why one would use soap. )

                    We certainly agree on that.

                    > Question, though. Why do you think this is an SVG (1.2) language issue,
                    rather
                    > than a scripting/viewer (read implementatio) issue?

                    because SVG 1.2 WG are adding getURL/postURL and if they leave them in their
                    current crippled state we have now, it will be a real shame, and will make
                    it even harder to make good SVG applications. The viewer authors would then
                    want to add such an extension because us developers need it, and we'd start
                    chasing non-standard extensions about all over the place.

                    Jim.
                  • ronan@roasp.com
                    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
                    Message 9 of 25 , Jun 2, 2003
                    View Source
                    • 0 Attachment
                      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. They're handy, but are they
                      not part of ECMAScripting land? I don't see the association with markup. And
                      let's not forget WHY they are so crippled. HELLO?? SECURITY?? 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? I don't agree it's the right place.

                      What about my other favorite JS method? Can we put those in too?

                      Maybe improve on JS's klunky regex support and something for handling
                      RonanSuperMarkupLanguage? (it's very secret, but I'd like that in the spec too).

                      ;-)

                      Don't worry. I'm just muttering to myself.

                      -Ronan

                      Quoting Jim Ley <jim@...>:

                      >
                      > <ronan@...> wrote in message
                      > news:1054553582.3edb35ee858a8@......
                      > > It strikes me that the SOAPAction header can easily enough be faked using
                      > a
                      > > post/get with a simple transmogrifyer on the other side to catch the
                      > kludge.
                      >
                      > Of course it can, but then you can do any such kludge to talk anything
                      > anywhere, so you're not talking SOAP in SVG, your server is talking SOAP, I
                      > generally see SOAP as a way of getting rid of the server dependancies so you
                      > can drop in any backend you want anywhere.
                      >
                      > > (Like you said I'm not sure either why one would use soap. )
                      >
                      > We certainly agree on that.
                      >
                      > > Question, though. Why do you think this is an SVG (1.2) language issue,
                      > rather
                      > > than a scripting/viewer (read implementatio) issue?
                      >
                      > because SVG 1.2 WG are adding getURL/postURL and if they leave them in their
                      > current crippled state we have now, it will be a real shame, and will make
                      > it even harder to make good SVG applications. The viewer authors would then
                      > want to add such an extension because us developers need it, and we'd start
                      > chasing non-standard extensions about all over the place.
                      >
                      > 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/
                      >
                      >
                      >
                    • Bernhard Zwischenbrugger
                      Hi ... functions such ... but are they ... It is in between ECMAScript an SVG. getElementById, parentNode, appendChild,.... this is DOM2 and not ECMAScript.
                      Message 10 of 25 , Jun 2, 2003
                      View Source
                      • 0 Attachment
                        Hi

                        > 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. They're handy,
                        but are they
                        > not part of ECMAScripting land?

                        It is in between ECMAScript an SVG.
                        getElementById, parentNode, appendChild,....
                        this is DOM2 and not ECMAScript.

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

                        Bernhard
                        http://datenkueche.com
                      • Robin Berjon
                        ... SVG isn t about markup, XML is. If you follow that route then none of the SVG DOM -- large parts of it are not concerned with markup -- are out. I believe
                        Message 11 of 25 , Jun 2, 2003
                        View Source
                        • 0 Attachment
                          ronan@... wrote:
                          > 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. They're handy, but are they
                          > not part of ECMAScripting land? I don't see the association with markup.

                          SVG isn't about markup, XML is. If you follow that route then none of the SVG
                          DOM -- large parts of it are not concerned with markup -- are out.

                          I believe that defining what an SVG User Agent has to be is very important,
                          notably for interoperability. If SVG is to be an application building
                          environment, such functionality is needed. And relying on ECMA for that is
                          hazardous at best imho.

                          > And
                          > let's not forget WHY they are so crippled. HELLO?? SECURITY??

                          Things such as access to headers, to other methods, or even to other protocols
                          aren't more security problems than what currently exists. You could require
                          signed scripts or the such to open up some of the functionality for instance.

                          Security is of course a concern, but it is orthogonal to the discussion of
                          whether such functionality is useful.

                          > What about my other favorite JS method? Can we put those in too?

                          Does it do something that can't be done using raw EcmaScript?

                          > Maybe improve on JS's klunky regex support and something for handling
                          > RonanSuperMarkupLanguage? (it's very secret, but I'd like that in the spec too).

                          There's nothing (apart from sanity obviously) keeping you from implementing your
                          own regex engine in EcmaScript. Just grab regex.c from the latest Perl
                          distribution and it's a straight port from there (provided you survive the
                          process :). It may be mad, but you can surely do it.

                          Now try to implement BSD Sockets in EcmaScript. You'll be missing some bits.
                          Those bits it may thus be worth adding (needless to say I strongly believe they
                          are).

                          --
                          Robin Berjon <robin.berjon@...>
                          Research Engineer, Expway http://expway.fr/
                          7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
                        • ronan@roasp.com
                          But isn t this simply a symptom of bloat and scope creep? The DOM recommendation is supposed to be concerned with the DOM. IE internal to the current document
                          Message 12 of 25 , Jun 2, 2003
                          View Source
                          • 0 Attachment
                            But isn't this simply a symptom of bloat and scope creep?

                            The DOM recommendation is supposed to be concerned with the DOM. IE internal to
                            the current document tree. getURL is concerned with retrieving a text snippet
                            from an external uri. Very unrelated, although certainly interacting together.

                            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.

                            There's nothing *wrong* with making use of the URI methods, and these methods
                            are useful enough for us to want to make sure they are optimally supported.

                            But *within* the SVG spec? I don't see the point. SVG is complicated enough as
                            it is. There will always be temptation to creep the scope towards a happier
                            world.

                            But like I said, I'm just muttering to myself.


                            Quoting Bernhard Zwischenbrugger <datenkueche2001@...>:

                            > Hi
                            >
                            > > 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. They're handy,
                            > but are they
                            > > not part of ECMAScripting land?
                            >
                            > It is in between ECMAScript an SVG.
                            > getElementById, parentNode, appendChild,....
                            > this is DOM2 and not ECMAScript.
                            >
                            > postURL is an extension of DOM2 and I think that's ok.
                            > I hope DOM3 will have this without extending the DOM standard.
                            >
                            > Bernhard
                            > http://datenkueche.com
                            >
                            >
                            >
                            > -----
                            > 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
                            Hi Robin, 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
                            Message 13 of 25 , Jun 2, 2003
                            View Source
                            • 0 Attachment
                              Hi Robin,

                              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? getURL
                              is ECMAscript-spcecific. 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.

                              SVG is a recommendation for a common vocabulary for a dialect of XML, and for
                              the interpretation of that dialect my UAs. 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 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.

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

                              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.

                              Ronan

                              Quoting Robin Berjon <robin.berjon@...>:

                              > ronan@... wrote:
                              > > 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. They're handy, but are
                              > they
                              > > not part of ECMAScripting land? I don't see the association with markup.
                              >
                              > SVG isn't about markup, XML is. If you follow that route then none of the SVG
                              >
                              > DOM -- large parts of it are not concerned with markup -- are out.
                              >
                              > I believe that defining what an SVG User Agent has to be is very important,
                              > notably for interoperability. If SVG is to be an application building
                              > environment, such functionality is needed. And relying on ECMA for that is
                              > hazardous at best imho.
                              >
                              > > And
                              > > let's not forget WHY they are so crippled. HELLO?? SECURITY??
                              >
                              > Things such as access to headers, to other methods, or even to other
                              > protocols
                              > aren't more security problems than what currently exists. You could require
                              > signed scripts or the such to open up some of the functionality for
                              > instance.
                              >
                              > Security is of course a concern, but it is orthogonal to the discussion of
                              > whether such functionality is useful.
                              >
                              > > What about my other favorite JS method? Can we put those in too?
                              >
                              > Does it do something that can't be done using raw EcmaScript?
                              >
                              > > Maybe improve on JS's klunky regex support and something for handling
                              > > RonanSuperMarkupLanguage? (it's very secret, but I'd like that in the spec
                              > too).
                              >
                              > There's nothing (apart from sanity obviously) keeping you from implementing
                              > your
                              > own regex engine in EcmaScript. Just grab regex.c from the latest Perl
                              > distribution and it's a straight port from there (provided you survive the
                              > process :). It may be mad, but you can surely do it.
                              >
                              > Now try to implement BSD Sockets in EcmaScript. You'll be missing some bits.
                              >
                              > Those bits it may thus be worth adding (needless to say I strongly believe
                              > they
                              > are).
                              >
                              > --
                              > Robin Berjon <robin.berjon@...>
                              > Research Engineer, Expway http://expway.fr/
                              > 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
                              >
                              >
                              >
                              > -----
                              > 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/
                              >
                              >
                              >
                            • 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 14 of 25 , Jun 2, 2003
                              View Source
                              • 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 15 of 25 , Jun 2, 2003
                                View Source
                                • 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 16 of 25 , Jun 2, 2003
                                  View Source
                                  • 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 17 of 25 , Jun 2, 2003
                                    View Source
                                    • 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 18 of 25 , Jun 2, 2003
                                      View Source
                                      • 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 19 of 25 , Jun 2, 2003
                                        View Source
                                        • 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 20 of 25 , Jun 2, 2003
                                          View Source
                                          • 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 21 of 25 , Jun 2, 2003
                                            View Source
                                            • 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 22 of 25 , Jun 2, 2003
                                              View Source
                                              • 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 23 of 25 , Jun 2, 2003
                                                View Source
                                                • 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 24 of 25 , Jun 2, 2003
                                                  View Source
                                                  • 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 25 of 25 , Jun 2, 2003
                                                    View Source
                                                    • 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.