Re: Comments on section 6.2 of ITS 2.0

On 5.7.2013 12:17, Daniel Glazman wrote:

> 1. do nothing, burden is on implementations. But an element that can
>    be parsed in two different ways in the html serialization of html5
>    and the xml serialization of html5 is in my opinion a quite serious
>    design flaw... The resulting DOM tree should be the same for both
>    html5 and xhtml5.

But this is rather design flaw of HTML5. During the development of ITS
2.0 we have had long discussion about this -- some proposed to not allow
inline global rules at all (because DOM is different based on parser
used) and some argued that this is important feature which must be
available in HTML5.

Given the lack of extensibility features in HTML5 using <script> was the
only usable option.

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.

> 2. clarify what happens when a <script type=application/its+xml> is
>    used, depending on html flavor and browsers' behaviour

Of course we can add such clarifying note. Do you have concrete proposal
where it should be to make it usable for implementers?

> 3. normatively force the contents of a <script type=application/its+xml>
>    element to be encapsulated inside a CDATA section or XML comment
>    inside XHTML documents. At least the resulting DOM in both html5 and
>    xhtml5 is made of a CharacterData node. That is an acceptable
>    compromise.

This would require special processing when XML toolchain is used. I
think that additional burden should be on side of HTML toolchains,
because it's HTML language which has defect here. Also using
CDATA/comments inside <script> is not conforming to polyglot spec and
doesn't adhere to DOM consistency principle.

> My preference clearly goes to option 3. Options 1 and 2 are too
> expensive for implementors, option 4 would be a pity.

IMHO options 1 and 2 can be implemented in ~10 lines of code.

-- 
------------------------------------------------------------------
  Jirka Kosek      e-mail: jirka@kosek.cz      http://xmlguru.cz
------------------------------------------------------------------
       Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep.
------------------------------------------------------------------
    Bringing you XML Prague conference    http://xmlprague.cz
------------------------------------------------------------------