Re: Comments on section 6.2 of ITS 2.0

Am 05.07.13 17:08, schrieb Daniel Glazman:
> On 05/07/13 16:57, Felix Sasaki wrote:
>
>> So please answer my question on a technical level, not in terms of the
>> standardization process.
>
> Ok, but the process still matters. If we reject a resolution for an
> issue "only because it's already shipped", then we can reject the
> whole process.

I didn't object your proposal. I was describing what I assume what will 
happen: if we adopt your proposal, implementers of the XML tool chain 
(more on that below) will very likely create an objection. I am now 
looking for technical arguments to avoid this "dead end" situation.

Pratically: would you be able to join the MLW-LT WG call next week 
Wednesday 2 p.m. CEST? I will then make sure that the XML tool chain 
implementers will be on the call so that we can move this technically 
forward.

>
> So from a technical POV:
>
> If we implement what I recommend with a CDATA section for XHTML docs,
> getting the ITS rules from any script element is ALWAYS a matter of two
> lines WHATEVER the flavor of HTML:
>
>   var source = scriptElement.textContent;
>   var itsInstance = (new DOMParser())
>                       .parseFromString(source, "text/xml");
>
> and the serialization is as simple, you create a TextNode or a
> CDATASection. That's for _both_ editors and the xml toolchain. I can't
> call that a burden.

Currently an XML implementation of ITS 2.0 can get all ITS 2.0 "global 
rules" with this XPath expression for all wellformed XML:

//its:rules

This XPath expression (or a jaxp implementation traversing an XML DOM 
etc.) is independent of whether the wellformed XML is XHTML or any other 
XML vocabulary.

With your proposal the current, general XML filters that e.g. extract 
translatable content out of general XML and that are also covering XHTML 
need to be special cased for CDATA sections. And: these filters work 
outside the browser in a pure XML environment, since localization 
workflows are mostly XML based, with XML formats like XLIFF, TBX, TMX, ...

>
> If we keep the current HTML/XML dicotomy with textual contents on
> one hand and a subtree on the other, that's considerably more complex
> to deal with.

For the browser, sure. But, as you know we already have one browser 
based implementer who didn't see an issue with this
http://attrib.org/jquery-its-example/
And we have many XML tool chain implementers who very likely want to 
avoid the CDATA unescaping step. But I can't speak for them, hence the 
proposal to discuss this on a call.

Best,

Felix

Received on Friday, 5 July 2013 15:34:08 UTC