Polishing before v1.0

[odungern]

I propose the following to make the schema more consistent:

• rename enumerated dataType value from 'title' to 'value' .. which it is in the end. Rationale: all content, which may be provided in differrent languages, is called 'value'.
• remove requirement for 'title' in case of resources and statements ... and add it to propertyClass. Rationale: For resources and statements the title is redundant, if there are properties. In case of the properties, the title can be taken from the respective propertyClass in case of default.
• add 'files' to the list of required top level elements ... or remove 'statements'.

@oalt : what do you think? Agree?

[oalt]

@odungern: I agree with all. What do you exactly mean with "... or remove 'statements'."?

[odungern]

The list of required top-level elements is currently: "required": [ "id", "title", "specifVersion", "dataTypes", "propertyClasses", "resourceClasses", "statementClasses", "resources", "statements", "hierarchies" ]

Thus, 'statements' are required, even though there may be valid SpecIF data-sets without statements, but 'files' is not required, even though the same is true. Of course, one can always add empty lists, but I propose to make it consistent: Either we require all top-level elements, even though they may be left empty, or we allow to omit empty lists. In the latter case 'statements' are removed from the list and 'files' are not added.

I propose to take the latter approach. This corresponds best with the general principle of JSON schemata. However it complicates the programming, because the existence of an element must be checked before using it ...

[oalt]

I think only these properties should be required for a SpecIF file: "required": [ "id", "title", "specifVersion"] The reason is: With such a definition you can have SpecIF files only containing the data type and class definitions and other files conatining the data. When working with SpecIF you have to create a superset of all SpecIF data available. If a class is missing you can not edit or display the data, but you can keep it for the future, when you have got the missing data. Of course you need all required data when you exchange SpecIF data via file exchange, but in such a case a tool can include all required data dependencies. When only the basic data is required, the schema check is correct in all cases I have described.

[odungern]

Very good argument. I'll think about it again, but I guess this will be the way to go.

[odungern]

However, if we have a schema which requires almost nothing and allows everything else besides the defined elements, we don't need a schema at all. At every level we must decide whether we require certain elements or we don't permit any other elements than the defined ones. So far, there is only a limitation to the defined elements in case of dataTypes. The idea was to allow any private extensions everywhere except for the dataTypes.

[oalt]

I have thought about that again. I think it was a misunderstanding from my side: When you have a required property (e.g. an array of Resource elements) you can have a valid file containing an empty array ('resources' : []). Correct? In this case you can use the schema as it is/was. I would propose to include the files additionally.

[odungern]

Your assumption with respect to empty lists is correct for the current schema implementation. (You could, however, require a minimum and/or maximum of list elements). I will go through the schema during the weekend and reconsider all required elements at all levels. We must find a balance between a useful schema and some extensibility for special applications. I'll make a proposal and we can discuss again.

[odungern]

To decide which elements shall be required and which not, it is proposed to apply the following principles:

• require elements/attributes which characterize the nature or being of SpecIF, even if they are not necessary for a correct and useful system specification. Example: statements at the top level.
• do not require elements/attributes which may appear very often (and thus adding considerable volume) without adding any information. Example: empty property-lists in statements or empty subordinated node-lists in nodes.

The following elements are considered to characterize SpecIF and will be required:

• id, title, resourceClasses, statementClasses, resources, statements and hierarchies.
• all others may be added, if required. Example: property 'dcterms:description' is added, if formatted text is necessary. Then, suitable dataType, propertyType and properties are included in the SpecIF data-set.

Have a look at SpecIF schema v0.10.8.

[odungern]

And have a look at SpecIF schema v0.11.8

[odungern]

We keep the current definition for v1.0.0.