You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@lenya.apache.org by Garry Howze <gl...@comcast.net> on 2005/07/20 02:59:10 UTC

Lenya new user (confused)

I'm researching about half a dozen CMS's for a project, and thought I 
had found my answer with Lenya. I thought I could use xml for my source 
documents (content), and xsl/xslt for transformation (presentation), but 
I keep seeing references to CSS's, and sometimes scripting languages. In 
fact, Lenya doc's say, "as much as possible we use css's for 
presentation". I thought xslt was an improvement over CSS's. Why have 
xslt available and then use CSS's?  Is it that you can't do 
"presentation" with xslt? I'm guessing there must be a reason to use 
CSS's. Can someone give me a quick overview of why CSS's are necessary?

glhowze

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org


Re: Lenya new user (confused)

Posted by Ron Wheeler <rw...@artifact-software.com>.
Looks good.

Andreas Hartmann wrote:

> Ron Wheeler wrote:
>
>> Does this appear in the wiki or documentation?
>> It is a very nice description of the rational behind the toolset .
>> Perhaps it could be enhanced over time with some examples or graphics 
>> but it is a nicely written starting point.
>
>
> I added it to the Wiki:
> http://wiki.apache.org/lenya/OverviewTechnologies
>
> -- Andreas
>
>>
>> Ron
>>
>>
>> Andreas Hartmann wrote:
>>
>>> Garry Howze wrote:
>>>
>>>> Thanks to Jon for the informative overview, and to Lee for the 
>>>> csszengarden link. Both were very helpful. But I'm still puzzled 
>>>> about a few things. Please bear with me. I'm just trying to 
>>>> understand the Lenya approach.
>>>>
>>>> Is it fair to say that xml/xsl/xslt/xsl-fo was conceived as a sort 
>>>> of "grand solution" to the problem of separation of content, logic 
>>>> and presentation, with xml for content, xsl for stylesheets, xslt 
>>>> for transformations and xsl-fo for presentation? If so, it appears 
>>>> to be a very good solution. XML is touted as probably the best 
>>>> overall format for content, and is used extensively. XSLT would 
>>>> transform that content to html/xhtml. That leaves XSL and XSL-FO. 
>>>> So I'm left wondering why isn't xsl (eXtensionable Stylesheet 
>>>> Language, it even has stylesheet language in its name!) used for 
>>>> stylesheets instead of CSS? Then I read that browsers aren't able 
>>>> to handle xsl-fo. Is that the crux of the problem?
>>>
>>>
>>>
>>>
>>> Just a short hint:
>>>
>>> XSL comprises
>>>  - XSLT (transform XML into something else, e.g. other XML)
>>>  - XSL-FO (page layout description language, comparable perhaps to 
>>> postscript)
>>>
>>> XSLT has a much bigger scope than just presentation issues. It is not
>>> a layout language, it's a processing (transformation) programming 
>>> language.
>>> XSLT itself cannot express any layout information.
>>>
>>> Why shouldn't XSLT be used for web-based presentation?
>>>
>>> A key issue is the separation between semantics and presentation, 
>>> which should
>>> even be available at the client side (browser), for instance for 
>>> accessibility
>>> reasons. To the user agent, a clean, semantic form of the content 
>>> must exist
>>> to allow custom presentation options (like screen readers - JAWS - ,
>>> a print version, ...). Otherwise, all these presentation options 
>>> would have
>>> to be provided by the server (CMS) and wouldn't be customizable and 
>>> extensible
>>> on the client side.
>>>
>>> In your XML-based application, you usually have other structures which
>>> are based on your domain (medicine, mathematics, music, ...). These 
>>> structures
>>> are necessary to hold all semantic information of your domain. But 
>>> on the
>>> client side, we need a standardized structure which can be 
>>> understood by all
>>> user agents (browsers). That's what XHTML is about - it's a 
>>> standardized
>>> language to express sequential, structured content.
>>>
>>> XSLT is the technology to transform your domain oriented content 
>>> into the
>>> standardized XHTML content.
>>>
>>> XSLT could also be used for different client-side presentation options
>>> (like print views, multiple or single column layouts, ...), but this
>>> has some drawbacks:
>>>
>>> - not all browsers support client-side XSLT
>>> - XSLT is much more complex than CSS (more flexibility is necessary)
>>> - XSLT is much harder to learn
>>> - another complex standardized presentation format would be required,
>>>   which would be the target format of the XSLT transformation
>>>   (at the moment this is HTML with style markup in most cases)
>>>
>>> XSL-FO is the weapon of choice when printable pages are required.
>>> It is extremely powerful, especially in combination with SVG you can
>>> implement amazingly complex designs. It is much more flexible than
>>> CSS for print views, but also much harder to learn and much more
>>> verbose.
>>>
>>> CSS is the weapon of choice for styling XML (e.g., XHTML) and SVG
>>> for simple, flexible applications (like web pages).
>>>
>>> See also http://www.xml.com/pub/a/2000/03/08/style/
>>>
>>>
>>>> That xml/xsl/xslt/xsl-fo is the optimal solution, but browsers just 
>>>> aren't ready for it?
>>>> And CSS's are used instead because browsers do understand CSS?
>>>
>>>
>>>
>>>
>>> No, CSS isn't outdated at all - quite the contrary :)
>>>
>>>
>>>> And finally, if tomorrow all major browsers were able to understand 
>>>> xml/xsl/xslt/xsl-fo would there be a need for Cocoon,
>>>
>>>
>>>
>>>
>>> Sure, there's much more about Cocoon than applying XSLTs to XML 
>>> documents.
>>> It is a framework for building web applications.
>>>
>>>> and would Lenya (without Cocoon) become almost like a front-end for 
>>>> xml/xsl/xslt/xsl-fo?
>>>
>>>
>>>
>>>
>>> I don't think so, Lenya is a framework for building content management
>>> solutions. A "front end for XML" I would call an editor (like BXE or
>>> XMLSpy), which would communicate with Lenya to store content.
>>>
>>> -- Andreas
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
>>> For additional commands, e-mail: user-help@lenya.apache.org
>>>
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
> For additional commands, e-mail: user-help@lenya.apache.org
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org


