forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [VOTE] Usage of file.hint.ext convention
Date Mon, 02 Sep 2002 11:55:04 GMT
<snip />

>> > convention, and keep it also in the output of the files.
>>+0 on source files, -1 on URIs
>> > We should always make ext as the *target* or the *source* 
>> > so that it becomes natural to link for users. Seeing mypage.xml and
>> > having to link to mypage.html has confused many already.
>> >
>> > It could be mypage.html or mypage.xml, but links and filenames need
>> > to be the same.
> IMO, the URI should indicate the output format and that's why usually *.html
> is used in pipelines instead of XML or so, even the source is XML. 
> So, I'm with Steven on this: -1 on URIs, as for the source files - that can
> use any naming format that is needed, so +0.

Steven knows this, to the rest: I have the same unease to doing 
this... but I don't call 'unease' an argument :-(

On the other side is this concern Steven brought under my 
attention: if we mess the URL up now, we will remain with those 
.hint. for ages... (so let us make sure we *really* want it)

What we look for is finding out how to style any-dtd up to some 
intermediate pre-skin format
- content-aware-pipelines say the DOCTYPE should tell us
- but probably the URI should tell us something aswell, no?

what if the pdf is not to be produced over fop, but is just a pdf 
file -resource that comes with the doc ?
==> if the answer is in the ResourceExistAction then the 
consequence will be that each extension-less file-name needs to 
be unique in a particular directory... so if I have a topic.xml 
file with an inline topic.gif and a referenced topic.pdf.... then 
to make sure we can distinct between what we really want, you 
will require the end-user to make unique filenames like 
topic-referingdocument.pdf topic-drawing.gif... compared to this 
I think dash could be dot, no?)

<snip />

> The document URL can be indication of the DTD. You can use:
> /my-dtd/doc.html to process one kind of documents
> /other-dtd/doc.html to process the other kind
> What's wrong with it?

it is not how the document editor works on his docs IMHO
look into your own harddrive: each of the dirs there has docs of 
various types cluttered together

organization into directories is done to my feeling based upon 
the following chain of concerns
- first:  access/management requirements (owner relationship)
- second: topic relationship
- never:  file type consistency

I think readable/hackable URL's should borrow at least the 
'organize' by topic idea...

>>I'm vigourously opposing the idea of encoding 
>>meta-information twice and 
>>in different places: inside the document, using its filename, 
>>and in the 
>>request URI.
> I think that the only indication of the document type should be the URI and
it is already in the file itself (DOCTYPE), the duplication 
inside the URI is exactly what the hints-discussion is about.

> not the filename. We can use any complex URIs for document handling, e.g.:
it is not in the filename (of the source) it is only in the URI, 
and thus through cocoon CLI in the filenames of the result

> /faq/*.html, /index.html, /docs/primer.html[1], etc. The URI prefix can
this choice is purely between:

/hint/**.rendering-type  and

The fun thing about the latter is that you keep up the leading 
part of the URI for e.g. pointing to different content-parts 
(like now we only serve what is inside ./content/xdocs)

> define the processing pipeline for a particular document type, the extension
> of the doc will indicate the output format and at last some additional
> information can come from the postfix - [1] in this case is the page number.
don't know how [] is doing in saved filenames after the static 
generation process, also don't know if webservers that need to 
publish afterwards will know how to make up the mime-type for those.

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center                    

View raw message