[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Status of MicroXML?

  • From: Dave Pawson <davep@dpawson.co.uk>
  • To: Amelia A Lewis <amyzing@talsever.com>
  • Date: Mon, 20 Dec 2010 09:21:40 +0000

Re:  Status of MicroXML?
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);"



Dave Pawson

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.