Re: [xml-dev] Status of MicroXML?

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

On Sun, 19 Dec 2010 08:15:25 +0000, Dave Pawson wrote:
> 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 liked Liam's catalog.  I don't think that it represents consensus, as 
yet, though.  Of the items listed, some I thought quite important, some 
I thought issues, but perhaps not demanding immediate attention, and 
some I thought non-issues (though I acknowledge that others felt 
differently).

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

You disagree that a 2.0 will *have* to address mistakes, or that we 
don't yet have consensus?  I'm thinking that you mean the no consensus 
part, but I'm not certain.

>> 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
> 
> IMHO James makes his view clear on that.

For what it's worth, I think his presentation and choice of items have 
been the most compelling to date.  It's just that I'm not feeling 
compelled.  Not that I'm necessarily one of the target audience, but 
... *shrug*.  It seemed better to provide feedback than not.

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

Ah!  Good.  Hmmmm.  Perhaps that means I ought to put up a strawman 
that would conform, following JC's example.

Here's a quick one, if folks are feeling egg-nog-argumentative: 

Take the XQuery Data Model.  From the seven node kinds, remove 
'Namespace' and 'Document'.  Remove everything that follows as a 
consequence.

Node names are local names; the data model would always report full 
names.  There's no concept of a document, so no xml declaration, no 
prolog, no distinction between text nodes containing whitespace and 
text nodes containing non-whitespace, doctype decl, and none of the 
things associated.  If a file or stream contains a single element, then 
it is congruent with current documents (a tree model); if it contains 
several elements, treat it as a hedge.  Or treat it as a series of 
documents.  Whatever works.

This would be the core of the proposal; it would adopt some variant of 
the namespace proposals that supply full names and permit abbreviation 
in context.  It's a bit more radical than most proposals to date; I 
would maintain that it's possible to turn this into XML 1.0 + 
Namespaces with a stylesheet-like transformation (note that it would 
not be a simple XSLT stylesheet; I don't think the input syntax would 
be accepted--but the core XSLT technology would be the place to go to 
generate the "to XML with Namespaces" transformation code).

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

The recent threads appealed to me: Michael Kay's proposal; James 
Clark's proposal.  Both would be proposals I'd line up behind.  I'm 
afraid that the webpage pointed at wouldn't be interesting, to me; the 
primacy it gives to HTML isn't, in my opinion, the correct solution to 
the problem.

I wrote more on what I thought wrong with Namespace in XML 1.0 before; 
I won't repeat it.  Instead, the principles of the solution, as I see 
it:

1) every element has a full canonical name (NSinXML: not true; MK and 
JC proposals: true; MicroXML: not true I *think*).
2) in context, abbreviation is possible--never in content, though 
(NSinXML: prefix mapping is not merely possible but required, but that 
PotP, not PotS; MK and JC proposals: true (not via prefix mapping); 
MicroXML: true via 'mapping the default prefix' in NSinXML-compatible 
fashion).
3) as a rule, don't create namespaced attributes; create attribute 
definitions that other folks can pick up (NSinXML: not true; MK and JC 
proposals: not treated; MicroXML: ns attributes not legal except 
xml:*).  (Note: it was the MicroXML rejection of namespaced attributes 
that made me think about and add this item).

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

I don't know that this would be either wise or possible.  The WHATWG 
came into the W3C with a fairly clear mandate: the committee members 
have the backing of the browser vendors, and for HTML, nothing is or 
can be more important (unless HTML were to expand beyond the browser, 
which doesn't seem to be terribly likely).  The W3C might make be able 
to provide some direction on the "XHTML serialization" of HTML.  
*shrug*  Won't matter to XML, or XML-derived languages, in my opinion.  
Different languages have different faces, different noses, different 
warts.

Amy!
-- 
Amelia A. Lewis                    amyzing {at} talsever.com
What makes me think I could start clean-slated?
        The hardest to learn was the least complicated.
                                                -- Emily Saliers