Re: Validation and optional fields

I agree that we should do it.


> 1. adopt the new rule, and bite the bullet and say that indeed it is not
> completely backwards-compatible, but they are mostly edge-cases.


To clarify, I didn't say (I hope) that these would be edge-cases. A simple
field with `type="xs:integer"` without a `required` property would hit this
case. So I think the backward-compatibility question is definitely there.
In our implementation, for example, we will need a way to enable the new
behavior. (An implementation-specific switch is not a problem for us.)


> 2. keep @required as-is, possibly deprecated, and introduce @optional,
> which introduces the new rule (but the other way round).
>

I know I suggested this. I am not yet entirely convinced myself, as that
can introduce some confusion. But if we relegate the `required` attribute
and MIP to a footnote, indicating that it is present only for
backward-compatibility, that might still be workable.

So the new validity rules would be:
> - the constraint model item property is true
> - if the required model item property is true, the value is non-empty
> - if the value is non-empty, it satisfies all applicable types.
>

I am not sure if you follow an order above, but order matters. It should be:

1. If the value is optional and empty, it is valid. No further validation
processing is needed.
2. Then the value must follow all applicable datatypes.
3. Then all XPath constraints should evaluate to `true()`.

-Erik

Received on Wednesday, 5 July 2017 10:57:09 UTC