9. XML 2.0 shall do away with insignificant whitespace (in content). Pretty-printing by putting the insignificant whitespace inside the tags and having all element content whitespace be significant would be nicer than having to rely on dtd or xml:space.

Maybe pushing it too far? Or is this just something that most people don't care about?

1, 2, 3, 6, 7, 9 : yes

4, 5, 8: maybe

7: hmm, this would be considerable barrier to adoption, especially if mixing of text and qnames is allowed in the attributes

Doesn't (3) conflict with (1)?

DTDs should definitely be evicted from XML.

XML should embrace the Infoset, it should be a syntax for trees rather than a syntax that implicitly happens to only allow trees. (This would make it much less painful to explain to people that in reality 95% of the XML technologies out there are in fact are Infoset technologies. IPath. ISLT. IQuery. SAI. AJAI.)

maybe add XML Base and XInclude, which could be optional, but at least would deserve better support than they have today.

Good catch, I guess 3 does conflict with 1, just a bit. I'm willing to reject both DTDs and documents that have names with colons in them that aren't conformant to Namespaces in XML.

Unfortunately, I think that XML 1.0 has already done its damage, so I'm not sure what purpose XML 2.0 would serve. Or, to put it metaphorically, after having drunk a bottle of XML 1.0 and awakened groggy in a dumpster with a few days of beard growth and no wallet, I'm not that eager to see how XML 2.0 tastes...

If anything is to be done other than to move on, less may be more, e.g., going back to the namespaces spec and removing any and all ambiguities.

See XML Skunk Works for a good base document for this effort. It is XML - DTD + XML Base + XML Infoset + XML Namespaces, and only 41 pages long (vs. 47 pages for XML 1.0). Removing the 4th edition naming rules would probably save another page or two. So that's all good. We could also yank attribute normalization, which Tim has admitted was a mistake. Adding prefix undeclaration and CURIEs would be cheap.

What else would we want? I'd like to see elements within start-tags, where <a href="foo"> is just shorthand for <a <href>foo</href>>, where the href sub-element can contain perfectly general XML. That would require some extensions to SAX, to be sure.

Yes, once you've opened up to the idea that attributes have structured values, then you can go the whole way and let them contain full-blown XML. The logical thing to do is treat elements as if they have some number of XML-content children, exactly one of which is anonymous.

Credit where it's due: James explained that to me in a bar in Bangkok in '99. Blew my mind at the time.

Still, I think I'd file that as one of the seventy-three whiz-bang features we don't do. In XML 2.0, anyway.

7, 7, 7 !

Seven!!

Jackpot?

No, Seriously. 7.

"Yes, once you've opened up to the idea that attributes have structured values, then you can go the whole way and let them contain full-blown XML."

Hmmm... or json-like...

<foo list=['a', 'b', 'c'] num=5, str="5">...</foo>

etc... Seriously, I think this is stretching it. It would be nice for simple cases maybe, but excessive nesting, and certainly full-blown XML kind of defeats the purpose of having attributes in the first place.

after previewing this comment: ouch, this does look tempting (but then again: don't a lot of bad ideas? ;-) But I'd go for this instead of full-blown XML if I had to choose)

Hi Norm.

Just to add to the discussion, I am surprised about 5). A QName is the name of an element or attribute. One can use it for other purposes, but I don't really see the point to allow a QName to start with a digit, but to still avoid element names to do so.

What about allowing prefix:* as a QName? And *:local? XPath uses QNames a lot, as well as other things, even things that look and smell like QName, but those are not.

Maybe those usages that are often used might be defined in a common dictionary, but I wonder if this is really the point of the XML recommendation?

-- Florent Georges

I always liked the idea that once an XML parser sees a document's first tag, it has a simple, unambiguous way to know when it's reached the end of the document, and 7 would do away with this. (Right?)

I was also going to ask what you'd cut if you were going to add these features without increasing the length of the spec, but I'm glad to see that John Cowan already has some good ideas there.

Bob

4. URI + local name to get longer URI. Fine, you do say "and we can argue about the precise mapping rules later" but wouldn't picking any mapping rules other than those of RDF (straight concatenation without extra '#'s or '/'s) cause more confusion than they're worth?

Blindness error:

Please swap 6 and 7 in my above post (#2)

7: maybe

6: is complexity worth it?

Some thoughts on 4 and 6:

- in the linked article (6), you use <{uri}name>. While I'm a fan of the James Clark notation and api's that let you use it (python elementtree), if you're having the fixed QName to URI mapping (4) anyway, can't you do away with the special notation? (as you can just use the full URI now?)

- if that is true, <uri> is very close to an unambiguous form not only for QNames, but for URI's in general (which is already a quite common notation, it's even in RFC2396 itself...). I think URI's ARE important enough to get special treatment... (although I'm generally against datatyping/binding in XML, contrary to what you might think from my previous comment). And if allowed for relative URI's, it would make xml:base much more useful...

- there's something nagging me about your QName to URI mapping, CURIE's, namespace prefixes+localnames, relative URI's and xml:base, but I can't quite put my finger on it. It has to do with all coming down to absolute URI's, and that this should be used somehow. Maybe it's just throwing away xml:base and using prefix declarations as a more general/powerful mechanism everywhere, I don't know... Can you go as far as saying that QNames ARE URI's?

XML 2.0 is like Olympic Games, it comes back every two to four years :)

John : 6 pages is huge room in you Skunk ! * What about adding xml:id ? * and what about a more pragmatic way to bing stylesheets (XSLT, XQuery, CSS, FO, etc.) and schemas (as DTD, XSD, RNG, RNC, Schematron, etc.)

My two euro-cents

<xml:entity name="nbsp" text=" "/>

You describe this as a solution for character references, but if people can do that, they will probably also do this

<xml:entity name="name" text="David Carlisle"/>

In which case hadn't you may as well let them do

<xml:entity name="name"><name><given>David</given> <family>carlisle</family></name></xml:entity>

That is, provide a (namespace aware) mechanism for all parsed entities not just character entities and document includes.

Clarifying that 'namespaces in xml, 1.1' means "version 1.1 of namespaces", not "namespaces in xml 1.1" and thus, that spec can be used with xml 1.0, and thus, namespace undeclaration is already possible, might help. IMHO.

I'm with you on #1-3.

Not sure about #4 and #5. Why are you picking that syntax over something like <http://docbook.org/ns/docbook::para>

As for #7, what if they created a compound XML document that consisted of multiple individual XML documents? Each individual root element would be considered a seperate document, but they could be contained in a single file?

Re: #8, I don't understand what the advantage would be. Isn't this just a new syntax for entities?

Re: structured attribute values... this looks like it could complicate things needlessly. I would hate to read a document with large amounts of XML in atrributes. If you need to stuff structure into attributes couldn't you use wiki-like or bbcode delimiters? Or the CSS-like notation of tyle elements? In fact this could be standardized and could be referenced from other parts of the XML document... but it would not be treated as ordinary XML.

XML 1.0 is broken with respect to internationalization, but not at all seriously. I've never once seen an actual instance of a problem caused by XML's internationalization problems.

There are far more serious issues in XML that could and perhaps should be resolved, mostly revolving around DTDs, the internal DTD subset, and entities. Namespaces and document fragments are also arguably broken.

If one were to resolve these issues in a new version of the spec, then one might as well fix up the trivial internationalization problems too. However XML 1.1 proved that internationalization is not a problem worth fixing in isolation.