Re: Lenya new user (confused)

Posted by Andreas Hartmann <an...@apache.org>.
Ron Wheeler wrote:
> Does this appear in the wiki or documentation?
> It is a very nice description of the rational behind the toolset .
> Perhaps it could be enhanced over time with some examples or graphics 
> but it is a nicely written starting point.

I added it to the Wiki:
http://wiki.apache.org/lenya/OverviewTechnologies

-- Andreas

> 
> Ron
> 
> 
> Andreas Hartmann wrote:
> 
>> Garry Howze wrote:
>>
>>> Thanks to Jon for the informative overview, and to Lee for the 
>>> csszengarden link. Both were very helpful. But I'm still puzzled 
>>> about a few things. Please bear with me. I'm just trying to 
>>> understand the Lenya approach.
>>>
>>> Is it fair to say that xml/xsl/xslt/xsl-fo was conceived as a sort of 
>>> "grand solution" to the problem of separation of content, logic and 
>>> presentation, with xml for content, xsl for stylesheets, xslt for 
>>> transformations and xsl-fo for presentation? If so, it appears to be 
>>> a very good solution. XML is touted as probably the best overall 
>>> format for content, and is used extensively. XSLT would transform 
>>> that content to html/xhtml. That leaves XSL and XSL-FO. So I'm left 
>>> wondering why isn't xsl (eXtensionable Stylesheet Language, it even 
>>> has stylesheet language in its name!) used for stylesheets instead of 
>>> CSS? Then I read that browsers aren't able to handle xsl-fo. Is that 
>>> the crux of the problem?
>>
>>
>>
>> Just a short hint:
>>
>> XSL comprises
>>  - XSLT (transform XML into something else, e.g. other XML)
>>  - XSL-FO (page layout description language, comparable perhaps to 
>> postscript)
>>
>> XSLT has a much bigger scope than just presentation issues. It is not
>> a layout language, it's a processing (transformation) programming 
>> language.
>> XSLT itself cannot express any layout information.
>>
>> Why shouldn't XSLT be used for web-based presentation?
>>
>> A key issue is the separation between semantics and presentation, 
>> which should
>> even be available at the client side (browser), for instance for 
>> accessibility
>> reasons. To the user agent, a clean, semantic form of the content must 
>> exist
>> to allow custom presentation options (like screen readers - JAWS - ,
>> a print version, ...). Otherwise, all these presentation options would 
>> have
>> to be provided by the server (CMS) and wouldn't be customizable and 
>> extensible
>> on the client side.
>>
>> In your XML-based application, you usually have other structures which
>> are based on your domain (medicine, mathematics, music, ...). These 
>> structures
>> are necessary to hold all semantic information of your domain. But on the
>> client side, we need a standardized structure which can be understood 
>> by all
>> user agents (browsers). That's what XHTML is about - it's a standardized
>> language to express sequential, structured content.
>>
>> XSLT is the technology to transform your domain oriented content into the
>> standardized XHTML content.
>>
>> XSLT could also be used for different client-side presentation options
>> (like print views, multiple or single column layouts, ...), but this
>> has some drawbacks:
>>
>> - not all browsers support client-side XSLT
>> - XSLT is much more complex than CSS (more flexibility is necessary)
>> - XSLT is much harder to learn
>> - another complex standardized presentation format would be required,
>>   which would be the target format of the XSLT transformation
>>   (at the moment this is HTML with style markup in most cases)
>>
>> XSL-FO is the weapon of choice when printable pages are required.
>> It is extremely powerful, especially in combination with SVG you can
>> implement amazingly complex designs. It is much more flexible than
>> CSS for print views, but also much harder to learn and much more
>> verbose.
>>
>> CSS is the weapon of choice for styling XML (e.g., XHTML) and SVG
>> for simple, flexible applications (like web pages).
>>
>> See also http://www.xml.com/pub/a/2000/03/08/style/
>>
>>
>>> That xml/xsl/xslt/xsl-fo is the optimal solution, but browsers just 
>>> aren't ready for it?
>>> And CSS's are used instead because browsers do understand CSS?
>>
>>
>>
>> No, CSS isn't outdated at all - quite the contrary :)
>>
>>
>>> And finally, if tomorrow all major browsers were able to understand 
>>> xml/xsl/xslt/xsl-fo would there be a need for Cocoon,
>>
>>
>>
>> Sure, there's much more about Cocoon than applying XSLTs to XML 
>> documents.
>> It is a framework for building web applications.
>>
>>> and would Lenya (without Cocoon) become almost like a front-end for 
>>> xml/xsl/xslt/xsl-fo?
>>
>>
>>
>> I don't think so, Lenya is a framework for building content management
>> solutions. A "front end for XML" I would call an editor (like BXE or
>> XMLSpy), which would communicate with Lenya to store content.
>>
>> -- Andreas
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
>> For additional commands, e-mail: user-help@lenya.apache.org
>>
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org


