Listen, if I can <span xml:lang="sco">threep it doun the thrapples</span> of TagSoup users that HTML script and style element have SGML CDATA content models, a little bit of noise around implicit namespaces shouldn't be so very hard to swallow.

I think there are additional problems apart from the possible loss of the content-type label (which is bad enough).

What if the content-type is wrong? In the case of xml where the content encoding clashes with the xml declaration, there is a clear error situation. With implicit namespaces there is not (unless the parser is also supposed to infer the namespace from the root element name - I think not!), so mis-labelled entities may not be easily detected.

And why pretend that HTML is actually XHTML (which inferring the xhtml namespace seems to imply)? This is going to cause real problems if an html browser sees an svg tab (without a namespace), and treats it as SVG (this is the sort of thing fault-tolerant - nay - fault ENCOURAGING, technology currently does (I don't know if it does it for SVG, but if not now, it probably will soon).

The XML parser is going to infer the XHTML namespace for the svg element (and so throw a validation error if it is a validating parser). So we are getting different treatment between the browser and the XML processor.

I can't see any benefit in any of this.

Certainly in an HTML context, if "foreign" languages such as math and svg are going to be allowed (yes please!) you probably don't want to force the user to use the explicit xml-inspired namespace markup.

The amount of "harm" done by these kind of defaults depends a lot on where the defaulting happens. If you have a fragment of mathml in your browser you can (today) cut and paste that fragment and drop it into another mathml application (microsoft word to give a somewhat surprising, but pleasing, example) If however the stuff that is pasted in isn't namespaced then it won't work (getting xslt1 to work with elements that may or may not be in a namespace is a pain, as you must know from docbook). If however the defaulting happens on parsing and the DOM is fully namespaced and what is killed and yanked is a linearisation of that DOM fragment, not a fragment of the source, then defaulting namespaces (and other HTML-style defaults such as end tag omission, are far less intrusive.

I saw two problems, over all others, from XML in-the-trenches and XML in-the-standards.

1: specifically, acquisition/inheritance in markup sucks.

2: generally, implicitness in markup sucks.

I'm not sure what the idea gets you.

"There's also the nasty case of what to do when the representation loses its associated media type, when it's stored on a local file system, for example, but we already have that problem to a certain extent. This exacerbates the problem though, for sure."

I was thinking there's a big assumption for the proposal to work - that markup is being _sent_ (via MIMEish protocols). That's aside from browsers et al being up to this at all (try sending an Atom document into firefox with an embedded xhtml namespace - I had to make late changes to a project last year to deal with that)

When we were designing namespaces I really really wanted the namespace URI to identify a catalogue or manifest of some kind that would let you combine namespaces in a meaningful way. You'd say that your foo namespace was actually the union of HTML, SVG and Bird Watching Report, for example, with unlabeled conflicts resolved in that order.

It didn't get traction for a number of reasons, and I suspect it's too late now. I can imagine some kind of Namespace Definition Language for the purpose, with only a little effort...

I think in practice "implicit namespaces" make perfect sense, although I agree about the problem when content becomes disassociated from a MIME media type, which is almost any time anyone does anything with it beyond looking at it in a Web browser, unfortunately.

I suggested several things similar to that while I was on the TAG -- basically assuming a default URI for a given protocol/format and all undecorated names would be "resolved" relative to that URI. It wasn't exactly shot down as much as it wasn't preferred within the realm of XML (I think we were discussing id attributes at the time). A similar suggestion was later adopted for link relation names in Atom.

The deeper problem in this question is: What does a parser or processor do if it finds a node from a foreign namespace. You start processing your document from the top, knowing full well how to based on the mime type. Now you've hit a snag: Someone has decided to embed some SVG, but unless it fits semantically into the existing document structure there is no way that a processor can know what to do with it.

My view is that it usually isn't meaningful to add namespaces to XML elements or attributes. It is only meaningful to talk about the type of a whole sub-document, found somewhere useful such as the "content" element of an atom document. RDF documents can make effective use of namespaces only because each triple contains all necessary context to interpret that triple. In general, XML processing depends on a great deal of document context.

If xml namespaces are only being used to distinguish one kind of sub-document from another, all they are doing is competing with mime types. Which is better is a discussion that resolves around the need for a large namespace for document types vs the need to be able to infer super-type information such as "+xml" or "text/" from the type identifier.

I have started gathering notes on restwiki as to how XML documents should be used in machine-to-machine communication. My guidance at the moment is to ignore xml namespaces completely.

In my opinion implicitness of namespaces could be a definitely useful concept, but obviously a number of problems with processing of content using an incorrect MIME media type will arise. It is a sad fact, that most users nowadays tend to use MIME type that does not correspond to actual content.

The idea seems to be quite interesting and surely worth exploring further. However, I'm a bit sceptic if introducing such innovations is really necessary. They would surely make our life easier and the code would be simplified a bit, but I think that using explicit namespaces gives us the assurance of valid processing of the code while implicit inferring is somewhat risky.

I'd really like to see other languages allowed in HTML. Especially use of SVG is a very temtping feature. I'm actually at odds with defaulting in gerneral. Perhaps it helps for many users to make the code look neater, but then multiple complications too often tend to come about. Particularily the danger of loss of media type while storing a file on local system bothers me. Well, time will tell if any of the namespace solutions catches up.