...
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:
| 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"/> {code} |
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
...
...
...
...
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
...
...
development
...
branch
...
and
...
is
...
planned
...
for
...
inclusion
...
in
...
the
...
upcoming
...
Fedora
...
3.1
...
release.