{"action":"opened","issue":{"url":"https://api.github.com/repos/w3c/poe/issues/237","repository_url":"https://api.github.com/repos/w3c/poe","labels_url":"https://api.github.com/repos/w3c/poe/issues/237/labels{/name}","comments_url":"https://api.github.com/repos/w3c/poe/issues/237/comments","events_url":"https://api.github.com/repos/w3c/poe/issues/237/events","html_url":"https://github.com/w3c/poe/issues/237","id":254696677,"number":237,"title":"Validator/validation/valid-related terminology","user":{"login":"nitmws","id":1301232,"avatar_url":"https://avatars1.githubusercontent.com/u/1301232?v=4","gravatar_id":"","url":"https://api.github.com/users/nitmws","html_url":"https://github.com/nitmws","followers_url":"https://api.github.com/users/nitmws/followers","following_url":"https://api.github.com/users/nitmws/following{/other_user}","gists_url":"https://api.github.com/users/nitmws/gists{/gist_id}","starred_url":"https://api.github.com/users/nitmws/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/nitmws/subscriptions","organizations_url":"https://api.github.com/users/nitmws/orgs","repos_url":"https://api.github.com/users/nitmws/repos","events_url":"https://api.github.com/users/nitmws/events{/privacy}","received_events_url":"https://api.github.com/users/nitmws/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2017-09-01T16:52:01Z","updated_at":"2017-09-01T16:52:01Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"The IM of 1 September defines in 1.3 Terminology the term \"ODRL Validator\" as \r\n\r\n> A system that checks the conformance of ODRL Policy expressions with respect to the ODRL Information Model validation requirements.\r\n\r\nIt defines two key features:\r\n1. checking conformance\r\n2. being aware of validation requirements\r\n\r\n**re 1: conformance with IM**\r\n* 2.1 Policy Class defines that a Profile can define \"conformance requirements\" - I assume they don't have to be covered by a \"Core IM\" Valdiator.\r\n* 2.6.8 outlines what an ODRL Validator has to validate - by examples: \"For example, this includes property cardinality and relationships, and conforming to validation requirements.\"\r\n* That's all about a Validator covering the conformance to the IM.\r\n* What is missing: to write down what a Validator must validate outside an example, e.g. in the Terminology definition. (A general issue: the whole section 1 is not-normative!)\r\nI suggest: \r\n**A system that checks the conformance of ODRL Policy expressions, including the cardinality of properties and if they are related to types of values as defined by the ODRL Information Model, and the Information Model's validation requirements.**\r\n\r\n**re 2: validation requirements**\r\n* The are defined in 2.5.2 Logical Constraints, 2.7 Policy Rule Composition, 2.7.1 Compact Policy, 2.8 Policy Metadata, 2.9 Policy Inheritance in a consistent way - that's fine\r\n\r\n**The \"valid\" status of a Policy**\r\n* Section 2.10 Policy Conflict Strategy defines checks clearly outside the definition of the ODRL Validator - and that this check has an impact on the valid/invalid state of a Policy. \r\n* This causes terminology confusion:\r\n  * a processor called Validator returns for its validations as result the Policy is **(not) conforming** to the IM - and NOT that the Policy is **valid** or **invalid**\r\n  * checking the conflicts inside a Policy - which is not done by the Validator -  returns as result **valid** or **invalid**\r\n* Knowing that this would change a term with a long history but for making the IM more transparent I suggest: \r\n**the results of checking Policies for conflicts results in \"in-conflict\" and \"no-conflict\"**\r\n... and the **enumeration term \"invalid\" should be changed to \"unusable\"** \r\n"}}
{"actor":{"display_login":"nitmws"}}