Page History

In previous versions of Fedora, datastream inputs to service methods were limited to datastreams that were members of a given data object. A typical scenario involved a dissemination that used XSL to transform one metadata format into another.

For example, in order to create a dissemination which used an XSL document to transform one metadata format into another, each object was required to have a member datastream that contained the XSL document, even though the same XSL document was used by each object.

{gliffy:name=metadata dissemination\|space=~eddie\|page=Dissemination Architecture Updates\|pageid=7733419\|align=left\|size=L}

One way to mitigate this design was to create the XSL datastream in a separate object (say, demo:foo) and have every other object reference demo:foo's XSL datastream. While this eliminated the need for multiple copies of the same XSL document, every data object still required an XSL datasteam of its own that redirected to demo:foo's XSL datastream.

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. Although this does the trick, it's a hack, and it would be desirable to be able to describe the datastream binding in a more formal fashion.

[detail/example here]

I came across this issue in the development of the [unAPI HTTP service|~eddie:/2008/09/23/unAPI and Zotero, meet Fedora and DSpace] 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 the specified pid's datastream.

{gliffy:name=metadata_dissemination_2\|space=~eddie\|page=Dissemination Architecture Updates\|pageid=7733419\|align=left\|size=L}

As shown in the diagram above, the data objects no longer include an XSL datastream. Instead, the XSL datastream is located in demo:cmodel and the DSINPUTSPEC datastream of demo:sdep references demo:cmodel.

sDep DSInputSpec
  <fbs:DSInput DSMax="1"DSMin="1"DSOrdinality="false"
               wsdlMsgPartName="XSL"pid="demo:cmodel">
    <fbs:DSInputLabel>XSL</fbs:DSInputLabel>
    <fbs:DSMIME>application/xml</fbs:DSMIME>
    <fbs:DSInputInstruction>DC to MODS XSLT</fbs:DSInputInstruction>
</fbs:DSInput>


sDep MethodMap
{code}
<fmm:MethodMap name="MethodMap - Document Transform SDEF Methods"
               xmlns:fmm="http://fedora.comm.nsdlib.org/service/methodmap">
  <fmm:Method operationName="transform"
              wsdlMsgName="transformRequest"
              wsdlMsgOutput="transformResponse">
    <fmm:DatastreamInputParm parmName="DC" passBy="URL_REF" required="true"/>
    <fmm:DatastreamInputParm parmName="XSL" passBy="URL_REF" required="true"/>
    <fmm:DefaultInputParm parmName="CLEAR_CACHE" passBy="VALUE" required="true"
                          defaultValue="yes" />
    <fmm:MethodReturnType wsdlMsgName="transformResponse"
                          wsdlMsgTOMIME="text/xml"/>
  </fmm:Method>
</fmm:MethodMap>
{code}
sDep DSInputSpec
{code}
<fbs:DSInputSpec xmlns:fbs="http://fedora.comm.nsdlib.org/service/bindspec"
                         label="Datastream Inputs">
  <fbs:DSInput DSMax="1" DSMin="1" DSOrdinality="false"
                       wsdlMsgPartName="DC">
    <fbs:DSInputLabel>Dublin Core</fbs:DSInputLabel>
    <fbs:DSMIME>text/xml</fbs:DSMIME>
    <fbs:DSInputInstruction>XML source to be transformed</fbs:DSInputInstruction>
  </fbs:DSInput>
  <fbs:DSInput DSMax="1" DSMin="1" DSOrdinality="false"
               wsdlMsgPartName="XSL" pid="demo:dc2mods.cmodel">
    <fbs:DSInputLabel>XSL</fbs:DSInputLabel>
    <fbs:DSMIME>application/xml</fbs:DSMIME>
    <fbs:DSInputInstruction>DC to MODS XSLT</fbs:DSInputInstruction>
  </fbs:DSInput>
</fbs:DSInputSpec>
{code}