- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Mon, 14 Dec 2009 18:30:52 -0500
- To: Toby Inkster <tai@g5n.co.uk>
- Cc: "Ennals, Robert" <robert.ennals@intel.com>, Maciej Stachowiak <mjs@apple.com>, "public-html@w3.org" <public-html@w3.org>
On Mon, Dec 14, 2009 at 5:31 PM, Toby Inkster <tai@g5n.co.uk> wrote: > Given that the name "Apple" was recently subject to an enormous lawsuit > between Apple Records and Apple Computers, surely this shows precisely > why this couldn't work? I don't see how this is relevant, unless you think someone is going to be sued over using a vendor prefix. A case from real-world markup languages where prefix collisions have caused serious problems would be more to the point. In any event, the problem with URLs is that they tend to be extremely long and difficult to remember. Identifier collisions are rare, and collisions of prefixed identifiers are even rarer, so you're creating substantial inconvenience for *every* use to ward against the very unlikely event of a prefix collision. A good solution would have no cost to the author except in the event of an actual collision -- optimizing for the common case. One approach to this would be to have a designated prefix with fixed meaning, but with a disambiguation mechanism (perhaps using URLs) that can be used in the event there really is a collision. This is the "automatic namespaces" idea that was recently discussed here. So tools that processed x-apple content would assume that x-apple stood for their favorite URL *unless* otherwise explicitly specified. Authors would then have to give the xmlns only if an actual conflict arises, and could safely omit it otherwise. Authors who were particularly worried about collisions could specify the xmlns regardless, but those who prefer brevity at the expense of marginally greater risk wouldn't have to.
Received on Monday, 14 December 2009 23:31:26 UTC