forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <je...@apache.org>
Subject Re: Claiming *.html (Re: cvs commit: xml-forrest/src/resources/conf forrest.xmap)
Date Mon, 08 Sep 2003 22:49:09 GMT
Nicola Ken Barozzi wrote:
> Jeff Turner wrote:
> 
>> On Mon, Sep 08, 2003 at 06:27:05AM -0000, nicolaken@apache.org wrote:
>>
>>> nicolaken    2003/09/07 23:27:05
>>>
>>>  Modified:    src/resources/conf forrest.xmap
>>>  Log:
>>>  Add .html matcher as new way of defining ihtml pages.
>>
>>
>> What happens if in 0.6, we decide to have a fully unified filesystem
>> layout, where extension is the only way of differentiating raw and parsed
>> content?
>>
>> That is more or less what I proposed in this thread:
>>
>> http://marc.theaimsgroup.com/?t=105886875300001&r=1&w=2
>>
>> And you agreed that it was a superset of the previously proposed
>> solution, that of having a raw/ directory:
>>
>> http://marc.theaimsgroup.com/?l=forrest-dev&m=105894150226944&w=2
> 
> 
> Wait a sec, AFAIU it's not the extension that defines binary or not, but 
> an attribute in site.xml.
> 
> You wrote:
>  > Well we can make binary=true an inheritable attribute then:
>  >
>  >   <apidocs binary="true">
>  >     ...
>  >   </apidocs>

I was thinking that although it's *possible* to have foo.html and 
bar.html treated differently, it would be pretty confusing for users. 
The extension provides a nice simple filetype marker.  As an analogy, 
modern filesystems don't *rely* on extensions for identifying file type, 
but people use them anyway, as a visual type indicator.

>> I don't want to limit our options in 0.6 for the minimal advantage of
>> making *.ihtml easier to edit.  So claim *.html if you want, but be aware
>> that it may be redefined in 0.6.
> 
> 
> I thought that we had agreed on this, Jeff, and I thought that this 
> commit was in line with what we had decided.
> 
> IE:
>  - Add .html matcher as new way of defining ihtml pages
>  - Make namespaced content pass the pipeline (so we can add xhtml things
>    to xdoc pages for special cases, as like ehtml)
>  - deprecate ihtml and ehtml

I'm not sure how processing *.html as ihtml counts as a first step down 
this road of supporting mixed-namespace documents.  For a start, '.html' 
is the wrong extension, as it's XML, not HTML.  Wouldn't it be better to 
graft HTML support onto doc-v12 instead of docv12 onto HTML?

> I'd add now:
>  - add a class attribute to all tags
>  - add a user.css stylesheet so that users can easily change styles or
>    attach new things to class attribute meanings

Great, but AFACT that's completely independent of ihtml, right?

> Do you have other ideas now?
> 
> I'm ok with rediscussing if you have other idea, just wanted to note 
> that I did this commit because I thought it was in line with the 
> decisions taken, not because I want to force things my way.

Cool, just misunderstandings.  It's been 7 months since 0.4, so I just 
want to get 0.5 out before we break some kind of ASF record for slackness ;)

--Jeff



Mime
View raw message