{"action":"created","issue":{"url":"https://api.github.com/repos/ckeditor/ckeditor5-design/issues/126","repository_url":"https://api.github.com/repos/ckeditor/ckeditor5-design","labels_url":"https://api.github.com/repos/ckeditor/ckeditor5-design/issues/126/labels{/name}","comments_url":"https://api.github.com/repos/ckeditor/ckeditor5-design/issues/126/comments","events_url":"https://api.github.com/repos/ckeditor/ckeditor5-design/issues/126/events","html_url":"https://github.com/ckeditor/ckeditor5-design/issues/126","id":132149993,"number":126,"title":"Features: Schema","user":{"login":"scofalik","id":1502228,"avatar_url":"https://avatars.githubusercontent.com/u/1502228?v=3","gravatar_id":"","url":"https://api.github.com/users/scofalik","html_url":"https://github.com/scofalik","followers_url":"https://api.github.com/users/scofalik/followers","following_url":"https://api.github.com/users/scofalik/following{/other_user}","gists_url":"https://api.github.com/users/scofalik/gists{/gist_id}","starred_url":"https://api.github.com/users/scofalik/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/scofalik/subscriptions","organizations_url":"https://api.github.com/users/scofalik/orgs","repos_url":"https://api.github.com/users/scofalik/repos","events_url":"https://api.github.com/users/scofalik/events{/privacy}","received_events_url":"https://api.github.com/users/scofalik/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/ckeditor/ckeditor5-design/labels/features","name":"features","color":"fbca04"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":15,"created_at":"2016-02-08T14:04:10Z","updated_at":"2016-02-17T22:42:38Z","closed_at":null,"body":"# Features concept\r\n\r\nThis is a part of Features concept. This issue discusses schema. See also #129.\r\n\r\n## Schema\r\n\r\nSchema is a way to validate and organize elements positioning and occurrence in the Tree Model and Tree View. Generally speaking, for each element, schema says what elements can be contained in them, what attributes can be set on that element, and what attributes can be set on that element's children. Schema may be then used to verify if Tree Model or Tree View is properly built and also can be used to build a proper Tree Model or Tree View.\r\n\r\nDue to flexible and modular architecture of CKEditor5 that is based on \"plug-able\" `Feature`s, which then may introduce custom elements and attributes, it is impossible to create a static, hard-coded schema that will cover all possible features.\r\n\r\nInstead, schema will be (mostly) built on the fly, during `Feature`s initialization. We need a flexible, yet \"easy to use in simple cases\" mechanism for creating schema.\r\n\r\n*(Right now it's hard to say what exactly should be registered to schema, it will be probably used both by converters and commands. On the other hand it is used differently by Tree Model and Tree View. Maybe there should be two separate ways to add rules to schema. Are there any other places that we will also want to use schema?)*"},"comment":{"url":"https://api.github.com/repos/ckeditor/ckeditor5-design/issues/comments/185442625","html_url":"https://github.com/ckeditor/ckeditor5-design/issues/126#issuecomment-185442625","issue_url":"https://api.github.com/repos/ckeditor/ckeditor5-design/issues/126","id":185442625,"user":{"login":"Reinmar","id":156149,"avatar_url":"https://avatars.githubusercontent.com/u/156149?v=3","gravatar_id":"","url":"https://api.github.com/users/Reinmar","html_url":"https://github.com/Reinmar","followers_url":"https://api.github.com/users/Reinmar/followers","following_url":"https://api.github.com/users/Reinmar/following{/other_user}","gists_url":"https://api.github.com/users/Reinmar/gists{/gist_id}","starred_url":"https://api.github.com/users/Reinmar/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Reinmar/subscriptions","organizations_url":"https://api.github.com/users/Reinmar/orgs","repos_url":"https://api.github.com/users/Reinmar/repos","events_url":"https://api.github.com/users/Reinmar/events{/privacy}","received_events_url":"https://api.github.com/users/Reinmar/received_events","type":"User","site_admin":false},"created_at":"2016-02-17T22:42:38Z","updated_at":"2016-02-17T22:42:38Z","body":"I've been also thinking more about the `<figure>` element and I start to hate it. The fact that it cannot be nested in a paragraph makes all this so much harder ;/. Its description kinda clarifies this though:\r\n\r\n> The figure element represents a unit of content, optionally with a caption, that is self-contained, that is typically referenced as a single unit from the main flow of the document, and that **can be moved away** from the main flow of the document without affecting the document’s meaning.\r\n\r\nSo the idea is that a captioned thing makes no sense in the middle of some content.\r\n\r\nI even wanted to write that presumably we'll want to implement the image feature so you can only insert images between blocks (because that's what users usually want to do). I don't know though how this can be done from the UX perspective (how to explain it to the user)... but it means that perhaps we can have inline images and block images working differently. I hate to say that but it sounds like we are talking here about two different features, so two different data model elements.\r\n\r\nThis turns around one more thing which I wrote before :D. "}}