> From: cmpilato@localhost.localdomain
> [mailto:cmpilato@localhost.localdomain]On Behalf Of C. Michael Pilato
> Sent: Thursday, October 09, 2003 4:11 PM
> To: Julian Reschke
> Cc: Jani Averbach; svn-dev list
> Subject: Re: XML parse error: Not well-formed (Not neon-0.24.3/svn bug)
>
>
> "Julian Reschke" <julian.reschke@gmx.de> writes:
>
> > Well.
> >
> > That's not a DAV-ism. Actually I'm, not aware of any language/format in
> > which identifiers can contain whitespace. Why is this a problem
> in WebDAV,
> > but not in XML (XML names), HTTP (message header names, method names) or
> > Java/C/whatever?
>
> It's a problem with DAV because they chose XML (and all the
> limitations that come with it) for their marshaling system.
>
> Note that we probably don't have this problem over ra-svn (just like
> countless other data transport problems we have in ra-dav but not in
> ra-svn). Why? Because Greg Hudson has his head on straight and
> decided that it was more sensible to design his own protocol with no
> obvious technical limitations than to select the trendiest-yet-limited
> protocol du jour.
>
> I'm not saying that it's bad to to have technical limitations. Who
> gives a rip if C/Java won't let you have spaces in your symbols?
> Symbols aren't the level at which users of software typically deal.
> It doesn't matter that a piece of recipe software can't use a variable
> named "Name of Recipe", but you better believe that people would hit
> the roof if their recipe names couldn't have spaces.
This sort of confirms what I feared: that people want whitespace in property
names because they use property names as *display names*. You shouldn't be
doing that -- how is I18N supposed to work if the identifier and the
displayname by definition are the same? It seems that there's a level of
indirection missing between internal property names, and what the user sees.
Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 9 16:24:35 2003