forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: Claiming *.html (Re: cvs commit: xml-forrest/src/resources/conf forrest.xmap)
Date Tue, 09 Sep 2003 08:32:53 GMT
Jeff Turner wrote:
> Nicola Ken Barozzi wrote:
>> Jeff Turner wrote:
>>> On Mon, Sep 08, 2003 at 06:27:05AM -0000, 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:
>>> And you agreed that it was a superset of the previously proposed
>>> solution, that of having a raw/ directory:
>> 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.

Well then that's not what I had understood. I reread the thread and I 
still don't see this.

You wrote:
Perhaps we could rather use marker attributes in site.xml to indicate raw

   <salesreport href="sales.pdf" binary="true"/>

And then just have:


I don't see how this is a proposal about matching extensions to 
processing rules.

>>> 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.  

Nope. It's html.

> Wouldn't it be better to 
> graft HTML support onto doc-v12 instead of docv12 onto HTML?

I think you don't get it. Html is just another *source* format that gets 
transformed in xdoc. It will *not* output extra facilities that doc-v12 
doesn't have.

html and cwiki have the same purpose, to be an alternative source format 
for document-dtd. I had posted a big drawing about it.

>> 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?

Yes, but related to the need of users to inject extra stuff in the docs.

>> 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 ;)

I don't want to delay the release in discussions. If you don't want to 
see this done now, feel free to revert, release and then rediscuss.

But I really thought we had finally gotten to a decision on this :-/

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message