- From: Erik Bruchez <erik@bruchez.org>
- Date: Wed, 5 Jul 2017 12:56:09 +0200
- To: Steven Pemberton <steven.pemberton@cwi.nl>
- Cc: "public-xformsusers@w3.org" <public-xformsusers@w3.org>
- Message-ID: <CAAc0PEULNSTY6mPXmDUiNstfE3E+gQWLDo9HfY0vmb8zf=g9PA@mail.gmail.com>
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