[ to Greg Hudson, too ]
On Wed, Dec 20, 2000 at 01:28:48PM -0600, Karl Fogel wrote:
> Greg Stein <firstname.lastname@example.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:
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:
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? :-)
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:17 2006