You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Impact: Any code which attempts to generate controlled mode data using Shape Expression constraints will need specific bespoke handling for termsOfService, which means it's harder to write and brittle to any changes of constraints
As an example of just such specific bespoke handling, look for oa:Terms in packages/test-interface-criteria/test/testShapeDataMatchesConstraints.js, which generates data in order to check that ShEx constraints match the non-ShEx ones.
This is an extract of how this constraint is defined presently, in packages/test-interface-criteria/src/testDataShape.js:
This is not a good match for an ArrayConstraint as they presently are defined and used. Currently, ArrayConstraint is used for things like oa:OpenBookingFlowRequirement, where the constrained value is an array of items from the oa:OpenBookingFlowRequirement enum. oa:Terms, on the other hand, is a data structure, not an enum. This means that, presently, any implementation which uses these Shape Expressions must have custom handling for oa:Terms ArrayConstraints.
One possible solution:
Make ArrayConstraint a meta-constraint which takes a constraint, applies it to items within an array, and adds special array-specific constraints like minLength. In this way, the oa:OpenBookingFlowRequirement constraint would be something like: ArrayConstraint(OptionNodeConstraint(datatype='oa:OpenBookingFlowRequirement')). And then, the terms constraint would apply ArrayConstraint(..) to a single-oa:Term constraint. (possibly a RecordConstraint meta-constraint to allow for further specifications of each property in each oa:Terms object?).
One consideration here would be that we don't presently have any meta-constraints.
The text was updated successfully, but these errors were encountered:
Impact: Any code which attempts to generate controlled mode data using Shape Expression constraints will need specific bespoke handling for
termsOfService
, which means it's harder to write and brittle to any changes of constraintsAs an example of just such specific bespoke handling, look for
oa:Terms
in packages/test-interface-criteria/test/testShapeDataMatchesConstraints.js, which generates data in order to check that ShEx constraints match the non-ShEx ones.This is an extract of how this constraint is defined presently, in packages/test-interface-criteria/src/testDataShape.js:
This is not a good match for an ArrayConstraint as they presently are defined and used. Currently, ArrayConstraint is used for things like
oa:OpenBookingFlowRequirement
, where the constrained value is an array of items from the oa:OpenBookingFlowRequirement enum.oa:Terms
, on the other hand, is a data structure, not an enum. This means that, presently, any implementation which uses these Shape Expressions must have custom handling foroa:Terms
ArrayConstraints.One possible solution:
Make ArrayConstraint a meta-constraint which takes a constraint, applies it to items within an array, and adds special array-specific constraints like minLength. In this way, the
oa:OpenBookingFlowRequirement
constraint would be something like:ArrayConstraint(OptionNodeConstraint(datatype='oa:OpenBookingFlowRequirement'))
. And then, the terms constraint would applyArrayConstraint(..)
to a single-oa:Term constraint. (possibly a RecordConstraint meta-constraint to allow for further specifications of each property in each oa:Terms object?).One consideration here would be that we don't presently have any meta-constraints.
The text was updated successfully, but these errors were encountered: