- From: Andrew Daviel <andrew@andrew.triumf.ca>
- Date: Fri, 2 May 1997 17:26:45 -0700 (PDT)
- To: Benjamin Franz <snowhare@netimages.com>
- Cc: Robots List <robots@mail.mccmedia.com>, http-wg@cuckoo.hpl.hp.com
On Thu, 1 May 1997, Benjamin Franz wrote: > > Proposal: > > > > That the reverse META relationship in an HTML header be used to indicate > > that metainformation in the current document > > applies to the referenced object, not the current document itself. > > > > > > That the forward META relationship in HTTP (RFC 2068-19.6.2.4) be > > optionally used to indicate the existance of metainformation > > pertaining to a non-text object. > > > > That the reverse META relationship in HTTP be optionally used > > in an identical fashion to the reverse META relationship in HTML. > > http://www.ics.uci.edu/pub/ietf/html/draft-ietf-html-relrev-00.txt expired > almost a year ago. It is no longer an active proposal unless a new draft > has been issued somewhere and I didn't notice. Well, I had realized and I don't think there's a new one.. > > Regardless - one problem is that your proposal only allows *ONE* object to > be associated with the meta data in a document and so prevents the > document from containing meta information for *itself* (or for multiple > included objects). That wasn't my intention. HTML (and presumably SGML, XML) documents normally include their own metadata. Or do you mean something like an HTML page with two inline GIFs, both of which you want to provide metadata for? I was thinking of those cases where a major resource (datasheet, academic paper, movie) exists as one PDF, PostScript, MPEG etc. file and one wants to index it using one HTML file, and perhaps define both forward and reverse links. Metadata in different schemas for the resource can be indicated using a schema qualifier > So now you need *another* document with links to the > meta document so you can have a document with non-HTML objects with > associated meta data. Well, yes. Nobody's going to make metadata for an email icon. But if the HTML wrapper of a JPEG describes the JPEG, there's no reason it needs it's own metadata separate from the metadata for the image. I suppose it's a bit of a mess where some users have browser plugins and some have standalone viewers for VRML, MPEG etc. so that some may see the object as an embedded frame and others as a distinct object. However, PDF and PostScript documents would probably appear full-screen without a visible wrapper. > Additionally, there is the 'multiple/hostile > meta-document' problem - how do you resolve multiple meta definitions for > a single object and/or prevent someone *else* from assigning undesired > meta information to one of *your* objects? Is this different from someone framing your content, or creating a page with misleading or libellous links to your pages? One of the proposals (I think) for PICS-ng (or PICS 1.1) is to allow just that kind of thing. The metadata is tagged in that case with the metadata creator's name (rating service). It's not so daft in any case to have multiple meta definitions for the same object if they have different purposes or schema. One might be for a specialist academic broker and one for general Web use, for instance. > It would probably be better to try for a new HTTP header instead. Then a > server could send something like: > > Metainfo-Location: URL/URI Well, yes. But Link exists and has some recommended uses (toc, help) in HTML3.2 which people are starting to use. Link + rel/rev seemed to make sense. Andrew Daviel
Received on Friday, 2 May 1997 17:30:21 UTC