Re: Lenya new user (confused)

Posted by Ron Wheeler <rw...@artifact-software.com>.
Does this appear in the wiki or documentation?
It is a very nice description of the rational behind the toolset .
Perhaps it could be enhanced over time with some examples or graphics 
but it is a nicely written starting point.

Ron


Andreas Hartmann wrote:

> Garry Howze wrote:
>
>> Thanks to Jon for the informative overview, and to Lee for the 
>> csszengarden link. Both were very helpful. But I'm still puzzled 
>> about a few things. Please bear with me. I'm just trying to 
>> understand the Lenya approach.
>>
>> Is it fair to say that xml/xsl/xslt/xsl-fo was conceived as a sort of 
>> "grand solution" to the problem of separation of content, logic and 
>> presentation, with xml for content, xsl for stylesheets, xslt for 
>> transformations and xsl-fo for presentation? If so, it appears to be 
>> a very good solution. XML is touted as probably the best overall 
>> format for content, and is used extensively. XSLT would transform 
>> that content to html/xhtml. That leaves XSL and XSL-FO. So I'm left 
>> wondering why isn't xsl (eXtensionable Stylesheet Language, it even 
>> has stylesheet language in its name!) used for stylesheets instead of 
>> CSS? Then I read that browsers aren't able to handle xsl-fo. Is that 
>> the crux of the problem?
>
>
> Just a short hint:
>
> XSL comprises
>  - XSLT (transform XML into something else, e.g. other XML)
>  - XSL-FO (page layout description language, comparable perhaps to 
> postscript)
>
> XSLT has a much bigger scope than just presentation issues. It is not
> a layout language, it's a processing (transformation) programming 
> language.
> XSLT itself cannot express any layout information.
>
> Why shouldn't XSLT be used for web-based presentation?
>
> A key issue is the separation between semantics and presentation, 
> which should
> even be available at the client side (browser), for instance for 
> accessibility
> reasons. To the user agent, a clean, semantic form of the content must 
> exist
> to allow custom presentation options (like screen readers - JAWS - ,
> a print version, ...). Otherwise, all these presentation options would 
> have
> to be provided by the server (CMS) and wouldn't be customizable and 
> extensible
> on the client side.
>
> In your XML-based application, you usually have other structures which
> are based on your domain (medicine, mathematics, music, ...). These 
> structures
> are necessary to hold all semantic information of your domain. But on the
> client side, we need a standardized structure which can be understood 
> by all
> user agents (browsers). That's what XHTML is about - it's a standardized
> language to express sequential, structured content.
>
> XSLT is the technology to transform your domain oriented content into the
> standardized XHTML content.
>
> XSLT could also be used for different client-side presentation options
> (like print views, multiple or single column layouts, ...), but this
> has some drawbacks:
>
> - not all browsers support client-side XSLT
> - XSLT is much more complex than CSS (more flexibility is necessary)
> - XSLT is much harder to learn
> - another complex standardized presentation format would be required,
>   which would be the target format of the XSLT transformation
>   (at the moment this is HTML with style markup in most cases)
>
> XSL-FO is the weapon of choice when printable pages are required.
> It is extremely powerful, especially in combination with SVG you can
> implement amazingly complex designs. It is much more flexible than
> CSS for print views, but also much harder to learn and much more
> verbose.
>
> CSS is the weapon of choice for styling XML (e.g., XHTML) and SVG
> for simple, flexible applications (like web pages).
>
> See also http://www.xml.com/pub/a/2000/03/08/style/
>
>
>> That xml/xsl/xslt/xsl-fo is the optimal solution, but browsers just 
>> aren't ready for it?
>> And CSS's are used instead because browsers do understand CSS?
>
>
> No, CSS isn't outdated at all - quite the contrary :)
>
>
>> And finally, if tomorrow all major browsers were able to understand 
>> xml/xsl/xslt/xsl-fo would there be a need for Cocoon,
>
>
> Sure, there's much more about Cocoon than applying XSLTs to XML 
> documents.
> It is a framework for building web applications.
>
>> and would Lenya (without Cocoon) become almost like a front-end for 
>> xml/xsl/xslt/xsl-fo?
>
>
> I don't think so, Lenya is a framework for building content management
> solutions. A "front end for XML" I would call an editor (like BXE or
> XMLSpy), which would communicate with Lenya to store content.
>
> -- Andreas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
> For additional commands, e-mail: user-help@lenya.apache.org
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org


