Re: [xml-dev] Status of MicroXML?

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

On Sun, 19 Dec 2010 21:05:42 -0500
Amelia A Lewis <amyzing@talsever.com> wrote:

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

I disagreed that there is no consensus... I do agree that SXML
(needs a new name after James post!),  will need to address
mistakes (including stripping out some stuff). 


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

Noted. I think he has picked a fair audience (Pete and David
spoke up with examples), which won't be even 80% of XML users.
The audience I think may be  most receptive are the journeyman
programmers pushed to 'do something' with a piece of XML
and wanting to get to grip with some tools quickly. For them
the current XML stack is a no go area, hence the cry for a 'string
handling' of XML? 



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

A strawman of what? The original SXML, or what James called XML.next [1]
I'm guessing you mean XML.next rather than a full blown XML 2.0?
Please do. I'd love to see this forum focussed on single aspects rather
than blasting away at huge panoramas. 




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

<snip/> New thread Amy?


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

> The recent threads appealed to me: Michael Kay's proposal; James 
> Clark's proposal.  Both would be proposals I'd line up behind. 

> 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*).
JC(James Clark) != uxml? Which JC then? 


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

"Namespaces. It's easier to start simple and add functionality later,
rather than vice-versa, so I am inclined to start with the simplest
thing that could possibly work: no colons in element or attribute names
(other than xml:* attributes); "xmlns" is treated as just another
attribute. This makes MicroXML backwards compatible with XML
Namespaces, which I think is a big win."
See http://blog.jclark.com/2010/12/more-on-microxml.html 

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

Yet it appears under a W3C banner? Strange world of politics.

regards DaveP




[1] "XML.next - by this I mean something that is intended to be a more
functional replacement for XML, but is not designed to be compatible
(however, it would be rich enough that there would presumably be a way
to translate JSON or XML into it);"


-- 

regards 

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