This is covered in the CTP documentation, but I want to explore the issue a little here. The way the WS matches times with paths works like this. If a time has the name of a path in its datasource property, that time is applied to the path. If not, the first time in the array is used for a path.
So, if you are doing a trend with three tags, you send the WS three paths and one time range. Got a single value and a trend in your app? Give use all the paths, then give us the time range of the trend, followed by the single value time instant with the single value path as the value of its datasource property.
We never, ever, march through the context array trying to match paths and tags one-for-one in order. This might seem a little counter-intuitive, but it works pretty well and keeps the context array short -- an important consideration for data volume on the wire. Bear in mind there are a few other wrinkles. Ranges and instants are just the first context types, and we plan on "casting" contexts. There are also some provisions in the context realm for intermediate structures to provide for M:M associations between paths and contexts, but that seemed like overkill on the first release.
What do you say? Can you think of use cases that are hard to satisfy with the rules we have in the CTP?