Many thanks for this Michel. There is a missing issue. Fairly high up on the list should be the issue about what to do with the User and Group ID info/elements? We've carried this issue over from the previous discussion and discussed it at length on the list. We just need to finalise our decision and move on. Summary of my observation is that: POSIX User and Group ID elements are required in the POSIX Application section/element only for now. We can extend this for further application types (e.g. Web Service invocation) by adding new, more specific, user ID elements. Other ideas are: 1. Different user types in a User element, which can be added to later: <User> <POSIXUser/> <POSIXGroup/> <WebServiceUser/> <OracleUser/> <XindeceUser/> </User> 2. General UID and GID with extensibility: <User> <UID/> <GID/> <xsd:any##other> </User> I'm in favour of 1. if we're to have a dedicated User element - i.e. not application specific like: <Application type="POSIX"> <UID/> <GID/> </Application> as suggested in the opening paragraph. Cheers and take care, Ali On Tue, 12 Apr 2005, Michel Drescher wrote:
Folks,
here's a list of issues. It's huge in numbers, but most of it is (IMHO) quite quickly fixable.
1) Fig. 1 revision
2) Fig. 2 revision
3) Prefixes and namespaces (check and update)
4) Namespace should be in the table (and update)
5) Section 3 (spec doc) general revision and polishing up
6) Update explanation for jsdl:other usage
7) Possibly reformat ch. 4.2.1
8) JSDL compliance levels How much of jsdl a system must support, not just process. Probably a topic for later.
9) The statement "If not supported then the consuming system MUST reject the document." needs a bit more explanation or re-write.
10) When/why did HostName change from 0-1 to 0-n? (reverted)
11) Filesystem name and type and filesystem reference in DataStaging
12) Mountpoint environment variable. Is the current approach ok, or should we provide a separate mechanism, e.g, a tag that if present provides the name of the environment variable in which the MountPoint value must be present.
13) Should FileSystemID be changed (back) to FileSystemName.
14) DRMAA use case for defining filenames. We have to at least be able to show an example of how to define and stage out an <Output> file.
15) CreationFlag. Was this made optional or not? Confirm and delete comment.
16) Process Topology needs review. In particular are the examples ok or not, are the definition correct and so on. Delete the yellow comments once that is done. Not sure if we should define the precise allocation behaviour or allow for that to be defined instead.
17) Section "Extending JSDL" needs an owner. I expect this section to be about 1 page long so should not be too much trouble.
18) Normative Extension is out of place
19) re-check terminology for process topology and delete comments
20) "Bytes (octets of bits)"
21) Memory limit incomplete text
22) pipe size limit incomplete text
23) Update of security considerations in line with latest decisions (when we actually reach firm decision)
24) Complete author information (see my entry as reference)
25) Update contributors and acknowledgements
26) Complete list of Normative references, e.g., CIM is still missing.
27) Glossary owner
28) Translation tables need to be added Proposal: Karl for Globus/GRAM, Chris for LSF, Saga-san for Naregi, ??? for Condor, ... 28a) Put the translation tables into a separate document?
29) Promised examples for the appendix (But maybe this should be split off into a Primer)
30) Make citations in text of document reference real cross-references.
31) Complete example sub-sections
---
For those that read until here: Is anything missing?
Cheers, Michel
-- ---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali@epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------