Hi; You're absolutely right that we require some sort of discovery mechanism for determining which extensions are supported by a given service. I would argue that this is a general problem where we should be following the lead of the broader web services community. That said, I don't think that that community has settled on anything yet -- people please correct me if I'm wrong on this -- and that we may well need to define our own mechanism in the interim. We should make sure that we design things so that we can easily migrate to whatever the industry standardizes on whenever that becomes available. Regarding your suggestion for having a runtime meta-language for marking content as "ok to ignore" or must be understood", I have several questions/requests: * When you say "meta-language" are you implying something richer than these two choices? I can imagine at least two answers to this question: * "Simple" (and hence also efficient) resource matchmaking typically involves (mostly) exact matches. Adding a simple binary notion of an optional resource requirement adds a powerful descriptive capability without substantially complicating the matchmaking system. * You want a much more expressive resource description/matchmaking language that lets you specify all kinds of complicated concepts, such as prioritization of optional alternatives. * It would be great if you could provide a variety of example use cases. I personally agree with your view that having a small set of major dialects with minor aspect extensions seems like the most likely approach to be successful. Having a concrete set of examples will make the design conversations much more focused. * Without wanting to comment on the specifics of GGF documents, I think of the use of xsd:any as being as markers for extensibility in specific protocols. Profiles then define and constrain how those xsd:any fields may be turned into more concrete (extension) specifications. Marvin. -----Original Message----- From: Karl Czajkowski [mailto:karlcz@univa.com] Sent: Friday, April 28, 2006 11:09 PM To: Marvin Theimer Cc: ogsa-wg@ggf.org Subject: Re: [ogsa-wg] Thoughts on extensions mechanisms for the HPC profile work 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