Donal: The main concern, I think, is that JSDL is "so close" to having the right terminology for both levels. It would be a shame to lose focus and have to repeat the effort again later. I do not think the heterogeneous solution is a simple "bag of JSDL documents"... Consider this: within my heterogeneous activity set, I do not just want to compose two independent constraint systems. Rather, I want to express some global (or even coupled!) goals about resources allocated to more than one homogeneous array. As I tried to propose to JSDL-WG long ago, I think there is a simple hierarchical generalization of the jsdl:Resources model, wherein the "leaves" are homogeneous array constraint models, and the whole tree is an aggregate constraint model. What I mean by the above: -- A "global" goal is a generalization of the current JSDL "total" constraint, i.e. a sum over a larger set of resources. -- A "coupled" goal is a restriction of the current JSDL model, as Marvin suggested. For example: here is my general range of per-resource values, but I need symmetry. Or, this coupled application is malleable in time/space, but the two coupled codes need to be balanced according to some linear/quadratic/ whatever relation. We have examined this problem a bit for some other work, and we think a modest refactoring of JSDL would make it very valuable here. Namely, I think the "ontological" stuff regarding to sub-resources has been nicely organized. However, there is some redundancy in the "single/total" constraint model. I think a more general composition of the core concept, e.g. "memory", and a scoping construct, e.g. "per resource," "sum over resource array," or "sum over heterogeneous aggregate" would be better. I haven't thought about the coupled cases much, so I do not embarrass myself with short English phrases for them :-) We can reuse the core JSDL concepts for naming and applying units to sub-resources. The set of scoping constructs would probably be expanded over time. The hierarchy of the complex resource description would be used to group the resource constraints and provide hygienic scoping of these more elaborate goal constraints. The idea I am advocating is to have one general constraint model that is hopefully neutral, such that it can be mapped to the local constraint model of various schedulers or meta-schedulers. No single service would necessarily implement the fully general model, but would rather support profiled subsets of this model. The benefit is that the different profiles are all related by a common model, and it is feasible to consider more general solvers/profiles being introduced over time. karl -- Karl Czajkowski karlcz@univa.com