What about the QName ? The only thing that smells iffy is the form Norm. How about to keep the parser writers happy? I can see why the first colon is needed, but for aethetics and authoring habits, keeping qnames a bit like empty elements seems reasonable? I'll look forward to more articles on this.

I don't like the syntax. It looks too much like an unbalanced start tag. Sure, it's not syntactically ambiguous to a computer, but humans' ability to check the syntax is more important. Since entities are going away anyway, I suggest &{uri}name; and &prefix:name; instead. If that's a dumb idea, I'd be happy to hear why.

Other than that, I think the proposals are great.

I avoided the "&" escape character because it's already used for the built in entities (<, etc.) and numeric character references (  etc.). I suppose that &{uri}localname; and &:p:localname; are still possibilities, it just seemed like a lot of overloading on that character.

I was aware that the forms I chose look a lot like start tags. I even toyed with <{uri}localname/> but I decided that made the problem even worse.

I think I could go either way.

Nice. Some obs.

"In XML 2.0, all documents would be namespace aware. Furthermore, the “null namespace,” the namespace in which elements appear if there is no namespace declaration, would have an explicit URI (and could, consequently, be associated with a prefix). This reduces all of the magic of the “null namespace” to simply a question of a default declaration. We could go a step further and simply outlaw the null namespace, but that seems a bit extreme to me."

xmlns="" would do fine for the null namespace - think of the months you could save not arguing about which scheme to use.

And drop default namespaces too - they suck.

I could live with the 'QClark' syntax, but maybe you should use a closing tag form for consistency. The truth is that allowing macros to work over markup and content is always going to be messy.

What you haven't done is verify that this will allow QNames and namespaces to roundtrip. That's a very important thing to get right this time.

The problem with using "" for the null namespace is that it would break the ability (important to some, I'm sure) to undeclare a namespace. As for dropping default namespaces, I could live with that, but I bet lots of folks would object. Lots of documents are only in a single namespace and using names without colons for those cases is appealing.

As for round-tripping, I'm pretty confident my proposal manages that. The parser can recognize all the QNames and it can serialize all the QNames. At least if they're in one of the new syntaxes.

I'm honou?red, you want to force the whole world through the pain of a version transition, just to inflict pain on me!

Mike Kay suggested on xml-dev recently (and before) that the {uri}local name ought to be allowed _everywhere_ that Qnames are recognised including element start and end tags, schema declarations, XPath steps etc so that you could write out everything without carrying namespace context if you need to. That would clash with your suggested Qname in content markup as M's suggestion would make that a legal start tag. (But that's just syntax....)

Woa: déjà vu [1,2,3]! :-) I agree that the entity syntax is a bit harsh [4], and I think consistancy with other entity sytaxes is important. However your solution for defining all entities seems pretty good. A few possible issues with your idea may include:

