Daniel has asked me to forward this to the list while he waits for Sergio to authorize his mailing list subscription request. ===== I had a meeting with JP this morning after the opening session to discuss ideas for Executable in ApplicationEnvironment. Here are some links to background information and some possible ideas. I would like to discuss this with other group members at one of the sessions this week. There are 2 sessions on Wed and 1 on Thu, however JP will not be available for the afternoon session on Wed (which is scheduled to be 'computing' I think). Alternatively we could meet Tuesday afternoon? *Background* Executable (LocalID, Name, Parallel)http://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/PhoneMeeting2... http://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/GridAustralia... More on ParallelType, NetworkInfohttp://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/PhoneMeeting2... *Current SPEC 24/2*https://forge.gridforum.org/sf/go/projects.glue-wg/docman.root.drafts No ParallelType or NetworkInfo yet. 5.0 Auxiliar Entities Spelling in title and GLUEntitiy in image need fixing! This could be used for executable. But since we agree that it is better to have a setup method (eg. module) then things like InstalledRoot should not be required either - and we don't want everything as an Auxiliary Entity! It appears to be 'less supported' and would not have a properly documented description. 6.7 p21 ApplicationEnvironment SetupMethod (module or softenv), SetupKey - only allows ONE! It would be better to be a Setup entity with method, key attributes. eg: <Setup method="module" key="blast"> Possibly rename Setup to Handle? This is what Teragrid have used in their non-GLUE schema. Or some other name? Allowing multiple entities, the method could then allow a value of "executable". This suggested alternative requires extra parsing and is more difficult to use XPath to extract modules for software: <Setup>module:blast</Setup> JP also suggested that things like parallel could be supported in a SoftwareAttributes (or similarly named) entity. But it is hard to decide what should be 'generic' and what should just be part of the SPEC to start with. Maybe best to keep as already discussed - but make sure it is put in the SPEC. Daniel.