You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Gerard van Enk <ge...@eo.nl> on 2000/03/01 09:50:55 UTC
RE: [RT] Layout-driven vs. content-driven
> Gerard van Enk wrote:
> >
> > If I use XInclude for the layout template how will I be able to
> use frames,
> > because all the information is in one file? Or will it be a
> file with the
> > url's to the content?
>
> No, you use XINCLUDE in the stylesheet the produces your huge PDF or the
> one producing the non-framed version of your website, XLINK in the one
> that produces the framed one.
>
> The thought is taking shape. It depends on where the final "merging"
> should occour. If the final merging occours on the server side, you use
> XINCLUDE, if on the client side, XLINK...
I'm not sure if I understand what you're saying.
Is the following possible with Xlink/Xpointer? I'm not finished reading
everything from the Xlink/Xpointer documentation.......
1. There's a layout-template in which the layout is defined.
2. This template is merged with the content using Xinclude.
3. A stylesheet is applied to the merged file. This produces a frameset
which is sent to the browser. This frameset contains URIs which can be
translated by Cocoon into Xpointers. These Xpointers are pointers to parts
of the merged file (step 2).
4. At stylesheet is applied to the parts of the merged file pointed to by
the Xpointers. These are sent back to the browser.
Is this possible or am I talking nonsens?
Gerard
Re: [RT] Layout-driven vs. content-driven
Posted by Niclas Hedhman <ni...@localbar.com>.
Leventhal's arguments + excellent counter arguments by you guys, drive me to
summarize;
a) At the time of the writing, XSL was a mix of XTL and FOL (Stefano's abbrevs).
Most of the article is attacking FOL, only to a lesser degree XTL.
b) The choice of using XTL or programming at the server side is an individual
choice, and matter of preferences. Cocoon allows both to happen, to accommodate
for various requirements.
c) Server side genereated FOL rendering is a rather bad thing. A XML document + a
FOL stylesheet (possibly also some XTL?) should be processed at the client. It
will however take yet quite some time before we will see these clients emerge.
d) Interactive documents, so much celebrated in Mr Leventhal's article, is perhaps
not as common as people believe. Interactive documents are not, IMO, pages that
flashes, beeps and do something upon user action. But instead, where there is a
link maintained, somehow, from the original source document and the visual
presentation on the client. This is especially a case for non-browser clients,
which should be dealing with raw XML and an associated stylesheet. When the client
modifies the XML document, the rendering must opccur again, and if this is a 1 sec
process, it is not really acceptable. However, I believe this a bit peripheral to
the current developments on the web.
e) Whether XSL is a difficult languages or not, is very much personal preference.
I tend to think it is utterly complex, and almost impossible to get it to do what
I want (except simple things). But then again, I am trying hard stuff, and I am a
traditional programmer.
f) Mr Leventhal is advocating full adherence of clients to existing standards
prior to devulging into new ones, on the basis of "compatibility". This is a good
thing, and we will probably never see it happen, no matter how much we want. Today
it is just about impossible to make anything on the web to appear the same, at
pixel level, on the 2 dominating browsers or the latest version, let alone older
versions and the dozen or so more peripheral ones.
g) Mr Leventhal's adovacy for CSS is possibly derived from his disappointment of
compliance among the existing CSS1 capable browsers (Anyone tried :o) ?? ) and
he wants so much for CSS to work for him, and that's why he sees XSL as threat
that CSS will never be fully supported.
I conclude, Cocoon is not shutting the door for anyone, not even Mr Leventhal, at
the server side. You want programming languages instead of XTL, you got it. You
want CSS to be delivered to the client, you got it. The strength of Cocoon is its
ability to compensate for the client's capability, and clients with new and other
features, such as WAP, VRML and voice.
I believe we will see a few very interesting variations on how Cocoon is deployed,
today not contemplated.
I thank you all for your comments and angles. To some I agree, to some I don't,
but that is mostly personal preference.
Niclas
Re: [RT] Layout-driven vs. content-driven
Posted by Donald Ball <ba...@webslingerZ.com>.
On Fri, 3 Mar 2000, Niclas Hedhman wrote:
> Stefano Mazzocchi wrote:
>
> > FO is great, IMO, but it's a pain to learn from the spec... almost
> > impossible without visual descriptions of the formatting layout. But as
> > soon as you have visual tools for that... shees, have you seen the SVG
> > example with the Adobe SVG Viewer as Netscape plugin? no?
>
> I just read an article by Michael Leventhal
> (http://xml.com/pub/au/Leventhal_Michael) regarding XSL in general, and FO in
> particular.
>
> It is a bit old, but I think it is relevant in our context.
>
> http://xml.com/xml/pub/1999/05/xsl/xslconsidered_1.html
> (terribly slow site...)
>
> Sad(?) to say; he managed to convince me on a lot of points.
>
> The article put forward some challenges, and I would like to see what
> kind of arguments the Cocoon users/developers have to defend their
> choice, or have we all been blinded by a "XSL anti-pattern"??
I think we all agree that we need seperation of content and design. XML
gives us a data management layer, these articles are questioning the use
of XSLT as the data presentation layer. They seem to be advocating CSS and
client-side javascript as their alternative. That may well be a good
solution for some applications, but I prefer usually XSLT. Why?
1. XSLT is general - it allows you to transform XML into other XML or
HTML. CSS+javascript is fairly closely tied to the 2D graphical browser
window paradigm.
2. XSLT is XML. CSS is not. Is there any good reason to learn and use two
different syntaxes?
3. Clients are stupid and untrustworthy and will always lag years behind
the state of the art. You can do XSLT on the server side. I'm not aware of
any packages for applying CSS or positing elements with javascript on the
server side. Plus I hate having to kludge together client-specific
javascript to accomodate differing implementations over which I have no
control - it's ugly, dangerous, and not maintainable.
4. XSLT is a beautiful language. CSS+javascript isn't. (big IMHO of
course)
Note that the articles tend to confuse XSLT and XSL:FO, which is only to
be expected since they used to be stuck together. I think XSLT is the
deal, but I don't understand or particularly like XSL:FO.
- donald
Re: [RT] Layout-driven vs. content-driven
Posted by Mike Engelhart <me...@earthtrip.com>.
Niclas Hedhman wrote:
>
> I just read an article by Michael Leventhal
> (http://xml.com/pub/au/Leventhal_Michael) regarding XSL in general, and FO in
> particular.
>
> It is a bit old, but I think it is relevant in our context.
>
> http://xml.com/xml/pub/1999/05/xsl/xslconsidered_1.html
> (terribly slow site...)
>
> Sad(?) to say; he managed to convince me on a lot of points.
>
> The article put forward some challenges, and I would like to see what kind of
> arguments the Cocoon users/developers have to defend their choice, or have we
> all
> been blinded by a "XSL anti-pattern"??
>
> I realize there is great risk of flames in this subject, BUT any comments?
>
> Niclas
I read the first page of the article and gave up. First of all it is very
out of date (1 year old exactly). Second the author is talking about
client-side XSL transformation vs. client-side transformation using CSS
which has nothing (at this point) to do with Cocoon or the Cocoon process of
site development/publishing. His points were not convincing at all from the
start. Anyone who has attempted in even the smallest way to implement a
site relying on client side transformation even using the latest browsers
realizes that doing this creating a world of pain for themselves. Writing a
shitload of javascript to do simple formatting for the multitude of browsers
out there is a complete waste of time. I still think XSLT and Cocoon have
some difficult aspects and I plan on writing a summary of these once I
finish my site but on the whole it is the single best model for site
development that uses w3c standards (and - bonus - OSS) that I have come
across in my several years of web development.
What the crap is an anti-pattern anyway???
Re: [RT] Layout-driven vs. content-driven
Posted by Niclas Hedhman <ni...@localbar.com>.
Stefano Mazzocchi wrote:
> FO is great, IMO, but it's a pain to learn from the spec... almost
> impossible without visual descriptions of the formatting layout. But as
> soon as you have visual tools for that... shees, have you seen the SVG
> example with the Adobe SVG Viewer as Netscape plugin? no?
I just read an article by Michael Leventhal
(http://xml.com/pub/au/Leventhal_Michael) regarding XSL in general, and FO in
particular.
It is a bit old, but I think it is relevant in our context.
http://xml.com/xml/pub/1999/05/xsl/xslconsidered_1.html
(terribly slow site...)
Sad(?) to say; he managed to convince me on a lot of points.
The article put forward some challenges, and I would like to see what kind of
arguments the Cocoon users/developers have to defend their choice, or have we all
been blinded by a "XSL anti-pattern"??
I realize there is great risk of flames in this subject, BUT any comments?
Niclas
RE: [RT] Layout-driven vs. content-driven
Posted by Gerard van Enk <ge...@eo.nl>.
On Thu, 2 Mar 2000, Gerard van Enk wrote:
>
> > > > But how do I define if it's becoming a merged file or a frameset?
> > >
> > > the sitemap will tell.
> >
> > By using the xinclude or the xlink filter?
> >
> No, the xkitchensink filter takes care of this I believe.
>
> Gurgle,
>
??
RE: [RT] Layout-driven vs. content-driven
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Thu, 2 Mar 2000, Gerard van Enk wrote:
> > > But how do I define if it's becoming a merged file or a frameset?
> >
> > the sitemap will tell.
>
> By using the xinclude or the xlink filter?
>
No, the xkitchensink filter takes care of this I believe.
Gurgle,
Dw
RE: [RT] Layout-driven vs. content-driven
Posted by Gerard van Enk <ge...@eo.nl>.
> > But how do I define if it's becoming a merged file or a frameset?
>
> the sitemap will tell.
By using the xinclude or the xlink filter?
>
> > I thought this is done by a serializer?
>
> It was an example. You can also transform FO into HTML using XSLT or
> your own magic filter.
>
> > I'd like to use the same file for the html or the pdf.
>
> Sure, then you need lots of serialization logic. Don't get me wrong, I
> do believe in this approach as the winner one in the long term... but
> right now there are many simpler solution and using the direct layout ->
> HTML frameset transformation is the simplest one by far :)
>
Ok, for now we'll go for the simplest solution 8-)
> > But isn't the choice between frames or tables something that
> must be done in
> > the last stage of the processing?
>
> oh, if you want to have that choice, yes, totally.
>
> > I'm happy with the solution of doing it somewhere in the middle of the
> > processing chain.......but I thought this was something for the
> > serializing.....It's clear I don't understand it as good as I
> thought I did
> > 8-(
>
> No, you got it right. Simply don't forget that there is no only one way
> of doing things. Not many (I'm not a great fan of PERL reasoning), but a
> few.
>
That's true, I like to keep things simple, that's why I'm programming Java
instead of Perl..........
> Of course, our goal is to make sure that you are not forced to use the
> best one, but you do it by yourself. But this takes both time to develop
> the software and time for the standards to stability and get digested by
> the community.
>
> FO is great, IMO, but it's a pain to learn from the spec... almost
> impossible without visual descriptions of the formatting layout. But as
> soon as you have visual tools for that... shees, have you seen the SVG
> example with the Adobe SVG Viewer as Netscape plugin? no?
>
> Well go www.adobe.com/svg/ and find out. You MUST go there NOW to
> understand what I really mean.
ok, ok....I'll check it out 8-)
Gerard
Re: [RT] Layout-driven vs. content-driven
Posted by Stefano Mazzocchi <st...@apache.org>.
Gerard van Enk wrote:
>
> > > > The thought is taking shape. It depends on where the final "merging"
> > > > should occour. If the final merging occours on the server
> > side, you use
> > > > XINCLUDE, if on the client side, XLINK...
> > >
> > > I'm not sure if I understand what you're saying.
> > >
> > > Is the following possible with Xlink/Xpointer? I'm not finished reading
> > > everything from the Xlink/Xpointer documentation.......
> > >
> > > 1. There's a layout-template in which the layout is defined.
> > > 2. This template is merged with the content using Xinclude.
> > > 3. A stylesheet is applied to the merged file. This produces a frameset
> > > which is sent to the browser. This frameset contains URIs which can be
> > > translated by Cocoon into Xpointers. These Xpointers are
> > pointers to parts
> > > of the merged file (step 2).
> >
> > Why so? In case of HTML frames, the layout is simply translated into a
> > frameset and the URIs are translated. It will be the browser to call the
> > URIs. No need to mess around with XInclude or XPointers if you don't
> > need to "merge" it.
>
> But how do I define if it's becoming a merged file or a frameset?
the sitemap will tell.
> I thought this is done by a serializer?
It was an example. You can also transform FO into HTML using XSLT or
your own magic filter.
> I'd like to use the same file for the html or the pdf.
Sure, then you need lots of serialization logic. Don't get me wrong, I
do believe in this approach as the winner one in the long term... but
right now there are many simpler solution and using the direct layout ->
HTML frameset transformation is the simplest one by far :)
>
> >
> > > 4. At stylesheet is applied to the parts of the merged file
> > pointed to by
> > > the Xpointers. These are sent back to the browser.
> > >
> > > Is this possible or am I talking nonsens?
> >
> > Sure it is, but what's the point? You get the same functionality anyway.
> > I'm probably missing something.
> >
> > The XInclude part is done in case you want the layout to be rendered as
> > tables. Then you _need_ to include all the pieces into one, but the
> > browser is unaware of what's going on to generate the page. As it should
> > always be.
>
> But isn't the choice between frames or tables something that must be done in
> the last stage of the processing?
oh, if you want to have that choice, yes, totally.
> I'm happy with the solution of doing it somewhere in the middle of the
> processing chain.......but I thought this was something for the
> serializing.....It's clear I don't understand it as good as I thought I did
> 8-(
No, you got it right. Simply don't forget that there is no only one way
of doing things. Not many (I'm not a great fan of PERL reasoning), but a
few.
Of course, our goal is to make sure that you are not forced to use the
best one, but you do it by yourself. But this takes both time to develop
the software and time for the standards to stability and get digested by
the community.
FO is great, IMO, but it's a pain to learn from the spec... almost
impossible without visual descriptions of the formatting layout. But as
soon as you have visual tools for that... shees, have you seen the SVG
example with the Adobe SVG Viewer as Netscape plugin? no?
Well go www.adobe.com/svg/ and find out. You MUST go there NOW to
understand what I really mean.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
RE: [RT] Layout-driven vs. content-driven
Posted by Gerard van Enk <ge...@eo.nl>.
> > > The thought is taking shape. It depends on where the final "merging"
> > > should occour. If the final merging occours on the server
> side, you use
> > > XINCLUDE, if on the client side, XLINK...
> >
> > I'm not sure if I understand what you're saying.
> >
> > Is the following possible with Xlink/Xpointer? I'm not finished reading
> > everything from the Xlink/Xpointer documentation.......
> >
> > 1. There's a layout-template in which the layout is defined.
> > 2. This template is merged with the content using Xinclude.
> > 3. A stylesheet is applied to the merged file. This produces a frameset
> > which is sent to the browser. This frameset contains URIs which can be
> > translated by Cocoon into Xpointers. These Xpointers are
> pointers to parts
> > of the merged file (step 2).
>
> Why so? In case of HTML frames, the layout is simply translated into a
> frameset and the URIs are translated. It will be the browser to call the
> URIs. No need to mess around with XInclude or XPointers if you don't
> need to "merge" it.
But how do I define if it's becoming a merged file or a frameset? I thought
this is done by a serializer? I'd like to use the same file for the html or
the pdf.
>
> > 4. At stylesheet is applied to the parts of the merged file
> pointed to by
> > the Xpointers. These are sent back to the browser.
> >
> > Is this possible or am I talking nonsens?
>
> Sure it is, but what's the point? You get the same functionality anyway.
> I'm probably missing something.
>
> The XInclude part is done in case you want the layout to be rendered as
> tables. Then you _need_ to include all the pieces into one, but the
> browser is unaware of what's going on to generate the page. As it should
> always be.
But isn't the choice between frames or tables something that must be done in
the last stage of the processing?
I'm happy with the solution of doing it somewhere in the middle of the
processing chain.......but I thought this was something for the
serializing.....It's clear I don't understand it as good as I thought I did
8-(
Gerard
Re: [RT] Layout-driven vs. content-driven
Posted by Stefano Mazzocchi <st...@apache.org>.
Gerard van Enk wrote:
>
> > Gerard van Enk wrote:
> > >
> > > If I use XInclude for the layout template how will I be able to
> > use frames,
> > > because all the information is in one file? Or will it be a
> > file with the
> > > url's to the content?
> >
> > No, you use XINCLUDE in the stylesheet the produces your huge PDF or the
> > one producing the non-framed version of your website, XLINK in the one
> > that produces the framed one.
> >
> > The thought is taking shape. It depends on where the final "merging"
> > should occour. If the final merging occours on the server side, you use
> > XINCLUDE, if on the client side, XLINK...
>
> I'm not sure if I understand what you're saying.
>
> Is the following possible with Xlink/Xpointer? I'm not finished reading
> everything from the Xlink/Xpointer documentation.......
>
> 1. There's a layout-template in which the layout is defined.
> 2. This template is merged with the content using Xinclude.
> 3. A stylesheet is applied to the merged file. This produces a frameset
> which is sent to the browser. This frameset contains URIs which can be
> translated by Cocoon into Xpointers. These Xpointers are pointers to parts
> of the merged file (step 2).
Why so? In case of HTML frames, the layout is simply translated into a
frameset and the URIs are translated. It will be the browser to call the
URIs. No need to mess around with XInclude or XPointers if you don't
need to "merge" it.
> 4. At stylesheet is applied to the parts of the merged file pointed to by
> the Xpointers. These are sent back to the browser.
>
> Is this possible or am I talking nonsens?
Sure it is, but what's the point? You get the same functionality anyway.
I'm probably missing something.
The XInclude part is done in case you want the layout to be rendered as
tables. Then you _need_ to include all the pieces into one, but the
browser is unaware of what's going on to generate the page. As it should
always be.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------