- From: James Clark <jjc@jclark.com>
- Date: Tue, 24 Jul 2012 11:38:29 +0700
- To: John Cowan <cowan@mercury.ccil.org>
- Cc: David Lee <David.Lee@marklogic.com>, "public-microxml@w3.org" <public-microxml@w3.org>
On Tue, Jul 24, 2012 at 11:14 AM, John Cowan <cowan@mercury.ccil.org> wrote: > James Clark scripsit: > >> The ideal situation would be that MicroXML meets two requirements. >> >> 1. MicroXML can be used to represent any HTML5 DOM, and >> 2. HTML5 validity for MicroXML documents can be specified at the >> MicroXML data model level > > I don't agree with #2 at all; the model ought not to have complications > added solely for the sake of the HTML5 validity case. Unless there is > one and only one way to write a MicroXML document from a given model > (which seems unlikely) there may need to be a way to specify output > options, and "html" or "html5" may be among those. One use case I'm thinking of is using a text-based MicroXML editor (similar to nxml-mode) to write HTML documents. It would be convenient if my MicroXML editor could ensure I was writing valid HTML5 just by telling it to use the appropriate HTML schema. #2 need not always involve adding complexity to the data model. For example, restricting comment syntax to be HTML5 compatible helps with #2 (that's the only justification for it), but doesn't change the data model. The empty element issue could be dealt with by simply not allowing empty element tags in MicroXML, rather than by representing the use of empty-element syntax in the data model. I completely agree that adding complexity to the data model is a negative, and goal #3 explicitly mentions simplicity of the data model as an objective. When #2 does require adding complexity to the data model, then I would say it's a matter of deciding between conflicting goals and a key factor would be how much complexity it adds. Without #2 , I don't see how the MicroXML improves upon XML in regards to HTML5-friendliness. James
Received on Tuesday, 24 July 2012 04:39:17 UTC