This is the mail archive of the
docbook@lists.oasis-open.org
mailing list for the DocBook project.
RE: Re: DocBook filename extension
- From: Peter Ring <pri at magnus dot dk>
- To: 'Brian Lalonde' <brianiacus at yahoo dot com>, Norman Walsh <ndw at nwalsh dot com>,docbook at lists dot oasis-open dot org
- Date: Tue, 19 Feb 2002 17:21:34 +0100
- Subject: RE: DOCBOOK: Re: DocBook filename extension
Not that it would be a general solution: NT/WIN2K/XP can actually attach
extra attribute/value pairs to a file. It gets stored natively in the
filesystem on NTFS.
Anyway, I'd like to be able to ask the filesystem (or some such service)
about at least a MIME type and an encoding; these are inherent
characteristics of the file, and should be embedded in the file.
With the proliferation of DC-and RDF-style metadata, see for example Adobe's
XMP, http://www.adobe.com/products/xmp/main.html, I'd expect more utilities
dealing with embedded information.
kind regards
Peter Ring
-----Original Message-----
From: Brian Lalonde [mailto:brianiacus@yahoo.com]
Sent: 18. februar 2002 00:40
To: Norman Walsh; docbook@lists.oasis-open.org
Subject: Re: DOCBOOK: Re: DocBook filename extension
----- Original Message -----
From: "Norman Walsh" <ndw@nwalsh.com>
To: <docbook@lists.oasis-open.org>
Sent: Saturday, February 16, 2002 5:52 AM
Subject: DOCBOOK: Re: DocBook filename extension
> But once you've got a lot of your data in XML, you can imagine a tool
> that extracts more metadata about a document than just its filename. I
Labeling containers on the inside seems really inefficient and opaque.
> can imagine being able to write Make-style rules that are based on
> doctype or namespace name in addition to just filename.
Hmmm... xmake: XML awareness and a format that uses XML syntax.
Sounds like a cool idea.
> Some of this could be shunted off into the filesystem. Why shouldn't a
> filesystem be able to tell you the MIME type of a document, at least,
> in addition to it's name and size and other properties? Watching
When is a MIME type more useful than an extension?
What other metadata would be useful?
Are these needs general-purpose enough to be provided by the OS/shell,
rather than an XML parser?
> Windows try to associate applications with data files based on three
> letter extensions should have tought us by now that there has to be a
> better way. Extensions just aren't a big enough namespace (in the
> non-XML sense) for the functionality we need.
Windows extensions haven't been limited to three letters for quite a while.
Extensions are a *large* enough namespace, though it might be nice if
datatypes were more polymorphic.