In previous versions of Fedora (including 3.0), 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.

One way to mitigate this design was to create the XSL datastream in one 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:

<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. 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.

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 is referenced in the DSINPUTSPEC datastream of demo:sdep. One thing to note: although the XSL datastream is a part of the content model object, its presence isn't actually described by the content model. In this case, however, I don't think it's appropriate to extend the dsCompositeModel schema such that the dsTypeModel element take a pid attribute. As it stands, the content model object would itself have to have another content model in order to accomplish this.

Other changes include removing the now-obsolete bDefPID attribute from both the Service Deployment (sDep) Method Map and DSInputSpec schemas. To take advantage of these schema updates, the FORMAT_URIs for DSINPUTSPEC and METHODMAP datastreams should be updated to info:fedora/fedora-system:FedoraDSInputSpec-1.1 and info:fedora/fedora-system:FedoraSDepMethodMap-1.1, respectively.

This work is currently available in the FC-254 development branch and is planned for inclusion in the upcoming Fedora 3.1 release.

3 Comments

  1. Daniel Davis

    While we are being very careful on extending the reference content model definition language, it is possible for the "hasModel" relationship to be pointed at any digital object. This means that content model objects can be self-referential and, thus, self-defining. In other words, content model objects can be their own content model. Actually, any object can potentially be both a data object and a content model object for a one-of-a-kind objects.

    What you are doing is consistent with this idea even though we do not have all the expressiveness in the reference content modeling language yet or any validation capability in place. But we can get there over time.

    1. Edwin Shin AUTHOR

      A self-referential content model would not have been adequate for this case. If demo:cmodel's DS-COMPOSITE-MODEL datastream included the XSL datastream, then demo:object.1 and demo:object.2 would both require an XSL datastream, which is exactly what we were trying to avoid in the first place.

  2. Thomas Ledoux

    Great job and neat implementation !!!

    I like the fact that, with your update, the cmodel is not only the 'struct' representation of a object; it can now support common behaviours more in a 'class' way.

     Hope we can experiment it in Fedora 3.1 ...