call 10 July? (Re: Comments on section 6.2 of ITS 2.0)

Hi all, that is esp. people in the "to" field of this mail,

could you join the MLW-LT call Wednesday 10 July, 2 p.m. CEST? Of course 
others are encouraged to join too.

For whose who haven't followed this thread: Daniel Glazman, implementing 
ITS 2.0 in BlueGriffon
http://www.bluegriffon.org/
is arguing for requiring ITS 2.0 "rules" inside (X)HTML "script" to 
appear in CDATA sections or XML comments. Various people in this thread 
(including me) pushed back. The discussion very likely will continue on 
mail, but the call might help to resolve the issue. And we need to 
resolve it: otherwise we cannot finalize ITS 2.0.

At Daniel, wrt to your question "for XHTML rules can appear everywhere, 
not just inside script?": this is due to the situation that most of the 
tools processing
XHTML with ITS handle it just as one XML flavor. This has the benefit 
that you can write general ITS processors, not taking any specifics of a 
markup vocabulary into account.

To support this approach, we have created a dedicated  ITS "rules" file 
already for ITS 1.0
http://www.w3.org/TR/2008/NOTE-xml-i18n-bp-20080213/#relating-its-plus-xhtml

The situation is now that the current approach (requiring ITS rules 
inside (X)HTML "script")) achieves backwards compatibility with ITS 1.0: 
an ITS 1.0 processor can convert e.g. XHTML using rules inside "script" 
to XLIFF and back. At the same time it allows for polyglot validation, 
as Jirka mentioned. If we now introduce CDATA or XML comments, the ITS 
1.0 processors and rules files like
http://www.w3.org/TR/2008/NOTE-xml-i18n-bp-20080213/#relating-its-plus-xhtml
will be broken.

So to me this sound like the choice between breaking exisiting tools and 
content (by introducing CDATA / XML comments), or putting a burden on 
HTML tool implementers (by keeping things as is). My high preference is 
the latter; I understand that performance will be an issue with inline 
global rules. But making web developers aware of this and strongly 
encourage them to use linked global rules can help.

Best,

Felix

Am 05.07.13 17:58, schrieb Jirka Kosek:
> On 5.7.2013 17:08, Daniel Glazman wrote:
>
>> 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:
> Whole point of recommending to use its-* attributes in XHTML is in order
> to get consistent results if you process page with either HTML or XML
> parser as users use wrong media type usually. Of course this will no
> longer be true with XML fragment inside <script> as it is not parsed in
> HTML but it gets parsed with XML parser.
>
> If you will introduce CDATA sections inside <script> then you break
> possibility of parsing content with HTML parser as HTML doesn't
> recognize CDATA sections. So while solving one problem, you have
> introduced another one -- resulting syntax is no more "polyglot compatible".
>
> I really don't see elegant solution which will satisfy all constraints
> here. We have to live with messy HTML parsing rules and sub-optimal HTML
> and XML compatibility.
>
> What about adding following into the spec:
>
> "If HTML or XHTML document contains script element with
> type=application/its+xml and such element does not contain any child
> elements then ITS markup must be extracted from this node by applying
> XML parsing on a content of the script element."
>
> Would that resolve your objection? It will be pretty clear what to do,
> and you can even use CDATA sections in XHTML if you think that makes sense.
>
> Your code will then be just little more complex -- it will test for
> presence of subelement -- if there will be some then all children of
> <script> element will be treated as fragment of ITS otherwise you will
> have first call parser on the text content of <script> node to get
> fragment of ITS markup.
>
>     Jirka
>

Received on Sunday, 7 July 2013 07:59:04 UTC