views:

75

answers:

2

I'm trying to figure out two things:

  1. Can Xpath be used to query a SOAP-based web services server?

  2. Is this built into the SOAP protocol such that any good SOAP server would handle the requests correctly without having to add custom handling of XPath queries?

The two questions may seem redundant, but I'm breaking them because:

  1. I don't know if what I have in mind makes sense/would be the right use of XPath,

  2. If it does make sense, is it already an understood feature of the SOAP protocol (and thus might explain why I can't find any specific documentation for the Web Service I'm actually dealing with.)

Here is the real-world scenario, if that helps:

I have a calendar database (very simple, MySQL), and I want to update my MS Exchange calendar via EWS. Whenever I push events out from my db to my calendar, two things are true:

  1. The date range will always be the same (the start of the week through the end of the week of when the push happens).

  2. The UID of each event will have an indicator that it was sent out by this specific app.

So, before any events are pushed to the calendar, I would like to delete any events that are within that date range and have the app-indicator in the UID, so that I don't get doubles of calendar items, or worse, old items on my calendar that no longer are right.

Since I'm having trouble finding the right way to do such a query/delete/add all in one request, I was thinking that XPath was the less-proprietary solution. But I'm not even sure where the XPath query would be amended to the request, or even if the best of xml parsers would derive the intended goal.

Sorry this was more long winded then I meant it to be. Short version: can I use XPath within a SOAP request? If so, how?

+1  A: 

1 - Can Xpath be used to query a SOAP-based web services server?

Umm. No. XPath is a highly dependent language, it can't do anything on its own. Like CSS, it needs an interpreter and a DOM around to work.

2 - Is this built into the SOAP protocol such that any good SOAP server would handle the requests correctly without having to add custom handling of XPath queries?

No. SOAP is a data exchange protocol built on top of HTTP. It is used to exchange objects (that have been serialized as XML) in a predictable and programmable manner. Even though XPath has a connection to XML, it has no intrinsic connection to SOAP.

I'm afraid I can't give a more specific answer than "probably not", since despite your explanation I have no idea what you are actually trying to do. To get a more specific answer, you would have to show your code (or the pseudo code that reflects your idea).

