W3C home > Mailing lists > Public > public-html@w3.org > December 2009

Re: ISSUE-76: If we fixed namespaces, does RDFa still have problems?

From: Aryeh Gregor <Simetrical+w3c@gmail.com>
Date: Mon, 14 Dec 2009 18:30:52 -0500
Message-ID: <7c2a12e20912141530h4d3ad480yafef995900d5c544@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:55 UTC