Re: Design goal regarding HTML5

Should I detect here an aim towards a grand unification (HTML / XHTML / XML)
facilitated via MicroXML? That seems to me a very worthy cause: Idenitfy
those
minimal changes needed to achieve such unification (what needs to be removed
from XML and from HTML to achieve convergence - let XML drop things to get
MicroXML and let HTML relax a few things such as the DOCTYPE declaration
and maybe the prefixes on attributes in the SVG component). Then 1) MicroXML
could allow parsers to preserve in its data model whether the markup
included
an empty element as <abc/> or as <abc></abc> or 2) maybe HTML would start
to treat them as equivalent. Either way, here is a potential road map to
sensible
convergence, isn't it, with MicroXML setting out to make the first step
from the
XML side and to highlight potential reciprocal changes that might be made
from
the HTML side.
----
Stephen D Green



On 6 September 2012 09:16, James Clark <jjc@jclark.com> wrote:

> On Tue, Sep 4, 2012 at 10:30 PM, John Cowan <cowan@mercury.ccil.org>wrote:
>
>> One of the nice things about MicroXML documents, indeed
>> James's original motivation for them, is that they are a good format
>> for human readable documents.  You can keep them around for processing
>> with XML or MicroXML toolchains, but if they use the right elements
>> and attributes, you can also view them casually in any web browser.
>> The only price of that is a fifteen-character signal (sixteen if you
>> have a trailing newline) that forces the web browser to DTRT rather than
>> enabling some unpredictable quirks mode.
>>
>
> 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 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
>
> James
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>