Re: [Standards] XEP-0244: the xs namespace prefix
Hi Pedro, On Thu, Sep 10, 2009 at 11:00 PM, Pedro Melo wrote: > Example 5 of XEP-0244 introduces a xs: namespace prefix without a proper > declaration. Are the authors assuming that the declaration is going to be in > the top level header? What happens when this stanza crosses to an > outgoing S2S link without that declaration at the stream level? the stanza > would be invalid XML. The xs prefix should indeed have be defined in the example. Egon -- Post-doc @ Uppsala University Blog: http://chem-bla-ics.blogspot.com/ PubList: http://www.citeulike.org/user/egonw/tag/papers
Re: [Standards] LAST CALL: XEP-0244 (IO Data)
Dear Wasaq, On Sun, Sep 6, 2009 at 8:28 PM, Waqas Hussain wrote: > Some problems with the XEP: > > 1. The XEP basically allows a service to expose a set of global functions. > There is no possibility for function namespaces. This is similar to the SOAP > over XMPP XEP, where you can have only one service end point per-JID (which > I consider a non-minor deficiency). Can you elaborate on this? If you run a service discovery on ws1.bmc.uu.se you will see various JIDs, each with one and often more functions... > 2. The schemata discovery protocol requires at least two IQ requests per > exposed function. For a service exposing a large number of functions, this > makes it impractical to use for generating marshalling code at runtime. I do not understand how you see the number of needed IQ requests to make generation of marshalling code at runtime difficult. Could you please explain? > And > there’s no allowance for caching the schemas (i.e., you have to load all of > them every time, since there is no assurance that it didn’t change since you > last checked). For something like Prosody, where we might be exposing > hundreds of functions, which can appear and disappear when modules > (including third-party modules) are loaded/unloaded, this makes for some > nastiness. As far as I know there is no standard for versioning on XML schemata, other than with the schema itself. Indeed, the current proposal does not propose a mechanism for doing this, and defines the schemata itself is 'contract' for the service interaction. I do understand that if you wish the change that contract regularly *and *you wish the services to keep the same JID, that this places stress on the clients. However, I am not sure that the XEP should provide best practices for dealing with service providers with such wishes. If we could get to, or reuse, a different XEP for specifying detailed versioning information for schemata, this would have been useful indeed. But in the lack thereof, I think that using the XML Schemata itself as exact versioning is a wise choice, even though it for larger schemata this puts some stress on the bandwidth. That said, using the current XEP, you could simply consider using 's which gives you exact control over the schemata versions your services are using. I think this provides the clients exact caching control on included schemata. Looking forward to hearing from you about the things that were not clear to me in your comments, Egon -- Post-doc @ Uppsala University Blog: http://chem-bla-ics.blogspot.com/
Re: [Standards] LAST CALL: XEP-0244 (IO Data)
Hi all, not sure I am supposed to reply to this as author of the XEP, but here goes... I hope it will trigger more replies to the call. On Wed, Aug 12, 2009 at 11:33 PM, XMPP Extensions Editor wrote: > 1. Is this specification needed to fill gaps in the XMPP protocol stack or to > clarify an existing protocol? To me it is. It defines clearly the content of an with respect to the data type and allowed content. The specification describes how clients can query the allowed content with the service in a simple and well defined manner. I like this simplicity, making it easier to write 100% implementing libraries. > 2. Does the specification solve the problem stated in the introduction and > requirements? The XEP introduces an alternative data container with strong data typing (going beyond xs:string), which we are happily using in machine-to-machine settings, in our XMPP web services environment. Using XML Schema the data type is well defined, such that clients can even on the fly build Java models of that schema and use that to create a IO-Data message. > 3. Do you plan to implement this specification in your code? If not, why not? We are using Johannes Wagener's http://xws4j.sourceforge.net/ And I know if this client implementation by Tuomas: http://www.lobstermonster.org/examples/ws1.bmc.uu.se/ > 4. Do you have any security concerns related to this specification? Data input is generally a source of failures of services, and IO-Data does not change that. However, the strong data typing makes it much easier to validate the input, though it depends on how strong the schema implements data types. This XEP does not introduce new security issues. > 5. Is the specification accurate and clearly written? I understand it :) So, I leave this to others to comment on. Egon -- Post-doc @ Uppsala University http://chem-bla-ics.blogspot.com/
Re: [Standards] XMPP example site - www.LiveBaseballChat.com
On Tue, Apr 7, 2009 at 11:00 PM, Dean Collins wrote: > Basically it is an ajax/xmpp site with 2430 chat rooms set up over the > next 6 months for people to talk about specific Baseball games. Interesting... I have been thinking about making a web front end for IO-DATA services, assuming there must be web/JavaScript libraries to talk over the XMPP network... Can you please elaborate on the libraries used behind your website? Egon -- Post-doc @ Uppsala University http://chem-bla-ics.blogspot.com/
[Standards] xmlns="" in IQ stanza
Hi all, In this email I would like to ask clarifiation of section 11.2.2 of RFC 3920 (XMPP), regarding the use of default namespaces in IQ stanza. In the IO-DATA proposal, XML Schema is passed in the IQ stanza. These XML Schema documents may use the default namespace when defining XML schema types and elements. For example, this is what the Chemical Markup Language does in [0] at line 1 (for readability layed out on multiple lines here): http://www.xml-cml.org/schema"; xmlns:h="http://www.w3.org/1999/xhtml"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns="http://www.xml-cml.org/schema";> Which defines the default namespace, and following XML Schema design puts the defined simpleType 'actionOrderType' using the targetNamespace attributs in the CML namespace... later in the schema, again according to XML Schema customs, the actionOrderType is used again, without prefix, and therefore taking from the default namespace defined in the above snippet (see lin 3070 in [0]: Now, one of the XMPP tools we use (I do not know yet which one, so won't name the tools just yet, to not encourage false accusations) removes the xmlns="" attribute from the above snippet. This effectively means that the second part (line 3070) of the CML XML Schema becomes invalid, refering to an actionOrderType now in the XMPP default namespace... Before I want to further explore which of the tools we use is removing this crucial bit of XML, and to decide this is a minor bug or a rather critical one, I would like to inquire if the XMPP protocol allows the above set up. Section 11.2.2 of RFC 3920 states [1]: "A default namespace declaration is REQUIRED and is used in all XML streams in order to define the allowable first-level children of the root stream element. This namespace declaration MUST be the same for the initial stream and the response stream so that both streams are qualified consistently. The default namespace declaration applies to the stream and all stanzas sent within a stream (unless explicitly qualified by another namespace, or by the prefix of the streams namespace or the dialback namespace)." This section defines the default namespace that applies by default to all elements, unless elements are explicitly qualified otherwise. From this section I do not read that the default namespace cannot be overwritten by IQ stanza content; indeed, the above description seems to follow the XML Namespace specification nicely. The first statement could be interpreted that the default namespace can solely be used to define the namespace of the first-level children, but that would contradict, I think, the last statement. So, my questions is, is the one of the libraries we use wrong, or, alternatively, can IQ stanza never overwrite the default namespace? Looking forward to your opinions on how to interpret this part of the XMPP specification, kind regards, Egon Willighagen 0.http://cdk.svn.sourceforge.net/viewvc/cdk/cdk-xws/trunk/xws-qsar-services/src/org/openscience/cdk/xws/schema/cml.xml?revision=14106&view=markup 1.http://www.ietf.org/rfc/rfc3920.txt -- Post-doc @ Uppsala University http://chem-bla-ics.blogspot.com/
Re: [Standards] Proposed XMPP Extension: IO DATA
On Sun, Mar 30, 2008 at 7:09 PM, Fabio Forno <[EMAIL PROTECTED]> wrote: > While it's true that in SOAP+XMPP specs there is no asynchronous > message exchange pattern (and that was a mistake, though I think it's > possible to add a new MEP), this is not related to REST. Neither the > concept of session id is somewhat related to REST, at the contrary, > REST explicitly forbids things like session ids. Fabio, thank you for catching this misqualification. We'll fix this shortly. BTW, let me say that asynchronous RPC support in XMPP is very interesting for scientific workflow environments. This proposal addresses two problems which are important limitations of current approaches like SOAP over HTTP. 1. many different data types. This is particularly a problem in (bio-)chemical sciences, where experimental data is found in many, many data types, which, moreover, are increasingly semantic. Currently, SOAP often cannot validate input unless the call has been made, while this proposal promises to allow to do this at the gate. Big improvement. 2. asynchronise calls. This is also a big limitation of our current tools. Call-by-reference does solve the problem of HTTP time outs on intermediate IP packet routers, but the only way to do long running jobs is to have the client use a second 'service' to poll the primary service and ask if it is done yet. XMPP is provides a much nicer protocol for such situations, and this proposal formalizes this. These two items combined, make this proposal an excellent candidate for running webservices in sciences like chemistry and biology. I am not too much into XMPP myself, but hope the discussions on this mailing list will help us get the proposal in shape, because we really like to see this functionality. The example code from Johannes looks great, and eager to start using it. We are setting up webservices for metabolomics, where the data that needs to be passed around goes in the gigabytes, and where processing easily goes into the tens of minutes. I am aware that we continue the unofficial extension of Edrin, but having this as an official XEP will make it much easier to roll out XMPP-based webservices on a larger scale. Looking forward to hearing further comments! Egon -- Post-doc in Metabolomics Wageningen Universtity & Research Center, The Netherlands http://chem-bla-ics.blogspot.com/
