[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: property names

From: Greg Stein <gstein_at_lyra.org>
Date: 2000-12-20 23:09:16 CET

[ to Greg Hudson, too ]

On Wed, Dec 20, 2000 at 01:28:48PM -0600, Karl Fogel wrote:
> Greg Stein <gstein@lyra.org> writes:
> > Urg. -1 on binary property names. As I've said before, property names should
> > be URIs. If we don't require URIs, then property names (between two
> > different tools) could conflict. And binary names certainly can't be mapped
> > into a URI :-)
>
> We can't require URI's. We can always use a certain URI ourselves,
> and encourage others to do the same, but in the end, what they do with
> properties is their business.

If a property name doesn't have a URI, then we can simply place it into a
namespace such as:

    http://subversion.tigris.org/xmlns/user-named/

I'm totally happy with saying that any property name that is not a URI gets
placed into the ".../user-named/" namespace. That gives you properties named
"foobar" *and* "http://www.lyra.org/viewcvs/svnprops/preferred-diff-format"

> There are lots of ways two different tools could conflict; we can't
> protect against all of them and shouldn't try. By allowing arbitrary
> names, we make a universe in which tools *can* cooperate if they
> choose to. That's the extent of our role. Enforcement will just get
> in the way of creative users.

Tools can certainly share property names. If I write Tool A that looks for
information from Tool B, then I just look for the properties that it
defines. Let's say it is called:

    http://www.tool-b.org/svn-props/widget-data

To the two different tools, this is the name. It is simply a well-defined
string. You're also saying the tools should share a well-defined string. But
what if Tool C also created a property called widget-data? Bummer. Now
everybody is screwed until somebody relents.

Also. Note that your above statement is another way to say, "well, we can
allow anything, so why not?" It is the trap I was talking about... I've got
a reason for requiring it to be a URI, so I'm asking for a "why *should* we
allow something else?"

"should we?" is always a better question than "we can, so why not?" There
are a lot of things that we *can* do with the software. But should we?

> > Can somebody give a rational reason for not using URIs for prop names? Other
> > than "that would be neat and the most flexible solution." Any requirements?
> > Use cases that need a binary property name?
>
> Sure: property names in character sets that we've never heard of.

The URIs are UTF-8 encoded (there is an RFC for this; I can dig up the
reference if necessary).

Next requirement? :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:17 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.