Cart
[Home] [By Thread] [By Date] [Recent Entries]
On Sun, 19 Dec 2010 21:05:42 -0500 Amelia A Lewis <amyzing@t...> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
