- From: Robin Berjon <robin@berjon.com>
- Date: Tue, 1 Dec 2015 11:38:52 -0500
- To: Florian Rivoal <florian@rivoal.net>
- Cc: public-scholarlyhtml@w3.org
On 01/12/2015 00:30 , Florian Rivoal wrote: > When we use a subset of existing standards, we must keep in mind that > the files may also end up being processed by tools not aware of SH, > and that these will understand the superset. So we need to avoid > conflicts between the two worlds, and think about this in two > directions: > > a - When we give specialized semantics to things, they must remain > compatible with the original non specialized definition, otherwise > generic tools may mishandle SH documents. Completely agreed. In fact, an SH document should just be an HTML document that happens to adhere to SH. The semantics aren't so much specialised as restricted. If we were to add new meaning, we'd need to think about a way of conveying the fact that content is SH (instead of HTML), with things like profile attributes, media types, etc. IMHO that would be a failure case. > b - We need to have clear definitions for what specialized SH > processing tools should do when they run into things that are not > part of the subset. And preferably, what they should ignore the extra > information, not hard failure. That way it is possible to author > documents that take advantage of everything a browser can do when > viewed in a browser, while still taking advantage of the specialized > meaning of SH when processed through SH specific tools. That also > gives a much nicer forward compat story. Again, absolutely. If we don't do that, we don't have a versioning story worth having anyway. We have to define a clear processing model for it (because otherwise it's confusing, see https://github.com/scienceai/scholarly.vernacular.io/issues/37) but that's just the usual. -- • Robin Berjon - http://berjon.com/ - @robinberjon • http://science.ai/ — intelligent science publishing •
Received on Tuesday, 1 December 2015 16:39:19 UTC