forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: [VOTE] Usage of file.hint.ext convention
Date Mon, 02 Sep 2002 12:51:16 GMT


Steven Noels wrote:
> Nicola Ken Barozzi wrote:
> 
> <snip/>
> 
>>> But it requires the docwriter to think about the management concern, 
>>> IMO.
>>
>>
>>
>> They still write mydoc.xml or mydoc.gif, no?
>> This isn't a management concern, no?
> 
> 
> No, that's the way silly OS'es bind editing apps to filetypes. On Unix 
> and Mac OS, this has been solved in a more robust way, IMHO 
> (/etc/mime-magic and Resource Forks).
> 

I see this more as a management contract to obey then a 
management concern taken up.
The content-editor is expected to give his document a filename 
(incl extension) by which the rest of the world can address it 
(pick it up later on)

>>> I'm still thinking about those content-aware pipelines, and for some 
>>> app we are developing, we actually have been using this technique 
>>> doing a XML Pull Parse on the document to check its root element - 
>>> here, we could check for its DTD identifier.
>>
>>
>>
>> It's neat, but a PITA for many users.
> 
> 
> Howcome? Using CAPs (content-aware pipelines), the system decides what 
> will be done with their XML files, depending on the editing grammar they 
> used.
> 

yep, this surely sounds easier from an end-user perspective
however, it will need some config file somewhere that explains 
which xslt or pipeline to use based on the recoginsed content.

(also note that 'content-aware' is more then doctype-aware.)

>>> 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.
>>
>> Conceptually I agree, the hint is a "hack".
> 
> Yes.
> 

it is also a solution ;-)

<snip />

>> Users that want to write a generic document use that dtd.
>> All other content that must be "skinned" by forrest must be 
>> pregenerated by other tools to give that dtd.
> 
> 
> +1
> 
? we are not saying that two step view means that the first step 
is done with ant-style-tasks is it?
"pre-generated" I also like to read as have a pipeline for it.
as for:

>> We still have status.xml... etc files that get automatically 
>> transformed to that format.
> 
> 
> Yep - and I like that.

And we should allow for more of these, including user-defined ones.
I mean: solve this in the URI design for our own future types, 
and make it available as well.

<snip />

> 
>> The point is, can we use them in statically generated documentation?
>>
>> We cannot.  :-/
> 

I know I made a similar statement on this earlier, however been 
thinking along these lines:

> 
> I fail to see why, but I might be stuborn ;-)
> 

someone should maybe just check...
I think the static generation process of cocoon would
- in case it finds a link of the kind 
href="addressing-part/name.rendering-type?hint=source-type"

- just save the resulting file under name.rendering-type
- currently the serializer would leave the jucky 
?hint=source-type in the href, but the webserver we put it on 
would survive that anyways (since it is not going to take the 
parameter in account for delivering static content)

In future it would be nice if the CLI version would remove the 
?-trailer on none http://-leading URI's though,

by the way Nicola: the CLI should also be the one that 
"relativizes" all the none http://-leading hrefs in our generated 
html as well :-D
that is the correct way to produce a bunch of relative 
interconnected pages that can be placed where-ever (not just in 
the /forrest) on a webserver. (and detaches the solution from the 
webapp that doesn't have this concern)

<snip/>

-marc
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
mpo@outerthought.org                              mpo@apache.org



Mime
View raw message