Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 25512 invoked from network); 14 Jan 2000 00:24:32 -0000 Received: from pop.systemy.it (194.20.140.28) by 63.211.145.10 with SMTP; 14 Jan 2000 00:24:32 -0000 Received: from apache.org (pv4-pri.systemy.it [194.21.255.4]) by pop.systemy.it (8.8.8/8.8.3) with ESMTP id BAA16483 for ; Fri, 14 Jan 2000 01:22:10 +0100 Message-ID: <387E5F98.E30887B1@apache.org> Date: Fri, 14 Jan 2000 00:28:24 +0100 From: Stefano Mazzocchi Organization: Apache Software Foundation X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,it MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: Sitemap and Links... References: <386A49B9.BC347632@apache.org> <387C8429.323141D@apache.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Stephen R. Savitzky" wrote: [...skipped very interesting points...] > I agree that RDF is too complex; I looked at WebDAV first and basically > ignored RDF. But WebDAV looks like it maps directly into the kind of > sitemap "document" that we both need -- a single XML document that contains > arbitrary XML metadata. > > Most of the PIA's extension mapping stuff, and your wildcard stuff, are > basically ways of compactly associating metadata (like styles and processing > steps) with documents. There are probably other ways that are just as good > if not better, including something like the X window system's Xdefaults > database. Now that I think of it, that's almost _exactly_ what we need. Ok. Let's try to sum up here. Let's list the points we are trying to make: - XML documents require additional data in order to be processed. - This data may or may not reside inside the documents themselves. - We all agree this data should _NOT_ reside inside the documents (like Cocoon does today with PIs), otherwise management costs increase at least linearly with the number of documents hosted. Do we agree on this? - A URI space should be considered a virtual addressing space, some of this maps to some real locations on file systems, some don't. - The .htaccess model is based on file system mapping, for point 1), this model is not general enough. - So, there must be a centralized "metadata" repository, plus local extention capabilities in those cases where this is possible. This leads to a "distributable sitemap" model. What about this? Let's move on: - the sitemap contains processing information that drive the functional mapping between servlet requests and responses. should the sitemap contain metadata information about the files? I think not. WebDAV and RDF stuff are _orthogonal_ to the processing instructions (not the PI, I mean the real term) required to "teach" the engine how to come up with a response, given the request. I totally agree something like this is needed, but I question the need for something like this in a sitemap. Anybody agrees with me? Now, wild-cards.... let's make a real example: http://host/data/users/stefano/bookmark/ generates the SQL query select * from bookmark on the database "stefano" of the database server mapped with "users" as for producer configurations. This is a general behavior and no file is touched to produce the document. There is no /data/users/stefano/bookmark/ directory on the file system, nor there should be one. How do you map that request to my MultiHostSQLProducer without wildcards? I think we cannot avoid the use of wildcards + mount points. Also, we cannot live without URL rewriting, but we'll presume this handled _before_ the request comes (at the web server level). Comments? -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. Friedrich Nietzsche -------------------------------------------------------------------- Come to the first official Apache Software Foundation Conference! ------------------------- http://ApacheCon.Com ---------------------