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

Re: Design goal regarding HTML5

From: Uche Ogbuji <uche@ogbuji.net>
Date: Mon, 18 Feb 2013 00:01:22 -0700
Message-ID: <CAPJCua359L7nXSd6z2JAEmy3kXKT07_xpuh6W=f6mHSK5Ur68g@mail.gmail.com>
To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Cc: "public-microxml (public-microxml@w3.org)" <public-microxml@w3.org>
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
Received on Monday, 18 February 2013 07:01:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 18 February 2013 07:01:52 GMT