Tomalak
Yeah, this is why I asked. Because XPath is mentioned so casually in XML-related contexts, yet I see very little implementation of it (or at least very few real-world examples). The specific instance of casualness that brought about the question can be found at an msdn page on EWS: http://msdn.microsoft.com/en-us/library/aa563525%28v=EXCHG.80%29.aspxI'm guessing they just mean "once you've got the response back, here's the XPath node to use..." but I hope you'll agree it's pretty vague. Anyway, I'll save the pseudo-code for its own question. Thanks for the feedback.
Anthony
@Anthony: There are countless implementations of XPath all around you. Every XML DOM parser has one. Every major browser has one. XPath can *find certain nodes* in an XML tree, but that's about it. I have the vague feeling you are misinterpreting or overestimating the purpose or capabilities of XPath.
Tomalak
That's why I'm here, right? I think my confusion (if it's possible to be confused and know why) is between documentation targeted toward client/browser/UA development versus documentation targeted toward smaller projects (web apps/scripts/plugins/etc.). I keep approaching everything like I can just grab a small bit and ignore the surrounding mechanisms, probably because a)I learn as I go and b)my self-training has always been problem-based (meaning, I either see a problem and want to fix it, or have a problem and need to fix it), not as much dealing with ideas beyond the abstraction I see.
Anthony
But in terms of me misinterpreting vs overestimating, I'm going to go with overestimating on this one. The idea I had in mind for XPath with SOAP was I pass a SOAP object (call it "DeleteItems") that has an array of items to delete inside. If I set the array of items to be one generic "AllItems" (risky, I know), with an XPath query appended to it, then the SOAP server should interpret my request as "deleteitems -> xpath-result-nodes(allnodes)" and thus it's not so far fetched that Xpath could add tremendous value to a WebService by lowering the overhead on creating methods for such queries.
Anthony
But it may be an over-estimation that they could easily be integrated together or that the SOAP Server would simply "get it" which is why I was asking.
Anthony
@Anthony: If you have an array `AllItems` *and* the XPath to identify those items that should be deleted, then you have everything to create an array `DeleteItems`, right? So why handing the full list *plus a rule* to the server, when you can pass the relevant list right from the start? Seems like a big waste of resources and like putting the cart before the horse.
Tomalak
Because in this hypothetical `AllItems` is not an array I have, but instead a generic object requesting "all items" and the XPath query filters it down to the items in the larger set to the ones I want deleted. The exact issue I'm talking about is that I DON'T already have an array of items. If I did, I wouldn't be trying to figure out how to use XPath to request those items from the server. Isn't that the point of a standard query language? To query things from a server?
Anthony
@Anthony: I'm afraid I can't follow. Your client requests a list of objects by means of an XPath query? SOAP is XML only "by accident", it could have been a binary protocol as well. Would you still ask the same question, then? SOAP is a means of transportation, an abstraction layer that *normally* is completely hidden from you the same way the details of TCP are hidden from you. Only when you *emulate* SOAP via a SOAP-incapable client (XMLHttpRequest), or write an actual SOAP client, will you ever see it the XML details of it. So, where is this going?
Tomalak
@Tomalak - I see now where the confusion is. Your point makes total sense and definitely has helped me see why XPath wouldn't work by default. But I still think it could. This may take more than one comment for me to explain, just so you know. So you are looking at SOAP as an arbitrary abstraction layer for transporting objects and methods over the application-layer (which it is), while I'm thinking of it as an abstraction layer for the application itself (which it could be)...
Anthony
Basically, the reason why XPath wouldn't work in your scenario is because the data on the server itself would also have to be in XML and the XPath query would have to be extended beyond the request to that data. This wouldn't make sense if the server only used XML for SOAP and everything else was native and local and whatnot. The server would probably (hopefully) reject the entire request as the XPath would be meaningless. However, if the XML abstraction was extended such that the server had to work from the deepest node outward, XPath would fit in...
Anthony
So if the server started at the deepest child, in this case a node with the element `<allrecords />` and then move outward, it would then hit the Xpath and filter out the records to just those that (for example) start with `foo`. Now it moves out another generation and hits the node `<deleterecords>` and thus sends only the records starting with `foo` to the native code that performs the delete method. I concede that this may not be how the protocol was written or what it was intended for,...
Anthony
...but it makes more sense to me that if the overall goal is to unify/standardize/normalize different systems/languages/apps so that they can interact, then it would be smart to use XML-based tools like XPath,XQuery,XLink to reduce the need for the clients/servers from having to write their own query methods that would be both redundant and less stable. Mentioning the "by accident" part was really helpful for seeing your point, but I don't think that just because something is arbitrary, it can't be extended. The choice of XML could be a "happy accident" that allows for XPath.
Anthony
And yes, ideally the SOAP abstraction offers the benefit of writing native code without having to directly meddle with the underlying XML, but the Xpath could be just as easily abstracted if it were added to the protocol. Queries are not really 'native' to any non-database languages I know of, but an SQL-style "method" could be tagged on to any object such that the SOAP client knows how to amend the node with the XPath.
Anthony
Last comment from me for now: Thanks for sticking with this thread. I feel like this has been really beneficial for me and pretty fun too. I hope by now you don't still think I'm a moron who throws terms around, but if you do at least you know I'm a persistent moron.
Anthony
I am still not convinced, but you got me to think about it the right way.
Anthony
A: 

The SOAP service in question could implement a method that takes the XPath query as input (where the XPath query is just sent as a string parameter to the SOAP method). Then implement logic on the SOAP server that executes the XPath query and deletes the records. BUT this would only be using XPath as a format for the query, it has nothing to do with SOAP being xml! The format of the query parameter could also be SQL.

I have worked with a SOAP method that does a query based on a gml structure (map vector data in xml form). The method took a filter parameter as a string that contained valid gml, and returned the result as another string containing map data in valid gml.

awe