- From: Felix Sasaki <fsasaki@w3.org>
- Date: Fri, 05 Jul 2013 16:42:40 +0200
- To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- CC: Jirka Kosek <jirka@kosek.cz>, public-multilingualweb-lt-comments@w3.org
Am 05.07.13 13:07, schrieb Daniel Glazman: > On 05/07/13 12:47, Jirka Kosek wrote: > >> It's certainly little more difficult to handle both XHTML and HTML, but >> not that much. If you use HTML parser you can simply add additional >> processing step which will run additional parsing step on text node in >> all <script type=application/its+xml> elements and replace text node >> with a parsed tree. > > No. There is nothing I can replace because my users will not tolerate > it. The app just cannot modify the document tree like that in an editor. > >> IMHO options 1 and 2 can be implemented in ~10 lines of code. > > Jirka, I think I can safely be called an expert of wysiwyg editors > and I am telling you that even if it is implementable in 10 lines of > code, you are making assumptions about what can be done by the editing > tool (like above) and the performance/maintenance of such a code > that are wrong. > > If editors have to check the flavor of HTML they deal with at every > single step of ITS manipulation, that's a cost. If we have to deal > on one hand with a DOMDocument parsed from the script's contents and > on the other a DOMElement being the <its:rules> elements, that has a > cost and I don't even mention the fact |document.evaluate()| will > process XPath queries in two different contexts. > > For me as a editor vendor, such an issue is important enough to raise > an objection to the PR release. Let's assume you raise the objection and we do what you implement with CDATA sections / XML comments that you proposed to resolve it. Then test files like these https://github.com/finnle/ITS-2.0-Testsuite/blob/master/its2.0/inputdata/translate/html/translate7html.html won't work any more. We have several localization service providers in the group who work with an XML tool chain and that rely on the current representation. Your CDATA approach would put a burden on them, as Jirka stated. So in summary: if we follow your approach we will resolve your formal objection and create another one. Best, Felix
Received on Friday, 5 July 2013 14:43:13 UTC