On May 16, 2004, at 12:09 AM, Branko Čibej wrote:
> Ben Collins-Sussman wrote:
>
>> On Sat, 2004-05-15 at 05:26, Branko Čibej wrote:
>>
>>> Should we treat XML mime-types as text? Users keep requesting this.
>>>
>>>
>> This means that svn will automatically try to do contextual,
>> line-based
>> merging on XML files. Isn't that bad?
>>
> Only as bad as merging C files is. If your C is all one line, merging
> won't work; similarily, if your XML is well structured and formatted,
> merging should work famously.
>
> -- Brane
Merging is great only if you understand the XML content (i.e. the tags
of any arbitrary DTD) well enough to perform a merge based on looking
at the XML data directly in a text editor.
As a general philosophy:
http://www.w3.org/XML/1999/XML-in-10-points
3. XML is text, but isn't meant to be read
There are obvious exceptions. I myself to all my XHTML web pages by
hand and I have xml configuration files for programs I write--config
files that users are never expected to edit directly. I would think
the exceptions should have exceptional treatment, not be the default.
I also have applications that produce XML files but that's just because
that's the format they chose, e.g. OpenOffice file formats are XML.
Now, my example of OpenOffice isn't necessarily problematic because the
recommended mime-types have xml in the type name, but not matching the
patterns you are considering:
http://books.evc-cit.info/ch01.html#mimetype-table
As I just wrote to the users@ list on a related topic
(application/postscript is the discussion rather than application/xml):
From http://www.rfc-editor.org/rfc/rfc2046.txt
Page 4-5:
3. Overview Of The Initial Top-Level Media Types
The five discrete top-level media types are:
.....
(5) application -- some other kind of data, typically
either uninterpreted binary data or information to be
processed by an application. The subtype "octet-
stream" is to be used in the case of uninterpreted
binary data, in which case the simplest recommended
action is to offer to write the information into a file
for the user. The "PostScript" subtype is also defined
for the transport of PostScript material. Other
expected uses for "application" include spreadsheets,
data for mail-based scheduling systems, and languages
for "active" (computational) messaging, and word
processing formats that are not directly readable.
Note that security considerations may exist for some
types of application data, most notably
"application/PostScript" and any form of active
messaging. These issues are discussed later in this
document.
I would think that anything application/* (including application/xml)
should not be treated as mergeable text.
-Travis Pouarz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 17 20:04:54 2004