W3C home > Mailing lists > Public > public-microxml@w3.org > February 2013

Re: Design goal regarding HTML5

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Sun, 17 Feb 2013 08:09:07 +0100
To: public-microxml@w3.org
Message-ID: <20130217080907457549.718124c5@xn--mlform-iua.no>
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? 
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.

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? 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 
https://dvcs.w3.org/hg/microxml/raw-file/tip/spec/microxml.html#names )

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 

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.


Leif Halvard Silli

James Clark on Thu, 6 Sep 2012 15:16:59 +0700 asked:

> My original goal was that you could author valid HTML5 documents
> by
> - following the syntactic rules of MicroXML, and
> - following the constraints of the HTML vocabulary, where these
>   constraints were expressed in terms of the MicroXML data model.
> MicroXML would thereby provide a way to avoid the syntactic 
> complexity of the HTML syntax of HTML5.
> However, there are a number of things that stop this working:
> a) information about the DOCTYPE declaration is not in the
>    MicroXML data model
> b) HTML5 doesn't treat <X/> and <X></X> as equivalent
> c) MicroXML doesn't allow prefixed attribute names, but some 
>    attributes in HTML (notably xlink:href in SVG) require 
>    prefixes
> In addition, I'm not sure that many people found my original goal
> particularly useful.
> Point c) is also a problem for out current design goal:
> 8. MicroXML shall be able to straightforwardly represent HTML
> So at this point I'm not at all clear what we should be trying 
> to achieve vis-a-vis HTML5.
> If the goal is to be able view MicroXML documents that happen to
> use the right element/attribute names "casually in a browser", 
> then does it matter that the browser will use quirks mode (if we
> don't allow DOCTYPE)?
> For robust, standards-compliant delivery of HTML5, my current>
> inclination is to use an MicroXML->HTML5 serializer that does
> the right thing with empty elements, and adds a DOCTYPE 
> declaration. We should at least have a standard way of 
> representing an HTML5 DOM (at least any HTML5 DOM representable
> in the HTML syntax) in MicroXML, which means we need some
> convention for dealing with xlink:href.
> So my current position is:
> - no bare DOCTYPE
> - no to the additional HTML5 restriction on XML comments
Received on Sunday, 17 February 2013 07:09:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 17 February 2013 07:09:37 GMT