You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2003/09/09 10:32:53 UTC
Re: Claiming *.html (Re: cvs commit: xml-forrest/src/resources/conf
forrest.xmap)
Jeff Turner wrote:
> 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.
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
content:
<site>
...
<salesreport href="sales.pdf" binary="true"/>
...
</site>
And then just have:
src/documentation/content/index.xml
src/documentation/content/sales.pdf
"
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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Claiming *.html (Re: cvs commit: xml-forrest/src/resources/conf
forrest.xmap)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Juan Jose Pablos wrote:
> Nicola Ken Barozzi wrote:
>
>> Jeff Turner wrote:
>>
>>> You take rants far too personally ;)
>>
>> Probably ;-)
>
> I think that is an Italian feature/bug :-)
For Italians it's a feature.
For me it's a bug ;-D
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Claiming *.html (Re: cvs commit: xml-forrest/src/resources/conf
forrest.xmap)
Posted by Juan Jose Pablos <ch...@che-che.com>.
Nicola Ken Barozzi wrote:
> Jeff Turner wrote:
>>
>> You take rants far too personally ;)
>
>
> Probably ;-)
>
I think that is an Italian feature/bug :-)
Re: Claiming *.html (Re: cvs commit: xml-forrest/src/resources/conf
forrest.xmap)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote:
> On Tue, Sep 09, 2003 at 02:44:35PM +0200, Nicola Ken Barozzi wrote:
>
>>Jeff Turner wrote:
> ...
>>>It wasn't. The desirability of being able to easily distinguish
>>>processed and unprocessed files is an afterthought.
>>
>>Ok, now I get it.
>>
>>Well, that's the reason why the previous proposal was about using two
>>directory trees, I'm still ok with that if you prefer.
>
> I don't know which is better.
Honestly, I don't know either, and both work for me.
> I just didn't want to potentially exclude
> one possibility.
ACK
> ...
>>>True, I don't get it. Translating presentational HTML into semantic
>>>docv12 seems completely backwards to me.
>>
>>HTML is not presentational. Part of it is, part isn't. docv12 was born
>>from html, and ebooks are based on semantical html.
>
> Okay, I'm fine with that. Perhaps we should think about the
> XHTML2-as-intermediate-format proposal some more? Wouldn't XHTML2
> provide a more natural foundation for a semantic-HTML source format than
> xdoc?
Probably yes. But this AFAIS does not preclude what I propose, it would
simply be a further evolutionary step.
>>>It wouldn't matter that I don't understand or use ihtml, but that
>>>you're forcing the issue by claiming *.html.
>>
>>I'm not claiming anything, Jeff, as I don't think that the extension
>>should tell Cocoon how to process the file anymore. This is exactly what
>>ithml and ehtml do.
>
> I don't yet understand how we can auto-detect arbitrary content types
> (esp. without namespaces or xsi:schemaType attrs), so I tend to be
> conservative when it comes to turfing out extensions.
All xml should have namespaces and schema definitions if we want to out
arbitrary content. With other sources, we would stick with one
processing mode.
>>Jeff, as I have already proposed, and now I ask you, please revert my
>>commits as I feel they were not appropriate.
>
> Thanks for doing so.
It was simply the right thing to do.
>>I would do so myself but cannot ATM. And again sorry if you felt
>>pushed, but I really am in good faith.
>
> You take rants far too personally ;)
Probably ;-)
But in fact it's not your rant (actually, did you rant at all?) but me
being a bit worried of having done another communication mess.
Oh well...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Claiming *.html (Re: cvs commit: xml-forrest/src/resources/conf forrest.xmap)
Posted by Jeff Turner <je...@apache.org>.
On Tue, Sep 09, 2003 at 02:44:35PM +0200, Nicola Ken Barozzi wrote:
> Jeff Turner wrote:
...
> >It wasn't. The desirability of being able to easily distinguish
> >processed and unprocessed files is an afterthought.
>
> Ok, now I get it.
>
> Well, that's the reason why the previous proposal was about using two
> directory trees, I'm still ok with that if you prefer.
I don't know which is better. I just didn't want to potentially exclude
one possibility.
...
> >True, I don't get it. Translating presentational HTML into semantic
> >docv12 seems completely backwards to me.
>
> HTML is not presentational. Part of it is, part isn't. docv12 was born
> from html, and ebooks are based on semantical html.
Okay, I'm fine with that. Perhaps we should think about the
XHTML2-as-intermediate-format proposal some more? Wouldn't XHTML2
provide a more natural foundation for a semantic-HTML source format than
xdoc?
> >It wouldn't matter that I don't understand or use ihtml, but that
> >you're forcing the issue by claiming *.html.
>
> I'm not claiming anything, Jeff, as I don't think that the extension
> should tell Cocoon how to process the file anymore. This is exactly what
> ithml and ehtml do.
I don't yet understand how we can auto-detect arbitrary content types
(esp. without namespaces or xsi:schemaType attrs), so I tend to be
conservative when it comes to turfing out extensions.
> Jeff, as I have already proposed, and now I ask you, please revert my
> commits as I feel they were not appropriate.
Thanks for doing so.
> I would do so myself but cannot ATM. And again sorry if you felt
> pushed, but I really am in good faith.
You take rants far too personally ;)
--Jeff
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
Re: Claiming *.html (Re: cvs commit: xml-forrest/src/resources/conf
forrest.xmap)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Nicola Ken Barozzi wrote:
...
> Jeff, as I have already proposed, and now I ask you, please revert my
> commits as I feel they were not appropriate. I would do so myself but
> cannot ATM.
Done.
>And again sorry if you felt pushed, but I really am in good
> faith.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Claiming *.html (Re: cvs commit: xml-forrest/src/resources/conf
forrest.xmap)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote:
> On Tue, Sep 09, 2003 at 10:32:53AM +0200, Nicola Ken Barozzi wrote:
>
>>Jeff Turner wrote:
...
>>You wrote:
>>"
>>Perhaps we could rather use marker attributes in site.xml to indicate raw
>>content:
>>
>><site>
>> ...
>> <salesreport href="sales.pdf" binary="true"/>
>> ...
>></site>
>>
>>And then just have:
>>
>>src/documentation/content/index.xml
>>src/documentation/content/sales.pdf
>>"
>>
>>I don't see how this is a proposal about matching extensions to
>>processing rules.
>
> It wasn't. The desirability of being able to easily distinguish
> processed and unprocessed files is an afterthought.
Ok, now I get it.
Well, that's the reason why the previous proposal was about using two
directory trees, I'm still ok with that if you prefer.
>>>>>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.
>
> I'm referring to the "namespaced content", as in multiple-namespaces.xml.
That is still *.xml as now.
Then .html refers only to real html files.
>>>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.
>
> True, I don't get it. Translating presentational HTML into semantic
> docv12 seems completely backwards to me.
HTML is not presentational. Part of it is, part isn't. docv12 was born
from html, and ebooks are based on semantical html.
> and utterly useless if you
> intend to strip out useful HTML features like forms.
In this regard, cwiki is useless too. It's just another source format.
If you won't use it, fine.
> It wouldn't matter
> that I don't understand or use ihtml, but that you're forcing the issue
> by claiming *.html.
I'm not claiming anything, Jeff, as I don't think that the extension
should tell Cocoon how to process the file anymore. This is exactly what
ithml and ehtml do.
I concede that I proposed it some time back as a compromise, but now I'd
like to go forward and make things better. Hence my initial asis
proposal, that became mixed-namespace stuff, and the proper separation
of directories.
> ...
>
>>But I really thought we had finally gotten to a decision on this :-/
>
> The last thread on this topic got waylaid by an <asis> tag. The core
> question (why ihtml) was never addressed.
I thought it was, also by other threads about source directories and such.
Jeff, as I have already proposed, and now I ask you, please revert my
commits as I feel they were not appropriate. I would do so myself but
cannot ATM. And again sorry if you felt pushed, but I really am in good
faith.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Claiming *.html (Re: cvs commit: xml-forrest/src/resources/conf forrest.xmap)
Posted by Jeff Turner <je...@apache.org>.
On Tue, Sep 09, 2003 at 10:32:53AM +0200, Nicola Ken Barozzi wrote:
> Jeff Turner wrote:
...
> >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
> content:
>
> <site>
> ...
> <salesreport href="sales.pdf" binary="true"/>
> ...
> </site>
>
> And then just have:
>
> src/documentation/content/index.xml
> src/documentation/content/sales.pdf
> "
>
> I don't see how this is a proposal about matching extensions to
> processing rules.
It wasn't. The desirability of being able to easily distinguish
processed and unprocessed files is an afterthought.
> >>>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.
I'm referring to the "namespaced content", as in multiple-namespaces.xml.
> >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.
True, I don't get it. Translating presentational HTML into semantic
docv12 seems completely backwards to me. and utterly useless if you
intend to strip out useful HTML features like forms. It wouldn't matter
that I don't understand or use ihtml, but that you're forcing the issue
by claiming *.html.
...
> But I really thought we had finally gotten to a decision on this :-/
The last thread on this topic got waylaid by an <asis> tag. The core
question (why ihtml) was never addressed.
--Jeff
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>