Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Pursuant to https://fedora-commons.org/jira/browse/FCREPO-400Image Removed

There are four places in a service deployment object that a dataStream ID/wsdl message part name are indicated:

...

  • DSInput binds a datastream ID to the to a partName, via @pid.  If @pid is absent, the partName , perhaps by the addition of a datastreamId attributewill be used as the datastream ID, and the current digital object will be the reference object.  If @pid begins with a slash, it is understood to indicate a datastream ID on the current object.  If @pid is only a Fedora pid, the object with the given pid will be the reference object, and the partName will be used as the datastream ID.  This could further be elaborated by allowing partName to be a messageName/partName structured value.
  • MethodMap indicates the source of a named parm with the input element, and the name of the bound message part in the @parmName.  If @required="false", the value of @defaultValue will stand in for a missing datastream value. If @required="true", a missing datastream will raise an errorMethodMap indicates that a named parm is taken from a datastream
  • WSDL Message Part name is used to establish the substitution pattern in http operations.  If the dissemination URL has a substitution pattern with no corresponding partName, an error is raised.

Thinking about this raises another potential issue under the 3.1 CMA: If an object can have multiple CModels, how should multiple matching SDeps be resolved when building a dissemination?This makes some sense to me, but leaves open the issue of when to assert a missing part error, and also where to indicate optionality of a part (and what to do if an optional part is missing).