- 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
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 names 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 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. [1] http://lists.w3.org/Archives/Public/public-microxml/2012Sep/0145.html 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 UTC