- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 25 Dec 2008 11:46:26 +0100
- To: Ian Hickson <ian@hixie.ch>
- CC: public-html@w3.org
Ian Hickson wrote: > On Thu, 25 Dec 2008, Julian Reschke wrote: >> Ian Hickson wrote: >>> That does seem to a spec for it, indeed. How about "adobe:ns:meta/"? >>> >>> (Another reason to have a centralised registry rather than URIs or >>> java-like identifiers is to make it possible for conformance checkers >>> to catch typos.) >> So are you saying that a single central Wiki-shaped registry for XML >> namespaces would actually work in practice? > > XML Namespaces on the Web, or XML Namespaces in general? The use cases are > very different. For XML in general, there are multiple completely > unrelated markets, within which different rules will be needed. It doesn't > matter if a car manufacturer doesn't know about flower namespaces, because > they won't be interacting with flower shops. Indeed. > For HTML, where interoperability matters (i.e. "on the Web"), there is a > single, very large, market. It's a very different situation, and warrants > different solutions. Web sites for car manufacturers will be accessed with > tools that are also used for flower shops. There are no silos. That is correct, but I don't see why that means a central registry is required. There are many case where one wants to put something on the web, but still use extensions that only some of the recipients will understand. A good compromise is a mix of both, as currently practiced for Atom link relations. BR, Julian
Received on Thursday, 25 December 2008 10:47:07 UTC