Change constraint in schema 1.1

[oalt]

Currently the schema defines, that a resource class shall define at least one property class reference. In the following case this leads to an error:

In that case an "Epic" element should be defined based on the "Requirement" element by inheritance. The properties are just the same and reused by inheritance. Only the title is changed:

{
    "id": "RC-Epic",
    "title": "SCRUM:Epic",
    "description": [
        {
            "text": "An 'Epic' is a big user story and will be refined by user stories/requirements."
        }
    ],
    "revision": "1.1",
    "replaces": [],
    "extends": {
        "id": "RC-Requirement",
        "revision": "1.1"
    },
    "isHeading": false,
    "instantiation": [
        "user"
    ],
    "propertyClasses": [
    ],
    "changedAt": "2021-06-27T08:59:00+02:00"
}

[odungern]

The idea behind requiring at least one property per resource (and thus one propertyClass per resourceClass) was that a resource without payload does not make sense. We do not have any native title and description any more. (Just to commemorate).

Yours is a valid corner-case. I did not consider it, so far. An argument could be:

• If the properties are equal, is it indeed a different class?
• In other cases we have common classes with sub-classes via dcterms:type, such as "Component", "Function" and "Role" all being of class FMC:Actor.
• In my projects I consider user-stories as functional requirements in a special form. So Epics would be requirements at a larger scale - which may be refined by user-stories. I think it is an equally valid abstraction.

Alternatively:

• We can indeed do without requiring a minimum number of properties by schema ...
• ... and add a constraint in the constraint checker for all resources (and statements) after collecting the properties from all inheritance relations.
• This is fine, as well.

What do you think?

[odungern]

Following the principle that systems shouldn't patronize the users without a really urgent need (for example, if malfunction or complexity is caused), there is an argument not to require a minimum number of properties.

However personally I would continue to consider user-stories and epics as requirements.

[odungern]

Have removed from the schema the requirement to have >0 properties for resources and statements. Similarly, propertyClasses, subjectClasses and objectClasses have no more minimal item count.

Instead, the check will be made in the constraintCheck including the items of any parent element.