Marvin and all: One additional comment I would add for consideration with extensible content (operations, resource models, etc.) is that there is a practical need for two complementary mechanisms that is often overlooked: 1. Runtime meta-language for marking criticality of extended content, e.g. marking an extension field as "OK to ignore" or "MUST be understood" so that a service in a heterogeneous environment can decide whether to proceed when it encounters some newfangled extension that is not implemeneted in the service. I would argue that there is no default policy that is appropriate for a majority of environments. Making the wrong choices on an extension-by-extension basis can cause faulty behavior and/or waste. I think there is a tendancy to use undisciplined "xsd:any" syntax in GGF documents lately, and I think it is a mistake. Please see the createAgreement operation extensibility of recent WS-Agreement drafts for my take on what is needed at minimum. We define an "OK to ignore" wrapper so that the service can disambiguate required versus optional extension fields in the input message. Unwrapped extensions are assumed to be mandatory/critical. 2. Discovery mechanisms for extensions supported by services. This obviously should complement what other discovery mechanisms are under discussion for job management. This is what will enable efficient brokering/routing of requests in a heterogeneous environment. The runtime disambiguation in (1) is more important if we have a general "aspect oriented" extension mechanism where, as you mentioned, there is a power-set of possible job descriptions. With a more limited profile/dialect approach, there would be a much smaller set of defined combinations. The art is probably finding the right hybrid of some "major" dialects with "minor" aspects so that major contradictory dialects cannot be mixed by accident, but simple minor extensions are not forced into this extend-by-replacement methodology. karl -- Karl Czajkowski karlcz@univa.com