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

Re: SOAP

Expand Messages
  • 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 1 of 25 , Jun 2, 2003
    • 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 2 of 25 , Jun 2, 2003
      • 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 3 of 25 , Jun 2, 2003
        • 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 4 of 25 , Jun 2, 2003
          • 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 5 of 25 , Jun 2, 2003
            • 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 6 of 25 , Jun 2, 2003
              • 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 7 of 25 , Jun 2, 2003
                • 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 8 of 25 , Jun 2, 2003
                  • 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 9 of 25 , Jun 2, 2003
                    • 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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.