RE: [geclipse-dev] GRIA questions

["Ken Meacham" <kem@xxxxxxxxxxxxxxxxxxxxxxxxx>]

Hi Ariel,

> -----Original Message-----
> From: geclipse-dev-bounces@xxxxxxxxxxx 
> [mailto:geclipse-dev-bounces@xxxxxxxxxxx] On Behalf Of Ariel Garcia
> Sent: 28 April 2008 15:02
> To: Developer mailing list
> Subject: [geclipse-dev] GRIA questions
> 
> Hi Ken, Kasia, Mariusz, all,
> 

...

> Another question:
> i see some exceptions regarding jobs submitted with invalid 
> parameters, things like:
> 
> ** java.lang.IllegalArgumentException: Could not parse JSDL 
> against schema
> (...)
> Caused by: org.xml.sax.SAXParseException: 
> cvc-datatype-valid.1.2.1: 'file:/C:/Dokumente%20und%20Einstell
> ungen/Tao-j/Eigene%20Dateien/geclipse.jpg' is not a valid 
> value for 'NCName'.
> 
> The question is, doesn't the GRIA client libs check for those 
> things before submitting? I think it would make sense that 
> this error is catched by the client libs.

No, the GRIA client libs do NOT do any particular validation of the
submitted JSDL, other than ensuring that it is a valid XML document.

I would suggest (if you don't already) that g-Eclipse itself parses the
JSDL and checks this against the JSDL schema, whether or not the
underlying middleware performs this check or not. At least we can then
filter out any non-JSDL compliant XML at this stage. This parsing should
be done immediately after  creation by the JSDL editor, and probably
again just before submitting it via the middleware client code.

I agree that the standard JSDL editor should be generic and have no
middleware-specific features. This would enable it to be used as a
standalone JSDL editor, for someone who just wanted to use this feature
of g-Eclipse. (For example, you could use this to create a JSDL file,
which could then be submitted to some other unsupported Grid
middleware).

My feeling is that any middleware-specific checking of the JSDL should
still be done by the server. For example, different parts of the JSDL
are used by different parts of the GRIA Job Service. Each part validates
the JSDL it understands w.r.t. GRIA job execution, so doesn't really
make sense to put this validation into the client. As someone pointed
out, it is better to have this validation in a single place (i.e. the
server), to avoid any inconsistency in the way that it is handled.

However, it might still be useful to have some kind of middleware JSDL
creation "helpers", to avoid the creation/editing of any non-supported
JSDL elements. As we all know, JSDL is a very flexible standard, and it
may be interpreted in different ways (c.f. the bible?).

Personally, if I knew I was creating JSDL intended to be submitted to
GRIA, it would be nice if I could select a GRIA "flavour" option, which
would then somewhat restrict the editors capabilities. This might be a
plugin which could override the generic behaviour for the editor. For
example, in GRIA we don't use the "Executable" element within the "POSIX
Application". It would be great if that was simply disabled during GRIA
JSDL editing. All the generic JSDL editor code would have to do is call
an "isSupported()" method on each element, in order to decide whether to
enable/disable this in the editor. So for the GRIA plugin, the
isSupported() for an Executable element simply returns "false".

Similarly, when displaying an arbitrary JSDL file, if we selected the
"GRIA flavour" option, this could perhaps display any non-supported
defined element values in red.

Then, if we want a fully generic editor, we'd (by default) use the
"vanilla flavour" option.

JSDL does provide some user-defined extension points. We might be able
to exploit this by adding some metadata to a JSDL file when created by
g-Eclipse that specified the current flavour of JSDL. This would then
allow us to view the contents using the appropriate flavour plugin,
without having to select this manually.

If everyone agreed to developing this functionality, we'd need to define
an API that each middleware plugin overrides. For example, it could be
as simple as:

boolean isSupported(Element e);

The implementation could simply check all possible Element names and
return the appropriate value, and the default return value would be
"true".

Please feel free to discuss further!

Regards,

Ken.