Re: Design goal regarding HTML5

On Sun, Feb 17, 2013 at 12:09 AM, Leif Halvard Silli <
xn--mlform-iua@xn--mlform-iua.no> wrote:

> Hi James, I agree more with your original goals about HTML5
> compatibility. Therefore I propose:
>
> 1. DOCTYPE declaration: Why not allow doctype declaration, without DTD,
> as a legacy feature, and require that it should match the root element?
>

Because the benefits in hack-for-hack compatibility with HTML5 do not
outweigh the added syntactical complexity.



> It is not up to *this* community group - or to the XML working group -
> to decide that it is not important whether a MicroXML document consumed
> as HTML, causes quirks mode rendering.
>

I don't see why this is relevant.  We're designing a markup language here,
not a Web browser.



> 2. xlink:href. Question: Is it not meant to be poossible to embed
> non-MicroXML documents, (e.g. XML 1.0 documents)  directly inline in a
> MicroXML document?


No this is not a goal.  It's worth noting that this is not in general
possible with XML 1.0, either.



> I ask because, unlike what you said, xlink:href is
> not an attribute in HTML5. It is an attribute in SVG (which HTML5
> considers to be in another namespace, even in the text/html
> serialization). It is thus, per HTML5’s own terminology, 'foreign'
> content. If MicroXML does not allow this today, then I propose to do
> allow embedding of 'forreign' XML 1.0 in MicroXML documents - this
> would solve the xlink:href problem until SVG eventually is updated.
> (Btw, MicroXML production [22] *does* seem to permit ':' in attribute
> names
> https://dvcs.w3.org/hg/microxml/raw-file/tip/spec/microxml.html#names )
>

This bit makes me think that you meant "elements" rather than "documents"
in the above section.  Anyway no, MicroXML does not offer a means of
embedding any character sequence that does not itself conform to MicroXML.



> On the other two other issues, then I agree more with you:
>
> * For the 'additional HTML5 restriction on XML comments', then I can
> live with <!--> being permitted in MicroXML simply because it would
> probably be an infrequent problem.
>
> * For <X></X> vs <X/>: I was about to sugges that it should be an error
> if <X/> was represented as <X></X>. However, in addition to e.g. <hr>
> and <br> HTML also have <script></script>, which is not equivalent with
> <script/> (the later is simply unclosed). So it is probably best to
> keep it as is and thus require authors to eventually take of the HTML
> conformance.
>
> My perspective on this is as one who has backed Polyglot Markup in the
> HTML working group, which defines a polyglot format for XHTML (thus
> XML) and HTML. It would be pity if one couldn’t create polyglots based
> on MicroXML and HTML5 as well. Yes, I read here that this was not
> important.[1] But for example I saw that John published an MicroXML
> example, which was basically a quirks-mode triggering HTML page, and
> said that it was MicroXML.
>
> Of course, if these things are not intresting to this community, then I
> the more shall I focus on the HTML working group’s Polyglot Markup, and
> warn aginst MicroXML as a solution to the problems that Polyglot Markup
> tries to solve.
>

I do not think that anyone should be advocating MicroXML as a solution
anywhere on the spectrum of HTML Polyglot Markup.  It sounds as if your
proposed warning is appropriate.

Historical note: It's true that thinking about HTML5 and JSON were the
initial triggers for work on MicroXML, but over time, and with much careful
discussion we worked out a difficult balance between these influences, and
that of XML 1.0, to arrive at what you see in the current community draft.


-- 
Uche Ogbuji                       http://uche.ogbuji.net
Founding Partner, Zepheira        http://zepheira.com
http://wearekin.org
http://www.thenervousbreakdown.com/author/uogbuji/
http://copia.ogbuji.net
http://www.linkedin.com/in/ucheogbuji
http://twitter.com/uogbuji