A proposal for the
VoSpace 1.0 schema.
A Java programmer writes XML schema I'm afraid, extension types for everything.
This seems to map quite nicely onto a Java class hierarchy.
However, if it causes problems for other language bindings then we can simplify where required.
Based on the methods in the v0.21
specification.
Comments/corrections welcome.
--
DaveMorris - 05 Jun 2006
A previous experiment, using several separate XSD files : prev
These files seem to be a rewrite rather than a refactor of the files that had been circulating amongst the intested members of the WG, and thus have lost some of the "accumulated knowledge" that was in those files - e.g..
- the original files were direct descendents of the VOStore files, and as such would make implementation from the existing VOStore implementations easier....
- the original files did have operations for all of the proposed VOSpace1.0 methods
- the split between the WSDL and the XSD files was originally intended to separate out non webservice specific types into the XSD, so that this file could be run through object generators to aid in generating object for parts of the implementation not directly connected with web services - e.g. metadata store without types such as DeleteNodeRequestType being generated that are specific to the web service.
- the original files followed IVOA namespace conventions more closely....
- the original WSDL was in wrapped literal style to provide maximum interoperability with .Net - not sure that the latest version follows that pattern.
- and possibly more - that is my point about gradual refactoring...
--
PaulHarrison - 06 Jun 2006
Yep, point taken.
Treate these as experiments only.
--
DaveMorris - 08 Jun 2006
Topic revision: r6 - 2006-06-09 - 10:56:54 -
DaveMorris