[jsdl-wg] Naming elements

[Yuri Demchenko]

Sorry, I can not understand most of comments and statements here.

Maybe explanation how most of these changes can improve understanding
or schema definition would help.

Michel Drescher wrote:
> 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

Sorry for my ignorance, why and when this may happen that "Similar
jobs (who have a different namespace)"?

Completely different? Can it be solved by using imported namespaces
and extension mechanism?

> 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.
> 
What does it mean referenceable?

IMHO, you can reference with ID/Id attribute or with XPath or with
xpointer any legitimate element in the XML document.

Do you mean referencing schema elements/types?

> - 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.

can you give an example what you mean by above?

> - 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.

Sorry I can not understand how/why some elements are qualified as
local and what is the incentive of using global vs local elements?

If you are talking about definitions like

<xsd:element name="Description" type="jsdl:description" minOccurs="0"/>

this I can understand.

> - 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
> 
How above is related to the schema attributes elementFormDefault and
AttributeFormDefault?

What is the reason of limiting number of global elements? What is the
benefits of having local elements?

Does it help implementation/programming?

> - 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
> 
There should be some reason to group some elements except referencing
them together. How many these cases of repeated definitions you have?

Sorry I am really confused.

Yuri

> 
> Cheers,
> Michel
> 
>  
>  
>  
> 
> 
> ------------------------------------------------------------------------
> 
> This text file carries explanations for the exammple given for the 
> proposal of a new schema layout.
> 
> Package contents
> ================
> job.xsd        - the schema defining a simple JSDL inspired job structure
> example.xml    - a sample XML document following the job.xsd schema
> exmple2.xml    - another sample XL document following the same schema as
>                  examle.xml. Additionally it uses more advanced features
>                  like referring to elements defined in example.xml, and
>                  the usage of POSIXApplication that is part of the 
>                  JSDL specification.
> readme.txt      - this file
> 
> 
> job.xsd
> =======
> This schema defines a bunch of element types and elements. In particular
> and in order of appearance in the schema:
> 
> MemoryType
> ----------
> A simple type of xsd:positiveInteger describing physical memory, in Bytes.
> 
> StorageType
> -----------
> A simple type of xsd:positiveInteger describing any sort of storage, in
> Bytes.
> 
> CPUCountType
> ------------
> A simple type of xsd:positiveInteger describing an amount of CPUs
> 
> ResourceGroup
> -------------
> A xsd:group structure containing zero to three elements, each of type 
> MemoryType, StorageType, or CPUCountType, respectively, so that each type
> occurs only once in this group.
> 
> ResourceType
> ------------
> A complex type allowing elements of the group ResourceGroup. Additionally,
> it has an attribute of type xsd:NCName for the purpose of (possibly 
> external) referencability.
> 
> ExecutableType
> --------------
> A simple type defining how to speciify an executable.
> 
> ArgumenntType
> -------------
> A simple type defining the structure of a command line parameter.
> 
> EnvironmentType
> ---------------
> A simple type defining the structure of environment variables
> 
> ApplicationGroup
> ----------------
> A group collecting elements of type ExecutableType, ArgumentType and
> EnvironmentType. Same constraints from ResourceGroup apply.
> 
> ApplicationType
> ----------------
> A complex type allowing elements of the ApplicationGroup to appear inside.
> Additionally, for referencability, it has an attribute "name" of type 
> xsd:NCName.
> 
> JobType
> -------
> A complex type defining the associations between Resources and an application.
> It defines two local elements "Resource" and "Application" (so that they do not need a namespace qualifier and cannot be root elements), both being
> complex types allowing elements of the group ResourceGroup and 
> ApplicationGroup, respectively. They also define an attrbute of type
> xsd:QName each.
> Additionally, the local element "Application" allows for extension just as
> JSDL does (by allowing any XML element from other namespaces).
> 
> Jobs
> ----
> This is the only globally defined element in this schema. Thus any 
> document following this schema must have "Jobs" as root element.
> Jobs defines three local elements named "Resource", "Application" and
> "Job" that are of type "ResourceType", "ApplicationType" and "JobType",
> respectively.
> It also allows arbitrary attributes of any namespace.
> 
> 
> example.xml
> ===========
> This sample XML document defines a set of resources named 
> "AnySuitableComputer" (you will notice the inspiration from Igor's
> proposal...) and an application named "MonteCarlo" (same goes here...).
> It finally defines a Job that associates the resources 
> "AnySuitableComputer" with the application "MonteCarlo".
> Note that the QNames must be given using the target namespace prefix ("ex" 
> in this case) even if the referred elements are declared in the same 
> document.
> 
> example2.xml
> ============
> This example defines a customised version of example.xml. It uses the same
> set of resources, but overrides the value for Storage (since this version
> happens to need more storage space, for the sake of this example).
> Also, it uses the same application definition. Additionally, it uses a
> POSIXApplication extension to be able to use a POSIX specific version
> off the Monte Carlo simulation. This bit of this example is somewhat
> artificial since it now specifies two Executable elements and it is 
> unclear which one the consuming system should use. But after all, it's 
> just an example. :-)