Re: [xml-dev] MicroXML

[Amelia A Lewis <amyzing@talsever.com>]

On Mon, 13 Dec 2010 16:01:11 +0700, James Clark wrote:
> I wrote a post describing a fairly minimal subset of XML:
> 
>    http://blog.jclark.com/2010/12/microxml.html

Nice.  I like the way that it copes with namespaces; I think it may 
improve upon Michael Kay's suggestion, even.

I have a problem with it.

How do I tell whether it's safe to use my uXML parser instead of my 
(heavier) XML 1.0 + Namespace in XML + XML:Base + XML:ID + whatever 
parser?

XML declaration not allowed.  XML 1.0 and uXML are placed in the 
position of both claiming to be the canonical format indicated by the 
absence of a declaration.

Processing instruction not allowed (meaning no presentation in the 
browser via XSLT, either, but that's another issue).  Can't use a PI to 
indicate that this is uXML.

Doctype declaration not allowed.  In comments on the blog, James seems 
to be leaning toward allowing the declaration (simplified: <!DOCTYPE 
root> with no public id, no system id (consequently no external subset) 
and no internal subset).  Problem with introducing it: it can't be 
effectively used, for uXML, as intended (unless uXML defines a single 
canonical root element).  Problem with using it: generally, a parser 
errors on encountering one of these anywhere but at the beginning (same 
problem as with the XML declaration).

That leaves: attribute on the root--or some other--element.  Does this 
defeat the design goal of embedding?  Specially-formatted comment.  
That ... simply changes the syntax of processing instructions (which is 
what happens in HTML, and no doubt will happen in HTML5 as well).  
Modifying content syntax to carry meaning has a long, inglorious 
history in HTML.

This suggests (to me) that the likeliest hack will be to create custom 
semantically important comments, possibly paired comments if uXML is 
widely deployed embedded (start and stop), although well-formedness 
might make a single indicator sufficient.

Personally, I'd rather have a PI.

In other issues, I think that there may be an over-emphasis on HTML5 
compatibility, even at the expense of XML compatibility.

If this were to be of interest, I'd expect to see it "grow up" with 
additional layers, at some point.  So, for instance, James's grammar 
describes strings; *someone* is going to want to apply schemata, of 
some flavor, and introduce 'typing' at some layer.  There may be an 
opportunity to suggest a better layer, but I'd say that if such a 
slimmed profile were adopted, one can predict some parts of its future 
(the functionality enhancements) by examining the functionalities 
provided by accepted and widely-implemented specifications in the XML 
stack.

Amy!
-- 
Amelia A. Lewis                    amyzing {at} talsever.com
There are two major products that came out of Berkeley: LSD and BSD
Unix.  We don't believe this to be a coincidence.