Comments on the XSD of PRD01

["Oliver Kopp" <oliver.kopp@iaas.uni-stuttgart.de>]

Dear  TOSCA-Team,

I've got some more comments on the XSD. I'm referencing the lines in the PDF
of PRD01.

Line 3634: Why isn't the complex type "tExtensibleElement" abstract="true"?

Line 3648 introduces a new type "importedURI", which is just a xs:anyURI.
Can't that additional type simple be removed? For other types of URIs such
as location or constraintType, there is no special URI attribute type.

Line 3653 introduces the element "Defintions" as new element of type
tDefinitions by using "xs:extensions". Why isn't just <xs:element
name="Definitions" type="tDefinitions"/> used?

Line  4246 onwards list multiple elements of type tImplementationArtifact in
tImplementationArtifacts. Instead of directly referencing
tImplementionArtifact, that type gets extended. Why is this extension
necessary? Isn't the extensibility of tImplementationArtifact itself enough?
In the case of tDeploymentArtifacts (line 4228), tDeploymentArtifact is
directly used as element type for DeploymentArtifact.

Page 18: In a definitions element, multiple extensions have to be nested in
<Extensions>, multiple Types in <Types>, but imports are put directly into
the XML. Why isn't there an "<Imports>" container?

Line 4377 introduces tExtensions, which is used nowhere else. I assume, it
should be used in lines 3664 to 3671 instead of re-declaring a sequence of
elements of type tExtension.

Line 3672 declares a sequence of tImport elements. This should be replaced
by declaring a tImports complex type and using that type.

Line 4201 introduces the element "ArtifactReferences" directly. Similar to
other sequences of elements (such as tPlans), there should be a separate
complex type tArtifactReferences.

Line 3996 introduces "RelationshipContraints" and Line 3999 introduces
"RelationshipConstraint" directly. To be consistent with the other
definitions, there should be a complex type tRelationshipConstraints and
tRelationshipConstraint be defined.

Line 4477 introduces "InstanceState" directly. To be consistent with the
other part of the XSD, there should be a complex type tInstanceState be
introduced. Possibly deriving from tExtensibleElements.

Line 4274 shows no use attribute for the attribute "targetNamespace". In all
other attribute declarations of the xsd, there is either 'use="required"' or
'use="optional"' given. A 'use="optional"' should be put here, too.

Line 4352: Why is tConstraint not deriving from tExtensibleElements, which
also allows any element from other namespaces.

Line 4477: Why is tCondition not deriving from tExtensibleElements, which
also allows any element from other namespaces.

Line 4522 introduces "tBoolean". This can easily be confused with
xs:Boolean. I propose to remove tBoolean and use xs:Boolean or rename
"tBoolean" to "tYesNo" to avoid confusion.


Extensibility seems to be important point for the specification.
For instance, tDefinitions (line 3660) and tExtensions (line 4377) drive
from tExtensibleElements.
This is not true for following containers:
* tTags (line 3724)
* tDeploymentArtifacts (line 4228)
* tImplementationArtifacts (line 4245)
* tPlans (line 4270)
* tTopologyElementInstanceStates (line 4485)
* tRequiredContainerFeatures (line 4511)

Why is that the case? Shouldn't be as much as possible elements be
extensible?




Referencing Types is done in different ways. Example: NodeTypes.
A tEntityTemplate (where tNodeTemplate derives from) points to its type by
using a QName (line 3858).
A tEntityType (where tNodeType derives from) points to its possible father
by the element "DerivedFrom", which contains a typeRef attribute having a
QName (line 3816).

For consistency reasons, always (or never) a surrounding element should be
used. In the example, derivedFrom should be an attribute of type QName or
the type attribute should become an element. In case always an element is to
be used, there should be a complex type definition tTypeRef.


For all *Types, there is tEntityType (line 3811) used as parent element,
for all *Templates, there is tEntityTemplate (line 3837) used as parent
element,
but there isn't a tEntityTemplate complex type used as parent for
tRelationshipTypeImplementation and tNodeTypeImplementation. For consistency
reasons, there should be one.


There are many complex types having the attribute combination
abstract+final+name+targetNamespace. There are even more with
name+targetNamespace. Couldn't there be an abstract super type where these
attributes are pre-defined and that the concrete complex element derive
from?


Line 3634 names the Element "tExtensibleElements" (which is plural), but
nearly all elements derived from that are named singular (e.g., tImport,
tServiceTemplate). The only exception is tDefinitions. I wonder why the
plural form has been taken. Why not just "tExtensibleElement" to stress that
each element (singular!) derived from this type is a single element.


Best regards,

Oliver