Re: Lenya new user (confused)

Posted by Garry Howze <gl...@comcast.net>.
Thanks everybody! (especially Jon, Lee and Andreas)  Andreas, your 
response was very helpful and the link you provided was the final peice 
of the puzzle. Now I understand much better. I think I'll give Lenya a try.

glhowze

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org


Re: Lenya new user (confused)

Posted by Andreas Hartmann <an...@apache.org>.
Garry Howze wrote:
> Thanks to Jon for the informative overview, and to Lee for the 
> csszengarden link. Both were very helpful. But I'm still puzzled about a 
> few things. Please bear with me. I'm just trying to understand the Lenya 
> approach.
> 
> Is it fair to say that xml/xsl/xslt/xsl-fo was conceived as a sort of 
> "grand solution" to the problem of separation of content, logic and 
> presentation, with xml for content, xsl for stylesheets, xslt for 
> transformations and xsl-fo for presentation? If so, it appears to be a 
> very good solution. XML is touted as probably the best overall format 
> for content, and is used extensively. XSLT would transform that content 
> to html/xhtml. That leaves XSL and XSL-FO. So I'm left wondering why 
> isn't xsl (eXtensionable Stylesheet Language, it even has stylesheet 
> language in its name!) used for stylesheets instead of CSS? Then I read 
> that browsers aren't able to handle xsl-fo. Is that the crux of the 
> problem?

Just a short hint:

XSL comprises
  - XSLT (transform XML into something else, e.g. other XML)
  - XSL-FO (page layout description language, comparable perhaps to postscript)

XSLT has a much bigger scope than just presentation issues. It is not
a layout language, it's a processing (transformation) programming language.
XSLT itself cannot express any layout information.

Why shouldn't XSLT be used for web-based presentation?

