The namespace constraint of the wildcard in the Extension element is
not(http://www.globus.org/namespaces/2004/10/gram/job/description) because of
the ##other namespace attribute on the wildcard in the schema. That means that
extensions there must have a namespace (See
http://www.w3.org/2001/05/xmlschema-rec-comments.html#pfiother). I think the C
code is correct to reject that document.

I verified that it works fine if the sub-elements of the extensions
element contain a namespace different from the target namespace
"http://www.globus.org/namespaces/2008/03/gram/job/description"

The following works fine

  <extensions xmlns:my="http://www.globus.org/whatever">
    <my:logfile>/tmp/logFeller</my:logfile>
  </extensions>

for submission of globusrun-ws, however, no logfile is written on the
server-side.

Reason seems that ExtensionsHandler.pm does not strip the namespace prefix
from the tag names, so they are named differently than expected
(my:logfile vs logfile) and thus not found.
If i strip the prefixes things seem to work fine, at least for the 
logfile element.

Possible solution: let a client define whatever namespace it wants and
strip the namespaces in ExtensionsHandler.pm. Is this a good solution?

How about this:

<job>
    <executable>/bin/true</executable>
    <extensions xmlns="http://www.globus.org/some/namespace">
      <logfile>/tmp/myPerlModuleLog</logfile>
    </extensions>
</job>

The default namespace would probably be the most convenient solution
for a client, because it must be specified only once and no ns-prefixes
for all sub-elements would have to be provided.

I'm getting the deserialization exception from globusrun-ws when i try
to submit that job.

To make that doc correct:

<job xmlns="http://www.globus.org/namespaces/2004/10/gram/job/description">
    <executable>/bin/true</executable>
    <extensions>
      <logfile 
xmlns="http://www.globus.org/some/namespace">/tmp/myPerlModuleLog</logfile>
    </extensions>
</job>

The extensions element is in the gram/job/description namespace

Joe

oh yeah, right.

Would it help to fix the bad namespace checking that's allowing you to get away
with gram elements without a namespace?

I set the namespace element to ##any for now. By this all ugly and dirty
things as we do now work fine, no changes at all required, neither on the
client-side (no explicit namespace settings) nor on the server-side (no
fixing in ExtensionsHandler.pm, no discussion about elements we want to
support or not).
A client can put whatever it wants into the extensions element and has
to adapt the perl modules to handle elements that we don't handle in the
custom perl modules.
As Joe said this is not a particular nice solution, but it looks like a
reasonable tradeoff to me with respect to convenience for users and the
effort it would take on the server-side to have a more elaborate solution.