Hi All -
This discussion seems to have died down for the moment; hopefully some others will post as well, particularly as the Europeans come back online tomorrow.
An important point here is that if we put an API in front of Spectrum, the details of the XML serialization are not all that important. The API library can support multiple serializations and resolve any differences between them, exposing an in-memory model to client applications which is *indendent of external representation*. If the API wants to present vectors to the client it can turn Point objects into vectors, or extract vectors from the columns of tables; if it wants to present a Point-model it can turn vectors or columns into Points, or whatever is required.
The specfic XML serialization only matters much when we deal with the XML representation directly. This happens if we use XML schema-based code generation tools to autogenerate a data binding, in which case if we have an array of Points in the schema, that is what the resultant API will present. Another case is when XML-specific tools are used to access the XML directly. In this case the vector approach may again be better, as a reference to a single node in the serialization could recover a data vector in one step, allowing it to be easily extracted and used in tools; otherwise such a data vector could be quite hard to extract. The tag-everything approach makes it easy to get at a single array element, but not the whole array, which is the wrong approach for something like a spectrum.
None of this has much to do with SOAP or the peculiarities of specific SOAP implementations, or where SOAP is appropriate to use or otherwise. That is an important issue too, which has not been adequately discussed, but is largely a separate issue.