A key issue is the separation between semantics and presentation, which should
even be available at the client side (browser), for instance for accessibility
reasons. To the user agent, a clean, semantic form of the content must exist
to allow custom presentation options (like screen readers - JAWS - ,
a print version, ...). Otherwise, all these presentation options would have
to be provided by the server (CMS) and wouldn't be customizable and extensible
on the client side.

In your XML-based application, you usually have other structures which
are based on your domain (medicine, mathematics, music, ...). These structures
are necessary to hold all semantic information of your domain. But on the
client side, we need a standardized structure which can be understood by all
user agents (browsers). That's what XHTML is about - it's a standardized
language to express sequential, structured content.

XSLT is the technology to transform your domain oriented content into the
standardized XHTML content.

XSLT could also be used for different client-side presentation options
(like print views, multiple or single column layouts, ...), but this
has some drawbacks:

- not all browsers support client-side XSLT
- XSLT is much more complex than CSS (more flexibility is necessary)
- XSLT is much harder to learn
- another complex standardized presentation format would be required,
   which would be the target format of the XSLT transformation
   (at the moment this is HTML with style markup in most cases)

XSL-FO is the weapon of choice when printable pages are required.
It is extremely powerful, especially in combination with SVG you can
implement amazingly complex designs. It is much more flexible than
CSS for print views, but also much harder to learn and much more
verbose.

CSS is the weapon of choice for styling XML (e.g., XHTML) and SVG
for simple, flexible applications (like web pages).

See also http://www.xml.com/pub/a/2000/03/08/style/


> That xml/xsl/xslt/xsl-fo is the optimal solution, but browsers 
> just aren't ready for it?
> And CSS's are used instead because browsers do understand CSS?

No, CSS isn't outdated at all - quite the contrary :)


> And finally, if tomorrow all major browsers were able to understand 
> xml/xsl/xslt/xsl-fo would there be a need for Cocoon,

Sure, there's much more about Cocoon than applying XSLTs to XML documents.
It is a framework for building web applications.

> and would Lenya 
> (without Cocoon) become almost like a front-end for xml/xsl/xslt/xsl-fo?

I don't think so, Lenya is a framework for building content management
solutions. A "front end for XML" I would call an editor (like BXE or
XMLSpy), which would communicate with Lenya to store content.

-- Andreas


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org


Re: Lenya new user (confused)

Posted by Garry Howze <gl...@comcast.net>.
Thanks to Jon for the informative overview, and to Lee for the 
csszengarden link. Both were very helpful. But I'm still puzzled about a 
few things. Please bear with me. I'm just trying to understand the Lenya 
approach.

Is it fair to say that xml/xsl/xslt/xsl-fo was conceived as a sort of 
"grand solution" to the problem of separation of content, logic and 
presentation, with xml for content, xsl for stylesheets, xslt for 
transformations and xsl-fo for presentation? If so, it appears to be a 
very good solution. XML is touted as probably the best overall format 
for content, and is used extensively. XSLT would transform that content 
to html/xhtml. That leaves XSL and XSL-FO. So I'm left wondering why 
isn't xsl (eXtensionable Stylesheet Language, it even has stylesheet 
language in its name!) used for stylesheets instead of CSS? Then I read 
that browsers aren't able to handle xsl-fo. Is that the crux of the 
problem? That xml/xsl/xslt/xsl-fo is the optimal solution, but browsers 
just aren't ready for it?
And CSS's are used instead because browsers do understand CSS?

And finally, if tomorrow all major browsers were able to understand 
xml/xsl/xslt/xsl-fo would there be a need for Cocoon, and would Lenya 
(without Cocoon) become almost like a front-end for xml/xsl/xslt/xsl-fo?

glhowze

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org


Re: Lenya new user (confused)

Posted by Lee Carroll <le...@aol.com>.
 I'm guessing there must be a reason to use
> CSS's. Can someone give me a quick overview of why CSS's are necessary?
>
See http://www.csszengarden.com/ for a view of what may be done with css and 
its advantages over using styling elements in the html.

CSS promises much and in the main delivers (structured markup with 
limitless(?) look and feel, accessability support, print styling, aural 
styling, ease of maint)  but some times its a struggle. Differing 
interpretation of styles by browsers is a real pain, just make sure you take 
view on what browsers you wish to support and keep testing. CSS also crosses 
the skills boundary. Really requires the "creatives" to get involved, so CSS 
can be seen as good SoC practice. (Its easier for web designers to look 
after a css file than an xslt file)

Lee C 


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org