[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC