Re: [xml-dev] Status of MicroXML?

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

On Sun, 19 Dec 2010 09:47:53 +0530, Mukul Gandhi wrote:
> I felt that developing something like XML 2.0/3.0 (which are discussed
> in other threads by Liam and Elliotte I believe) to add and fix things
> from XML 1.0/1.1,
[snip] 
> Perhaps the idea of MicroXML looks like a language profile concept,
> which to my opinion is fine
[snip]

Two comments:

1) I don't think that there is anything like consensus about what an 
"XML 2.0" should look like.  I don't think much discussion of the topic 
has happened here, although a few people have suggested directions.  
I'm not sure that I've seen two people agreeing.  I don't know how or 
when an XML successor (whether it's 2.0 or just Different Approach to 
Markup Now language) will happen; I think it will *have* to admit that 
there are some mistakes made in 1.0 (but I'm not certain that we have 
adequate consensus on what the mistakes are, as yet).

2) I tend to agree that I'm losing interest in JC's MicroXML, presented 
as a profile/"best practice" for XML 1.0.  I don't think that the 
things that it removes are all well-enough justified (and I'm not 
convinced that it's justified in *not* removing the last bits of 
doctype decl, either), and I don't feel that it's giving enough weight 
to the multiple-vocabulary issue.  I remain uncomfortable with the 
notion that MicroXML can't be reliably distinguished from XML 1.0, so 
that it may be impossible to gain the benefit of the (hypothetical) 
simpler parsers (the benefit to developers/authors remains; it *is* 
simpler to explain, apart from the hand-waving at "play nice with 
HTML5, except sometimes").

I continue to think that a variant that can be mapped one-to-one onto 
XML 1.0 (though the reverse may not, indeed should not, be true) with 
low-cost tools (the equivalent of a well-defined stylesheet), but that 
offers a more robust path forward as tools are incrementally upgraded 
is the better path.  I don't think that this is it, yet.  "XML 2.0" 
goes too far and costs too much; MicroXML (in my opinion) doesn't go 
far enough (except where it goes too far ... *sigh*).

Well, and I'd agree with [can't find the cite, now], who suggested that 
if we're going to do any *one* thing, we deal with the namespaces 
mess.  I'll reiterate my reading of the problem: there isn't a 
canonical "full-name" that can be used by other specifications, which 
means that binding a namespace to a prefix has to happen in some 
context, and there's inadequate assurance that the context will 
transfer with the syntax, depending upon where you make your cut before 
pasting.  Let's a) give up on putting namespaces in attributes 
completely, and b) provide a mechanism that divides the global 
space-for-names in a distributed fashion without requiring 
context-dependent mapping (optional mapping is okay).

And in a slightly different direction: I don't see any value in 
attempting to achieve conformance/compatibility with HTML5.  My reading 
of that WG is that it is powerfully antipathetic to the 
extensibility/generality of XML, and is unwilling to take any steps 
toward reconciling incompatibilities.  XML *cannot* introduce different 
parsing behaviors dependent upon the GI of the tag parsed (it is, by 
design, indifferent to the identifiers of tags); HTML5 is unwilling to 
accept introduction of a mode or indicator that would follow the 
otherwise-universal rules for these specific tags when encountered in 
XML.  Impasse; accept that HTML5 is something different from XML, from 
SGML, from any proposed variant or profile or enhancement of XML.

Amy!
-- 
Amelia A. Lewis                    amyzing {at} talsever.com
Love is never less for being shared.