W3C home > Mailing lists > Public > public-multilingualweb-lt-comments@w3.org > July 2013

Re: Comments on section 6.2 of ITS 2.0

From: Felix Sasaki <fsasaki@w3.org>
Date: Fri, 05 Jul 2013 16:42:40 +0200
Message-ID: <51D6DB60.8080005@w3.org>
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
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 

So in summary: if we follow your approach we will resolve your formal 
objection and create another one.


Received on Friday, 5 July 2013 14:43:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:32:28 UTC