Return-Path: 
 <forrest-dev-return-4242-apmail-xml-forrest-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-forrest-dev-archive@xml.apache.org
Received: (qmail 11330 invoked by uid 500); 18 Dec 2002 14:24:48 -0000
Mailing-List: contact forrest-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:forrest-dev-help@xml.apache.org>
list-unsubscribe: <mailto:forrest-dev-unsubscribe@xml.apache.org>
list-post: <mailto:forrest-dev@xml.apache.org>
Reply-To: forrest-dev@xml.apache.org
Delivered-To: mailing list forrest-dev@xml.apache.org
Received: (qmail 11316 invoked from network); 18 Dec 2002 14:24:46 -0000
Received: from fep02.tuttopmi.it (HELO fep02-svc.flexmail.it)
 (212.131.248.101)
  by daedalus.apache.org with SMTP; 18 Dec 2002 14:24:46 -0000
Received: from apache.org ([80.204.154.181]) by fep02-svc.flexmail.it
          (InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP
          id <20021218142431.YEAS4548.fep02-svc.flexmail.it@apache.org>
          for <forrest-dev@xml.apache.org>; Wed, 18 Dec 2002 15:24:31 +0100
Message-ID: <3E0084C7.2000100@apache.org>
Date: Wed, 18 Dec 2002 15:23:03 +0100
From: Nicola Ken Barozzi <nicolaken@apache.org>
Reply-To: nicolaken@apache.org
Organization: Apache Software Foundation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.2) Gecko/20021126
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: forrest-dev@xml.apache.org
Subject: Re: File prefix again (Re: Cocoon CLI - how to generate the whole
 site)
References: <3DFA0B7F.6050006@apache.org>
 <20021213170618.GC7718@expresso.localdomain>
 <20021216055750.GB1708@expresso.localdomain> <3DFD87E4.1090508@apache.org>
 <20021216120309.GA2355@expresso.localdomain> <3DFDCEC0.1060109@apache.org>
 <20021216142017.GC2355@expresso.localdomain> <3DFDEC75.1020700@apache.org>
 <20021217043902.GA1977@expresso.localdomain> <3DFF2FBD.5020601@apache.org>
 <20021217155222.GC8629@expresso.localdomain>
In-Reply-To: <20021217155222.GC8629@expresso.localdomain>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N



Jeff Turner wrote:
> On Tue, Dec 17, 2002 at 03:07:57PM +0100, Nicola Ken Barozzi wrote:
> 
>>Jeff Turner wrote:
>>
>>>On Mon, Dec 16, 2002 at 04:08:37PM +0100, Nicola Ken Barozzi wrote:

[...]

>>Static or generated there is no difference. The use should not even know 
>>if Cocoon does something with it.
> 
> Yes! +1000.  But first, the user needs to identify what "it" is.  Is "it"
> the PDF rendition of index.xml, or the index.pdf file sitting on my
> harddisk?  They are two different Sources, containing completely
> different content, and they deserve different Source URIs.

My point is that there should be just one "index" file, whatever 
extension it has.

>>This is important. This is why I say that you are mixing concerns.
> 
> Identifying the source is the user's concern.  That is the I in URI.  We
> have two different Sources, we need two different URIs.

Excactly the point. Me says that we can have only one source with the 
same name. I don't see the need of having two.

>>What if the sitemap guy would want to take the PDF and transform it; 
>>with the file: protocol you are making this not possible. You are taking 
>>away from the sitemap the possibility of doing what the heck it wants 
>>with the files.
> 
> I don't get this.  How can PDFs be transformed?

There are Java libraries that read PDFs. What would be really cool is to 
have a reader or something like it that uses a PDF as a template.
Using FOP for just filling out forms is overkill, we just need templating.

This is a general use case of PDF transformation, and another that I 
would really like to see is to generate a "non-controlled copy" stamp on 
the PDF for the management of ISO9001 documentation.

Or simply by adding a copyright statement.

[...]

>Imagine I have
>>
>> ./index.xml
>> ./index.pdf
>>
>>If I link like this
>>
>>  <link href="index"/>
>>
>>Cocoon serves only one, as defined in the sitemap rules.
>>
>>If I introduce the file: protocol, I can do:
>>
>>  <link href="index"/>           ->  serve index.xml
>>  <link href="site:index.pdf"/>  ->  serve index.pdf
>>
>>Problem is, how can the browser as for
>>
>>  http://domain.ext/path/to/index
>>
>>and have one or other result?
>>
>>What would the above URL yield?
> 
> 
> Excellent point :)  One I completely missed.  So you're saying that
> disambiguating 'cocoon:index.pdf' and 'file:index.pdf' is well and good,
> but it causes a name clash in the Destination URI space.
> 
> Simple enough answer: we need two create two destination URIs, because
> there are two Source URIs.  Eg, generate:
> 
> http://localhost:8888/index.pdf    # The static index.pdf
> http://localhost:8888/index~.pdf   # index.pdf generated from XML   
> 
> But this is an implementation detail.  What I'm concerned about now is
> whether disambiguating the sources makes sense _conceptually_.
> 
> So say we have two distinct Source URIs: a static index.pdf file, and the
> PDF rendition of index.xml.  In "ideal world" syntax, we can write those
> two as:
> 
> <link href="index.pdf">
> <link href="index.xml" type="application/pdf">
> 
> In "real world: Jeff style" syntax, they'd be written as:
> 
> <link href="file:index.pdf">
> <link href="index.pdf">
> 
> In "real world: Nicola style" syntax, there'd just be:
> 
> <link href="index.pdf">
> 
> and you simply can't have an index.pdf file.

Not exactly.
If you have index.xml, that becomes the index.pdf.
If you have index.pdf, that becomes the index.pdf.

One filename, one result.

> Firstly: do you agree that there _are_ two Sources?  That the user
> _could_ create an index.pdf?  In fact, considering that the user isn't
> meant to know that index.xml even *has* a PDF rendition, why shouldn't
> they create an index.pdf?

I don't agree here. The user creates documents to explain a concept. 
"index" means it's the index. Who cares what the rendition is.
Imagine the user making an index.xml and index.xhtml file in the same 
dir. Does it make sense?

> Secondly, do you agree that conceptually, any source of content should be
> assigned a Source URI?  _Regardless_ of whether it has a Destination URI?
> Because Source and Destination URI spaces have no direct relation.  Heck,
> I could generate a single PDF containing the entire site, thus mapping
> lots of Source URIs to a single Destination URI.

Yes, on this I agree. We should always link to source URIs, so that what 
you explain about a single PDF can be possible. And it's also easier for 
the user. +1

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------