RE: Design goal regarding HTML5

Re: James' message below about HTML5 ...

I could never quite understand the design goal of MicroXML documents being directly usable in Browsers.   XML itself is sparsely used in browsers and I dont think making MicroXML will change that.
Furthermore the set of people who hand edit text files directly to be displayed in browsers is a small selective set (likely a set highly represented by the likes of us ... but I assert is miniscule).
Rather Browser docs are either

* Edited in HTML editors
* Generated by some process from another form (often made out of snippets of HTML and code either active or pre-done).

So I personally see almost no value at all in MicroXML  being used *directly* as a browser doc.   If you want to edit a text file for a browser then I think one would use HTML.
Or if you want to use MicroXML then one would process it either as a "Save As" option in a MicroXML editor or a processor which can do HTML serialization.

So in conclusion I agree now with James' latest statement.
We should drop HTML compatibility as a design goal for MicroXML in the raw form.   But should consider it in a processed form.
That is, it makes good sense (to me) to be able to edit an MicroXML file which is *trivially converted* likely via well-defined serialization rules (i.e. doesn't require XSLT or some other more complex process) into HTML(n+1).    The last bit means we hope for some backwards and future proofing for older or newer versions of HTML from the same MicroXML document.

The bit about some HTML tags needing ":" I suggest we simply cough and look the other way.  If you are generating such HTML then you need either to use XML , HTML , or a more complex processor.

-----------------------------------------------------------------------------
David Lee
Lead Engineer
MarkLogic Corporation
dlee@marklogic.com
Phone: +1 812-482-5224
Cell:  +1 812-630-7622
www.marklogic.com







>>>  James Clark

I think we badly need to get some precision about our design goals are with respect to HTML5.

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 our 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

James













 

Received on Thursday, 6 September 2012 11:18:33 UTC