Re: [xml-dev] Status of MicroXML?

[Dave Pawson <davep@dpawson.co.uk>]

On Sun, 19 Dec 2010 00:24:38 -0500
Amelia A Lewis <amyzing@talsever.com> wrote:


> 1) I don't think that there is anything like consensus about what an 
> "XML 2.0" should look like. 

I'd tentatively suggest there is a moderate level of agreement
on the problem areas, if not solutions Amy? See Liams summary?


> 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).

I disagree with this to some extent. The namespace aspect
of this (these?) threads being an example. Agreed more could
come out with more focussed threads. That simply hasn't happened
on the list. 



> 
> 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").

IMHO James makes his view clear on that. I disagree with the HTML5
view, but it may well come up trumps with the backing it has. 
We'll see. The quirks of HTML5 mentioned recently have really put
me off. I'm sure a new tagsoup will see to them though.


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

Lovely summary of a solid way ahead. Thanks. 100% behind this intent. 




> 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*).

<grin>Eee, There's no pleasing some folk</


> 
> 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).

I don't understand this. Perhaps you'd go a bit further with
your thinking?
I do see it as one area that most were in 
agreement as needing to be addressed, has been worked before and some
more this time. 
http://www.dpawson.co.uk/namespaces/  and recent threads on this list.




> 
> And in a slightly different direction: I don't see any value in 
> attempting to achieve conformance/compatibility with HTML5.

That's James Clarks view. He may be right. 

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

It would seem that the HTML5 WG are going their own  way
regardless of XML concerns. Unless W3C steps in, which so far
I don't see, or the horrors reported here wouldn't be happening.




-- 

regards 

-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk