[jsdl-wg] Naming elements

[Michel Drescher]

Folks,

from the last phone conference, I had the action assigned to follow the 
suggestion of naming elements.

Based on some thinking and toying around, I propose the following 
layout:

     JSDL allows to define a) applications that are supposed to be 
executed, b) sets of resources that are to be consumed, c) files to be 
staged in and out and, finally, d) establishes associations between 
applications, resources and data sets. An exhaustive 3-tuple of 
associations is called "JobDescription". A JobDescription can also 
contain a set of identifiable elements serving various kind of 
purposes, such as accounting, billing, etc. These elements are 
aggregated in an element called "JobIdentification". All this is 
aggregated in a root element called "JobDefinition" (a name I would 
like to question, but more on this at a later point).
     This short description from a bird's eye view may not be totally 
new, but it gives some valuable hints on what is worth being 
referencable and what not: a) resources, b) applications and c) data 
sets.
     A JobDescription does not necessarily has to be referencable, since 
it is usually a unique association between other elements that, in this 
configuration, serve a unique purpose. It is adequatically specified 
through the document's namespace.
     Similar jobs (who have a different namespace) may want to use 
exactly the same set of resources or the same application etc. Most 
likely, however, the resource sets or applications etc. that have been 
defined for another job will not fit exactly the new job's needs, so a 
mechanism to tweak existing definitions could be handy.

So, more technically and closer to the spec/schema, the following 
elements should be made referencable:
- /JobDefinition/JobDescription/Application
- /JobDefinition/JobDescription/Resource
- /JobDefinition/JobDescription/DataStaging
- Additionally, a similar mechanism exists for
   /JobDefinition/JobDescription/Resource/FileSystem and
   /JobDefinition/JobDescription/DataStaging/FileSystemID. I also
   propose to change FileSystemID to the type xsd:QName.

- Following the convention used with the construct "xsd:group", I
   propose to use an attribute "name" of type "xsd:NCName" to make
   an element referencable. An attribute named "ref" of type
   "xsd:QName" is proposed to be used as a reference to a
   referencable element.
- Sibling to JobDescription, applications, resource sets and data
   staging elements are allowed to be specified. They all get
   an attribute "name" of type "xsd:NCName" to be made referencable.
- JobDescription defines local elements(!) with the same name (for
   applications, resource sets and data staging) and each gets an
   optional attribute named "ref" of type "xsd:QName" to refer to
   already defined elements (either in the same document, or externally).
- These locally defined elements allow exactly the same appropriate
   groups of elements as the elements sibling to JobDescription.
- Elements specified in JobDescription's local elements override
   elements with the same name in referred elements.
- Finally, I propose to change the name of "JobDefinition" to something
   else, e.g. "JSDL" or something that does *not* have "Job" in its name
   since it does not define jobs alone anymore. (I just have no clue on
   a reasonable replacement.)

The following proposals are of more concern to schema hackers and are 
related to technical issues of design and "taste". They can easily be 
skipped by others although they may touch higher level concerns:

- I further propose to follow one of the two scenarios:
   a) define exactly one global element ("JobDefinition")
      so that any valid JSDL document always has "JobDefinition"
      as root element
   b) define a limited number of global elements, i.e.
      JobDefinition, JobDescription, Resource (rename to "ResourceSet"?)
      Application and DataStaging so that any valid JSDL document
      may have any of these globally defined elements as root element

- Any other elements and types should be locally defined. Or do we
   want to allow i.e. "jsdl:NetworkBandwidth" to be root element?

- Use xsd:group to group elements together and refer to these groups
   instead of repeating element definitions


Cheers,
Michel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: job.xsd
Type: application/octet-stream
Size: 3920 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/jsdl-wg/attachments/20050401/4f80bf03/attachment.obj 
-------------- next part --------------
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: example.xml
Type: application/octet-stream
Size: 917 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/jsdl-wg/attachments/20050401/4f80bf03/attachment-0001.obj 
-------------- next part --------------
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: example2.xml
Type: application/octet-stream
Size: 1050 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/jsdl-wg/attachments/20050401/4f80bf03/attachment-0002.obj 
-------------- next part --------------
  
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: readme.txt
Url: http://www.ogf.org/pipermail/jsdl-wg/attachments/20050401/4f80bf03/attachment.txt