- From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Date: Sat, 21 Nov 2009 12:06:34 +0100
- To: Krzysztof Maczyński <1981km@gmail.com>
- Cc: public-html@w3.org
Krzysztof Maczyński wrote: > Much less. You write it once, it's very small (usually) and applied > not only to a single arbitrarily large document, but any set thereof > you may create. For virtually all use cases you'll be able to readily > find one suitable for your needs on the Internet (I'd be willing to > put up a service for finding or generating them based on requirements > stated by the user). A typical author wouldn't ever write one. I > believe even that Liam went too far in his simplification. > Unobtrusive Namespaces markup language is an XML dialect and it > merits its own namespace. The most serious problem with this proposal is that if browsers would be required to download these external namespace definition files, then it will inevitably create a single point of failure in these centralised services that you're talking about. If a popular one were to go down, all the sites relying on it for providing the namespace definition files would suddenly lose their namespaces. We've already seen the effects of what happens with such a model. Just look at the mess that was created with the RSS 0.91 DTD hosted by Netscape disappeared [1]. A few of the major RSS readers that depended on the DTD suddenly wouldn't display RSS 0.91 feeds any more. I know this is an extreme example, but the principle is the same. Parsing would become dependent on the availability of external namespace definition files. If a browser encounters a prefixed element in the document, it wouldn't be able to proceed until it could obtain the namespace definition file, assuming it's even available. This creates a major bottle neck for performance, which is simply not acceptable. [1] http://blog.netscape.com/2007/01/16/to-dtd-or-not-to-dtd/ -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Received on Saturday, 21 November 2009 11:07:06 UTC