> Since Subversion owns the "svn:" namespace, we don't have to worry
> about compatibility with older clients *or* servers. No one else is
> creating "svn:" properties, and if they are, it's in violation of a
> long-published standard.
Subversion may own the "svn:" namespace in the context of Subversion,
but it certainly doesn't in the context of XML namespaces (and thus
WebDAV). The simple reason being that it's not a registered URI scheme
and thus is owned by nobody (as far as the IETF is concerned).
I always thought that one of the longer term goals of Subversion was to
be a RFC3253-compliant server (plus extensions). This also implies that
other CMS systems would be able to implement RFC3253 (+ the extensions)
and then would be able to interact with Subversion clients. It would be
a pity if that goal is gone. If it isn't, there should be a one-to-one
mapping of Subversion properties to WebDAV properties; and the simplest
way to achieve this is to simply use the same name format.
> It seems quite reasonable to me that people want "/" in property
> names, just as they want ":". We've already had real-world examples
> of both.
It doesn't seem reasonable to me at all; and I've spent the last 3 years
working on a CMS (incl versioning and resource properties), and nobody
ever has asked for that.
Asking again: what's the use case? Is it possible that people use the
*name* for display purposes (in the absence of something else such as a
property *display* name that would be I18N'd)?
> Good point.
> I certainly agree that we should decide on a valid syntax for property
> names (and values, for that matter), among other things. But the
> limitations encouraged by DAV are far too narrow, and we shouldn't
> settle for them unless we have absolutely no choice.
DAV simply relies on XML marshalling, just like *many* other protocols
as well (RDF in XML, Atom, RSS...). Using XML name syntax at least
guarantees a well-known and well-defined set of valid names that will be
compatible across many protocols/formats using XML as well. This by
itself is a big advantage because it allows sharing of property names
between these formats (for instance, I can make any feed-level Atom
extension element a WebDAV property, and the other way around).
I think giving that up would be a mistake, in particular when it's
absolutely unclear why one would want these characters inside an
Best regards, Julian
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Jul 22 08:46:27 2004