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