Your SDep's DSInput can have a pid attribute to bind to a different object than the current context, which is how I skirted that issue (I have a single dummy object with a NULLBIND datastream, and have multiple deployments use it).
Have you tried repeating the datastream references? I'm pretty sure it works (the DC datastream is repeated in many content models, I'm sure), but I wonder what would happen if there were competing format uri's... On Fri, Sep 25, 2009 at 12:24 PM, Richard Green <[email protected]> wrote: > Chris and others, > > > > The Hydra team have decided that normal Hydra objects will all subscribe to > the same content model which defines metadata datastreams. This is actually > adequate for the parent of an aggregation object – it does not also need to > subscribe to another content model to define any content-bearing > datastreams. > > > > However, it would be useful to have aggregation parents subscribe to a > content model ‘genericAggregationParent’ simply so that they could be > identified (perhaps, say, to trigger a specific behaviour in the search and > discovery interface). Is there any harm in defining such a content model > and referencing a datastream already declared in the common metadata model? > Is it possible/better to declare a content model referencing *no* > datastreams (what do you do about the SDef reference)? Or? > > > > Advice would be welcome! > > > > Best > > > > Richard > > ___________________________________________________________________ > > > > Richard Green > > Consultant to the University of Hull IT Systems Group > > managing the CLIF and Hydra (Hull) Projects > > > > http://edocs.hull.ac.uk > > http://www.hull.ac.uk/clif > > https://fedora-commons.org/confluence/display/hydra > > > > ***************************************************************************************** > To view the terms under which this email is distributed, please go to > http://www.hull.ac.uk/legal/email_disclaimer.html > ***************************************************************************************** > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Fedora-commons-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers > > ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Fedora-commons-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
