...
In order to workaround the requirement for every object to have its own XSL datastream (inline or redirect), the WSDL binding in the service deployment could hardcode a reference to demo:foo's XSL datastream:
| Code Block |
|---|
<wsdl:binding name="DC2MODS_http" type="tns:DC2MODSPortType"> <http:binding verb="GET"/> <wsdl:operation name="transform"> <http:operation location="SaxonServlet?source=(DC)&style=http://localhost:8080/fedora/get/demo:dc2mods.cmodel/XSL"/> |
Although this does the trick, it's a bit of a hack, and it's desirable to be able to describe the datastream binding in a more formal fashion. (detail/example of wsdl binding hack)It's also fragile, because of the hardcoding of the host and port and it also doesn't support authentication (e.g. if authentication is required for API-A).
I came across this issue in the development of the unAPI HTTP service for Fedora. Rather than hardcode a datastream location in the WSDL binding, I extended the DSInputSpec schema to include an optional pid attribute. Absent the pid attribute, the datastream input is still assumed to belong to the data object. However, if the pid is specified, the binding occurs against that pid's datastream.
...