• How are the mappings between entities and XML content defined? That is, how is · defined to be <{http://www.w3.org/2003/entities/iso8879/isonum}middot>?

• Many XML processors won't necessarily have the ability to access the internet and download the definition files - a way to specify a local copy (public id?) is helpful.

• What happens if the entity can't be resolved for some reason or another? XML 1.x's fatal error behavor is often quite annoying: a fallback mechanism would be nice.

In addition, a possible alternative syntax that doesn't hurt existing XML 1.x processors (and looks nicer, IMHO) looks like [based on 3]:

<animals
    xmlns="http://example.com/animals/"
    xmlns:ent="http://example.com/entity/ns/"
    ent:cls="http://purl.org/stuff/colors/"
    example="%cls:rainbow;"
    >
    <dog
        xmlns="http://purl.org/stuff/dogs/"
        paw="%cls:golden;"
        >
        <nose>%cls:brown;</nose>
    </dog>
</animals>

Of course, that's an ugly hack and requires an additional %pc; escape sequence. However, it could be used to test your approach with existing XML processors via XSLT or some pipe.

Notes:

P.S. Your software barfed on the % symbol - I had to use an entity for it. Odd, since it is valid xml.

[1] http://norman.walsh.name/2004/11/10/xml20#p32

[2] http://dannyayers.com/archives/2004/11/05/exorcising-qnames/

[3] http://slashdot.org/~Quantum Jim/journal/89855

[4] http://norman.walsh.name/2004/11/10/xml20#comment0002

For character entities, just add to the predefined set. Take everything from HTML 4 and others if needed (such as MathML?). That list really isn't big since the representation can be very simple. Voila. No need to have external references at all, and I don't have to wonder how to say &middot; today.

Of course, this doesn't address the general QName problem, but I'd really rather not put these two issues together.

Everyone with extra needs could just use better editors. Or, as you suggest, specialized applications could still use Elements or QNames with special significance, but there would be no need to confuse them with character data.

Hello,

There are some nice ideas, but there a long long way...and the form could become better, so let's wait ...

But the good points are :

* merging {XML, XML Infoset, XML Base, XML:id, XML Namespace}

* removing DTD Infoset (fixed attribute value, entity definition, DOCTYPE call)



The brace notation {} looks good, but we need to introduce two new predefined entities ( &lb; { and &rb; } )

But why throwing entity notation ?

&{http...}foo; looks good

And why not changing the http dummy protocol ?

Why not introducing the xml:// protocol to really make the difference ?

But I saw a bug

You wrote this



<?xml version="2.0"?>

<<{http://example.com/xmlns/doc}doc>

xmlns:a="http://example.com/xmlns/a">

<<{http://example.com/xmlns/doc}p> a:att="value"

<{http://example.com/xmlns/b}:att>=”value”/>

<<{http://example.com/xmlns/doc}doc>>



but I think you mean this



<?xml version="2.0"?>

<<{http://example.com/xmlns/doc}doc>

xmlns:a="http://example.com/xmlns/a">

<<{http://example.com/xmlns/doc}p> a:att="value"

<{http://example.com/xmlns/b}:att>=”value”/>

</<{http://example.com/xmlns/doc}doc>>

 ^

 +---- here is the missing slash



Cheers, and keep going

We don't need new built in entities for curly braces because they aren't recognized except immediately after "<" (or perhaps "&"). There's nothing special about { this }.

Good Luck getting rid of Maths entities!

When people are writing XPaths etc, they will now need to know which part is a Qname and do something extra? Sounds complicated.

And wouldn't it mean that a language with a Qname could never be an XML Schemas simple type, because it has structure?

Everyone also would have to abandon any idea that attributes are always simple types too. This seems an enormous change, in practice. Surely the point of having a layered system of specifications is to allow one layer to change without requiring change in all the other layers?

And would it mean that every existing XML language that uses Qnames somewhere in data values would have to be redefined?

So I wouldn't characterize something that requires a change to the XML Infoset, the PSVI, XML itself, XML Schemas type system and components and syntax, XQuery, XSLT1, XSLT2, etc, as well as changes to many other languages and systems as being minimal.

A goal of XML 2.0 should be that one can replace a current XML parser that generates SAX with an XML 2.0 parser and also generate SAX. That is layering. Everything hinges on building in the Maths and standard entity references into the basic language. Then you can get rid of DOCTYPE declarations. Without that first step, no progress can happen. The people who have trouble with Qnames are a tiny minority: leave that for XML 3.0 please!

May I recommend Schematron's way again? See http://lists.w3.org/Archives/Public/www-tag/2002Jun/0183.html

By the way, XML 1.1 cannot be a failure unless it has no eventual uptake from the people who need its facilities. Have the Ethopians etc. complained? If the goal of XML 1.1 was to attract people from XML 1.0, then it would have addressed more popular issues. In fact, XML 1.1 was designed to prevent a potential handicap for some underdeveloped countries more than meet a current worldwide demand for Unicode 4. Cheers Rick

For the record: I am not trying to remove character entities out of some perverse desire to make life harder for the people who need them :-)

While we are at it, can we please remove NOTATION from the XML syntax...?

Is there any reason why the :p:localname syntax couldn't be used to reference entities that contained text and element content? I mean, not just for referencing single characters?

(I realize of course that some standard format would need to be used for declarations that associate the names with content, and processing apps would need to know how to parse it.)

Anyway, I don't personally care so much about the problem of how to use ISO named characters in DTD-free doc instances -- because I think there already some great authoring tools, like your "XML Unicode" package, that obviate the need for it.

But I would really really like to have a DTD-free way to declare and reference external text/element content -- regardless of what delimiters it may use (that is, whether it's angle brackets as in your proposal or the "looks more like classic SGML entity refs" style somebody else suggested in a comment.)

And as far as the problem that somebody mentioned of how to handle getting stuff from the URI locations if you're not connected to the Net -- that's already solved: Have local copies and make your tools use a URI resolver to remap the URIs to local system paths.

I thought Tim Bray had an elegant solution to this by moving entity processing out of the XML processing and into the encoding with his UTF-8+names proposal.

http://www.tbray.org/ongoing/When/200x/2003/10/17/UTF8-plus

And I second the removal of Notations, though I think that without DTDs they drop out anyway.

A good article. Lots of detailed debate ahead though.

A couple of warts-on-a-wart on the QNames-in-content problem:

(a) prefixes are used in content independently of QNames, e.g. XPath uses prefix:* and XSLT has attributes containing a list of prefixes

(b) if QNames-in-content are to be understood at the parser level then you need to be able to distinguish whether absent prefix means null namespace (as in XSLT) or absent prefix means default namespace (as in XML Schema).

Great article, but I think you are still not addressing what I find to be one of the chief pain-points of namespaces in XML 1.x: they look like attributes, they quack like attributes, some software thinks they are attributes, and some doesn't, they look like part of the content but they aren't so you get this weird effect of them applying to their own start tag, which means you have to do arbitrary buffering just to dispatch a start tag, and its a messy swamp all the way around.

So, first up against the wall when the revolution comes, for me, is overloading the attribute syntax for namespace declarations. I want ns decls to also be first class syntactic objects, and I want their scoping to be manifest in that syntax.

And then I consider seriously the question of namespaces and the default namespace and non-namespaces vis-a-vis attributes.

World peace to follow as an exercise for the reader.

Do you suggest a common URI for the NULL namespace, wherever it is used?

I read the NULL namespace like a database NULL: That we don't know if the element has any semantics, and we don't know what the semantics are, if they exist.

The implication of a URI for the NULL namespace, is that my <foo/>and your <foo/> carry the same meaning, I don't think that's what we want from a NULL namespace?

Or should the URI of the NULL namespace be the URI of the document where the NULL namespace is used? E.g., if I use a Team element with NULL namespace in http://heima.olivant.fo/~styrheim/gallery/stadium/stadium.rdf, then you could use the same element un your document, not with the NULL namespace, but with namepace http://heima.olivant.fo/~styrheim/gallery/stadium/stadium.rdf# ?

Hi I want to know whether there is any difference in XML 1.0 & 2.0 coding stucture. When i am running an XML code with version changed to 2.0 i am getting an error in internet Explorer. Can you guide me how to run an Xml versin 2.0 example and also i want to know which browser supports XML 2.0 language

Regards

I'm not sure but it seems that there are no such browsers released yet. Right me if I'm wrong.

As someone who has published documents using MathML, I'd be very happy to see named entity references for symbols go away. That's why we have Unicode and that is what I used.

The Unicode folks have worked very hard to continue to include more and more symbols for Mathematics and Science. In the end, if you invent some symbol, you'd be better off with some special piece of markup that indicates it is a non-standard character rather than some character reference that isn't really true.

In the end, I don't the MathML folks are completely screwed as I'm one of them. We've all just got a transition to make--and we have XML 1.0 for backwards compatibility if we get stuck.

In the end, we need to push the use of unicode and add or change the specifications to meet all our needs. A tall order, but the right direction.

I think you need &copy; etc if you wan't to support non unicode encodings, and those are likely to be in use for many years yet.

On the encoding of namespaced tags how about:

<?xml version="2.0"?>

<"http://example.com/xmlns/doc":doc>

<"http://example.com/xmlns/doc":p "http://example.com/xmlns/a":att="value" "http://example.com/xmlns/b":att="value"/>

</"http://example.com/xmlns/doc":doc>

To me that seems much easier to read, and it should be fairly easy to parse as well. I would remove the namespace from the end tag, as it's redundant information anyway.