[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: The illusion of simplicity and low cost in datadesign and

• From: "Liam R. E. Quin" <liam@fromoldbooks.org>
• To: JSON Developers List <xml-dev@lists.xml.org>
• Date: Sat, 13 Aug 2022 16:08:22 -0400

On Fri, 2022-08-12 at 23:36 +0100, Michael Kay wrote:
> > 
> > I'm glad someone mentioned the old days of Mac OS, when files had a
> > "resource fork" and a "data fork", 

[...]

> 
> 
> It was painful and awkward because they were simultaneously trying to
> make the system look like Unix,

For MacOS (found in e.g. the original Macintosh back in 1984) i don't
think there was any attempt to be Unix-like. They didn't even have a
hierarchical file system at first, and no preemptive multitasking.

The trouble with the resource/data fork model is that it's fragile: the
two halves can easily get separated.  The same is true for invisible
metadata stored as file system attributes (e.g. in Linux ext3 or ext4).

So there's a lot to be said for the Unix "magic number" approach, where
files start with a string that identifies them - "#! /bin/sh" for
example :) - because it is carried along with the file.

You (Mike) wrote also,

> There are some cases, I think, where it makes sense for an
> application to encapsulate data files so that access to the files is
> only possible via that application: an obvious example is database
> files - you really don't want people messing with database files
> except via the DBMS software.

but even here, a database debugger, a db repair tool, a third party
backup tool, might all need to access the database file. They might all
use a shared service to do so, or they might not.

The idea of data files belonging to a specific application means that
you don't get to think in a way that leads to tools such as "grep"
(able to search for strings in files regardless of format or syntax).

We're used to thinking that you can use pretty much any XML tool on
pretty much any XML file; my "marketing" take on this was that it was
the "XML Promise", i.e. interoperability.  So you can run Saxon on an
SVG graphic to extract the text for translation, or to make a swatch of
colours in a new image file, and the result isn't a "Saxon file", it's
an XML document.

Maybe i'm just wedded to the creative possibilities of systems that
encourage us to combine tools.

liam

-- 
Liam Quin, https://www.delightfulcomputing.com/
Available for XML/Document/Information Architecture/XSLT/
XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
Barefoot Web-slave, antique illustrations:  http://www.fromoldbooks.org

• Follow-Ups:
  • Re: The illusion of simplicity and low cost in datadesign and computing
    • From: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>

• References:
  • The illusion of simplicity and low cost in data design and computing
    • From: Roger L Costello <costello@mitre.org>
  • Re: The illusion of simplicity and low cost in data designand computing
    • From: Michael Kay <mike@saxonica.com>
  • Re: The illusion of simplicity and low cost in data designand computing
    • From: Roger L Costello <costello@mitre.org>
  • Re: The illusion of simplicity and low cost in datadesign and computing
    • From: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>
  • Re: The illusion of simplicity and low cost in data designand computing
    • From: Tim Bray <tbray@textuality.com>
  • Re: The illusion of simplicity and low cost in data designand computing
    • From: Michael Kay <mike@saxonica.com>