You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2000/01/25 16:45:01 UTC
A better model for site generation
People,
as you all know, the xml.apache.org site plus all the documents included
in all the hosted projects are built using XML/XSL technology, driven by
Stylebook, a command line clone of Cocoon written by Pier when working
for IBM.
Stylebook and Cocoon share the exact same design patterns, even if not a
single line of code. This is going to change since we believe in
integration, like many others here.
I've been playing around with Stylebook for the last two days to come up
with a better look and feel since our documents use more complex DTDs
and require more expressive power.
But every time I think about "forking" the DTDs, I feel bad, knowing the
pain that will generate.
Anyway, I'll do it and see who wins.
On the other hand, we need a better model for site generation: Donald
(Leslie) and Pier were discussing about a standard way to place
documents, DTDs and site skins on the different packages. I agree we
need to define such a thing.
Donald proposed to follow our pattern used in the distribution
/docs/ -> generated HTML docs
/xdocs/ -> source XML files
so here is the pattern that we should follow to allow better integration
between projects with site tools and stuff:
/xml-<project>/[language/] --> root of the project (language is
required only when the projects spans multiple languages, could we move
xalan-j under java/? without loosing CVS information?)
build.xml -> ant build file
/src -> source tree
/samples -> samples
/xdocs -> document source
a few directories are left for generation (as standard ant build files
do)
/build -> building
/dist -> distribution
so you should not use them for your purposes. NOTE: /docs should never
be used in the CVS. Also, no generated info should be in the CVS rather
than aAll other directories are left for your needs.
/xdocs -> XML documents
/xdocs/dtd -> their DTDs
/xdocs/skins -> the stylebook skins
/xdocs/images -> images used inside XML documents
Now, to reduce effort Pier proposed to symlink the appropriate
directories to xml-site so that one repository for site skins and DTDs
is located. I like this proposal even if makes the directories and their
contract very solid. this is why we should discuss them here before
doing such a thing and find an agreement.
Then, Pier will work on having a JDK 1.2 on locus (not easy, since we're
running FreeBSD) so that site generation can be done there.
I propose to _remove_ everything from xml-site but the instructions and
scripts on how to generate the site. The script should use CVS to
download the documents from all the different modules, then each project
build.xml file should have a "site" target that generates its
documentation for the web site.
The key is duplication of effort.
I think we should minimize the use of symlinks across CVS modules, since
this is clearly a dirty hack. The only good symlinks are those that
require the presence of information inside the CVS modules, but stuff
that doesn't really belong there as for development purposes.
So, my proposal is:
1) remove xml-site all together (or leave it with scripts and
instructions)
2) place the skins under xml-stylebook in a well structured directory
3) install JDK 1.2 on locus using FreeBSD Linux emulation and the
latest Sun/Imprise/BlackDown JVM for linux.
4) create a script that generates the web site and place it in
/home/www/xml.apache.org
The idea is simple:
1) every project has its own docs files, DTD and skin (those who wish to
use global ones, will have the CVS symlinked for them).
2) doc writers should work on their docs and forget about anything else
3) we should not move thing around: it's easy to make mistakes
4) generating the site should be as easy as: login; cd
/home/www/xml.apache.org; ant site
that's it.
I won't stop bugging people around here until we find a global agreement
on this. So, be prepared: I just turned my "pain-in-the-ass" mode on :)
--
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: A better model for site generation
Posted by Pierpaolo Fumagalli <pi...@apache.org>.
Ben Laurie wrote:
>
> Stefano Mazzocchi wrote:
> > Then, Pier will work on having a JDK 1.2 on locus (not easy, since we're
> > running FreeBSD) so that site generation can be done there.
>
> Why is 1.2 required?
AWT for images generation...
Pier
--
--------------------------------------------------------------------
- P I E R -
stable structure erected over water to allow the docking of seacraft
<ma...@betaversion.org> <http://www.betaversion.org/~pier/>
--------------------------------------------------------------------
- ApacheCON Y2K: Come to the official Apache developers conference -
-------------------- <http://www.apachecon.com> --------------------
Re: A better model for site generation
Posted by Ben Laurie <be...@algroup.co.uk>.
Stefano Mazzocchi wrote:
> Then, Pier will work on having a JDK 1.2 on locus (not easy, since we're
> running FreeBSD) so that site generation can be done there.
Why is 1.2 required?
Cheers,
Ben.
--
SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm
http://www.apache-ssl.org/ben.html
Y19100 no-prize winner!
http://www.ntk.net/index.cgi?back=2000/now0121.txt
Re: A better model for site generation
Posted by Stefano Mazzocchi <st...@apache.org>.
Mike Pogue wrote:
>
> Stefano Mazzocchi wrote:
> >
> > I've been playing around with Stylebook for the last two days to come up
> > with a better look and feel since our documents use more complex DTDs
> > and require more expressive power.
> >
>
> Technically, look and feel should be the role of the Style, not the role
> of the DTD.
Yes, you're right, but you know what? after playing around with a bunch
of DTDs, trying to apply DTD inheritance using empty entities and such
(see below), I feel there is a _great_ need of design patterns for DTD
generation and, even more important, style abstraction.
HTML is everything but style abstract, even plain HTML + CSS2.
> However, if there is additional *semantic* tagging that you feel is
> needed, there's definitely the opportunity to add this.
I'd like to discuss briefly something with your guys, since it would
lead to interesting ideas and patterns.
In the Cocoon project we have 5 DTDs: document, spec, faqs, changes,
todo (and bugs in the making)
Document is the most complex one and it follows the W3C spec DTD which
is "extendible", in this sense:
<!ENTITY % local.markup "">
<!ENTITY % markup "strong|em|code|sub|sup%local.markup;">
So, if you create your ExtendedDocument DTD you do
<!ENTITY % local.markup "|shout">
<!ENTITY % document-dtd SYSTEM "document.dtd">
%document-dtd;
and then define what "shout" means.
This is a very simple (and dirty, I admit) way of doing DTD inheritance
without the need of complex stuff like Architectural Forms and without
the use of DTD fragmentation used in the site DTDs (which is not
extendible in this sense).
Now, let us suppose we have a stylesheet for the document DTD, creating
a stylesheet for the extended-document DTD is a matter of writing a
template for the new element and import the previous stylesheet.
This works in the document <-> spec couple, where this DTD inheritance
is used to add bibliography capabilities to the document (our documents
don't require that semantic power, only specs do).
But the other DTDs have a different sense of inheritance: they reuse
part of the code in the document DTD, but they do not set any local.xxx
entities, so they don't _expand_ the semantic meaning of them, they
simply use what's already there.
For example, the FAQ DTD reuses the %markup; entity that includes all
the markup tags with no addiction. In some sense, FAQs, Changes and Todo
provide a higher level of abstraction and, for this reason, they are not
transformed into HTML directly, but they follow two steps:
faqs --> document --> html
while specs (which adds semantic meaning) goes
spec -(imports document)-> html
Can you see the difference? is that clear enough? (I ask because this is
_really_ hard stuff to see, it took me months and the line it's very
thin between the two approaches)
This pattern is not a solid one, but it's the most solid I could come up
with:
1) if you extend the semantic capabilities with local.xxx entities,
you'd better use import the original sheet and improve it from there.
2) otherwise if you reuse parts and add higher level elements which do
not require semantic changes, tranform your more-structured document
into a plain document and then apply the regular document stylesheet.
One thing is for sure: it allows to "measure" the power of your main DTD
since sometimes, you are not able to follow number 2).
For example:
in the Changes DTD, we simply list the changes in Cocoon from revision
to revision. The DTD is simple but inherits the markup and linking
features of the Document DTD. Being an higher level structure and not
adding any semantic capabilities to what's inherited, Changes is
transformed into Document.
But I wanted to add small images up front visually indicating changes,
fixes, deletes and such. Kind of a pretty showof of stylebook
capatilities :) It turns out that the site skin places all the images on
the right side. As you can see from the web site, this is not visually
appealing at all.
So, how do we proceed? This is just an example, but shows the pattern I
used and could be general enough for other needs
- if I changed the stylesheet, all the images would go to the left and I
liked some of them on the right.
- I also wanted to center them and, maybe surround them with a nice
border and caption indicating what is that.
- so, I thought, I could do
a) indicate an attribute to indicate the location of the image
b) create different elements for the different needs
If I choose a), I add styling ideas directly into the content context,
thus totally breaking separation. This is what happened with HTML when
more powerful graphic capabilities were needed.
If I choose b), I turn up adding a bunch of elements for every possible
use of an image.
I believe b) is the right choice and this is what I did:
- icon -> is a text inlined element: places the images where the
element is, normally used for small icons or text-inlined small
graphics. This is what I use with changes to add the icons on the left.
- figure -> this is a block element: it places the image as a block,
normally centered with a caption or such.
- img -> this is another text inlined element, but it's normally used
as a bigger figure with text around it, like in current site skin.
> > But every time I think about "forking" the DTDs, I feel bad, knowing the
> > pain that will generate.
> >
>
> What changes are you suggesting? Could they be done in an upward
> compatible way?
Possibly so, I'll try to come up with a summary of the required changes
ASAP (consider this is not a very high priority for me at this point)
> I suggest we use the "theory of parsimony" here, i.e. the DTD should be
> as simple as possible (but not simpler).
I love this, really, very nice way to put it. I totally agree. But let's
make an example: do you think the img|figure|icon thing is becoming too
complex?
> For example, Docbook is extremely complex,
> even though its expressive power is very high. Even though each
> additional feature provides *some* additional value, it also makes it
> harder to learn (which decreases value).
True, but what happens when you need something that it's not there?
Anyway, the differences in the semantic capabilities of our the two DTDs
are minimal, just maybe a little more structured.
> Let's be very careful not to add more functions, just because we can
> (the eternal temptation, especially when it's real easy to add new
> functions)...I'd like to keep the tagset to where any "Joe Writer" can
> use it, without taking a course in XML first!
Right, let's use the "icon" deal as a test. Tell me what you think and
I'll behave in consequence. (note I don't thing we need anymore of those
images, but its just an example)
> <snip>
>
> > On the other hand, we need a better model for site generation
>
> Agreed.
>
> <snip>
>
> > The idea is simple:
> >
> > 1) every project has its own docs files, DTD and skin (those who wish to
> > use global ones, will have the CVS symlinked for them).
>
> Agreed.
>
> > 2) doc writers should work on their docs and forget about anything else
>
> Yep. However, they also shouldn't have to learn a new tag set each
> month....
Sure, this is why I'd like to have one and only one DTD for the site
that everyone is happy to use. But note that if we extend a DTD (say,
again, we add icon to the tagset), this is completely back compatible.
We should agree on a document structure that is flexible and easy
enough.
> > 3) we should not move thing around: it's easy to make mistakes
>
> Yep.
>
> > 4) generating the site should be as easy as: login; cd
> > /home/www/xml.apache.org; ant site
>
> I'd suggest that the site generation should be not be dependent on ANT
> (or any other particular tool), by abstracting into a script, i.e.
> login;
> cd /home/www/xml.apache.org;
> build-site; (which might internally call ANT or something else)
Agreed, no problemo at all (the java.apache.org site has a PERL script
and a shell script to generate it, while jakarta.apache.org has a shell
script that calls a simple java template tool)
--
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: A better model for site generation
Posted by Stefano Mazzocchi <st...@apache.org>.
Mike Pogue wrote:
>
> Stefano Mazzocchi wrote:
> >
> > I've been playing around with Stylebook for the last two days to come up
> > with a better look and feel since our documents use more complex DTDs
> > and require more expressive power.
> >
>
> Technically, look and feel should be the role of the Style, not the role
> of the DTD.
Yes, you're right, but you know what? after playing around with a bunch
of DTDs, trying to apply DTD inheritance using empty entities and such
(see below), I feel there is a _great_ need of design patterns for DTD
generation and, even more important, style abstraction.
HTML is everything but style abstract, even plain HTML + CSS2.
> However, if there is additional *semantic* tagging that you feel is
> needed, there's definitely the opportunity to add this.
I'd like to discuss briefly something with your guys, since it would
lead to interesting ideas and patterns.
In the Cocoon project we have 5 DTDs: document, spec, faqs, changes,
todo (and bugs in the making)
Document is the most complex one and it follows the W3C spec DTD which
is "extendible", in this sense:
<!ENTITY % local.markup "">
<!ENTITY % markup "strong|em|code|sub|sup%local.markup;">
So, if you create your ExtendedDocument DTD you do
<!ENTITY % local.markup "|shout">
<!ENTITY % document-dtd SYSTEM "document.dtd">
%document-dtd;
and then define what "shout" means.
This is a very simple (and dirty, I admit) way of doing DTD inheritance
without the need of complex stuff like Architectural Forms and without
the use of DTD fragmentation used in the site DTDs (which is not
extendible in this sense).
Now, let us suppose we have a stylesheet for the document DTD, creating
a stylesheet for the extended-document DTD is a matter of writing a
template for the new element and import the previous stylesheet.
This works in the document <-> spec couple, where this DTD inheritance
is used to add bibliography capabilities to the document (our documents
don't require that semantic power, only specs do).
But the other DTDs have a different sense of inheritance: they reuse
part of the code in the document DTD, but they do not set any local.xxx
entities, so they don't _expand_ the semantic meaning of them, they
simply use what's already there.
For example, the FAQ DTD reuses the %markup; entity that includes all
the markup tags with no addiction. In some sense, FAQs, Changes and Todo
provide a higher level of abstraction and, for this reason, they are not
transformed into HTML directly, but they follow two steps:
faqs --> document --> html
while specs (which adds semantic meaning) goes
spec -(imports document)-> html
Can you see the difference? is that clear enough? (I ask because this is
_really_ hard stuff to see, it took me months and the line it's very
thin between the two approaches)
This pattern is not a solid one, but it's the most solid I could come up
with:
1) if you extend the semantic capabilities with local.xxx entities,
you'd better use import the original sheet and improve it from there.
2) otherwise if you reuse parts and add higher level elements which do
not require semantic changes, tranform your more-structured document
into a plain document and then apply the regular document stylesheet.
One thing is for sure: it allows to "measure" the power of your main DTD
since sometimes, you are not able to follow number 2).
For example:
in the Changes DTD, we simply list the changes in Cocoon from revision
to revision. The DTD is simple but inherits the markup and linking
features of the Document DTD. Being an higher level structure and not
adding any semantic capabilities to what's inherited, Changes is
transformed into Document.
But I wanted to add small images up front visually indicating changes,
fixes, deletes and such. Kind of a pretty showof of stylebook
capatilities :) It turns out that the site skin places all the images on
the right side. As you can see from the web site, this is not visually
appealing at all.
So, how do we proceed? This is just an example, but shows the pattern I
used and could be general enough for other needs
- if I changed the stylesheet, all the images would go to the left and I
liked some of them on the right.
- I also wanted to center them and, maybe surround them with a nice
border and caption indicating what is that.
- so, I thought, I could do
a) indicate an attribute to indicate the location of the image
b) create different elements for the different needs
If I choose a), I add styling ideas directly into the content context,
thus totally breaking separation. This is what happened with HTML when
more powerful graphic capabilities were needed.
If I choose b), I turn up adding a bunch of elements for every possible
use of an image.
I believe b) is the right choice and this is what I did:
- icon -> is a text inlined element: places the images where the
element is, normally used for small icons or text-inlined small
graphics. This is what I use with changes to add the icons on the left.
- figure -> this is a block element: it places the image as a block,
normally centered with a caption or such.
- img -> this is another text inlined element, but it's normally used
as a bigger figure with text around it, like in current site skin.
> > But every time I think about "forking" the DTDs, I feel bad, knowing the
> > pain that will generate.
> >
>
> What changes are you suggesting? Could they be done in an upward
> compatible way?
Possibly so, I'll try to come up with a summary of the required changes
ASAP (consider this is not a very high priority for me at this point)
> I suggest we use the "theory of parsimony" here, i.e. the DTD should be
> as simple as possible (but not simpler).
I love this, really, very nice way to put it. I totally agree. But let's
make an example: do you think the img|figure|icon thing is becoming too
complex?
> For example, Docbook is extremely complex,
> even though its expressive power is very high. Even though each
> additional feature provides *some* additional value, it also makes it
> harder to learn (which decreases value).
True, but what happens when you need something that it's not there?
Anyway, the differences in the semantic capabilities of our the two DTDs
are minimal, just maybe a little more structured.
> Let's be very careful not to add more functions, just because we can
> (the eternal temptation, especially when it's real easy to add new
> functions)...I'd like to keep the tagset to where any "Joe Writer" can
> use it, without taking a course in XML first!
Right, let's use the "icon" deal as a test. Tell me what you think and
I'll behave in consequence. (note I don't thing we need anymore of those
images, but its just an example)
> <snip>
>
> > On the other hand, we need a better model for site generation
>
> Agreed.
>
> <snip>
>
> > The idea is simple:
> >
> > 1) every project has its own docs files, DTD and skin (those who wish to
> > use global ones, will have the CVS symlinked for them).
>
> Agreed.
>
> > 2) doc writers should work on their docs and forget about anything else
>
> Yep. However, they also shouldn't have to learn a new tag set each
> month....
Sure, this is why I'd like to have one and only one DTD for the site
that everyone is happy to use. But note that if we extend a DTD (say,
again, we add icon to the tagset), this is completely back compatible.
We should agree on a document structure that is flexible and easy
enough.
> > 3) we should not move thing around: it's easy to make mistakes
>
> Yep.
>
> > 4) generating the site should be as easy as: login; cd
> > /home/www/xml.apache.org; ant site
>
> I'd suggest that the site generation should be not be dependent on ANT
> (or any other particular tool), by abstracting into a script, i.e.
> login;
> cd /home/www/xml.apache.org;
> build-site; (which might internally call ANT or something else)
Agreed, no problemo at all (the java.apache.org site has a PERL script
and a shell script to generate it, while jakarta.apache.org has a shell
script that calls a simple java template tool)
--
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: A better model for site generation
Posted by Mike Pogue <mp...@apache.org>.
Stefano Mazzocchi wrote:
>
> I've been playing around with Stylebook for the last two days to come up
> with a better look and feel since our documents use more complex DTDs
> and require more expressive power.
>
Technically, look and feel should be the role of the Style, not the role
of the DTD.
However, if there is additional *semantic* tagging that you feel is
needed, there's
definitely the opportunity to add this.
> But every time I think about "forking" the DTDs, I feel bad, knowing the
> pain that will generate.
>
What changes are you suggesting? Could they be done in an upward
compatible way?
I suggest we use the "theory of parsimony" here, i.e. the DTD should be
as simple as
possible (but not simpler). For example, Docbook is extremely complex,
even though its expressive power is very high. Even though each
additional feature provides *some* additional value, it also makes it
harder to learn (which decreases value).
Let's be very careful not to add more functions, just because we can
(the eternal temptation, especially when it's real easy to add new
functions)...I'd like to keep the tagset to where any "Joe Writer" can
use it, without taking a course in XML first!
<snip>
> On the other hand, we need a better model for site generation
Agreed.
<snip>
> The idea is simple:
>
> 1) every project has its own docs files, DTD and skin (those who wish to
> use global ones, will have the CVS symlinked for them).
Agreed.
> 2) doc writers should work on their docs and forget about anything else
Yep. However, they also shouldn't have to learn a new tag set each
month....
> 3) we should not move thing around: it's easy to make mistakes
Yep.
> 4) generating the site should be as easy as: login; cd
> /home/www/xml.apache.org; ant site
I'd suggest that the site generation should be not be dependent on ANT
(or any other particular tool), by abstracting into a script, i.e.
login;
cd /home/www/xml.apache.org;
build-site; (which might internally call ANT or something else)
Re: A better model for site generation
Posted by Ben Laurie <be...@algroup.co.uk>.
Stefano Mazzocchi wrote:
> Then, Pier will work on having a JDK 1.2 on locus (not easy, since we're
> running FreeBSD) so that site generation can be done there.
Why is 1.2 required?
Cheers,
Ben.
--
SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm
http://www.apache-ssl.org/ben.html
Y19100 no-prize winner!
http://www.ntk.net/index.cgi?back=2000/now0121.txt
Re: A better model for site generation
Posted by Mike Pogue <mp...@apache.org>.
Stefano Mazzocchi wrote:
>
> I've been playing around with Stylebook for the last two days to come up
> with a better look and feel since our documents use more complex DTDs
> and require more expressive power.
>
Technically, look and feel should be the role of the Style, not the role
of the DTD.
However, if there is additional *semantic* tagging that you feel is
needed, there's
definitely the opportunity to add this.
> But every time I think about "forking" the DTDs, I feel bad, knowing the
> pain that will generate.
>
What changes are you suggesting? Could they be done in an upward
compatible way?
I suggest we use the "theory of parsimony" here, i.e. the DTD should be
as simple as
possible (but not simpler). For example, Docbook is extremely complex,
even though its expressive power is very high. Even though each
additional feature provides *some* additional value, it also makes it
harder to learn (which decreases value).
Let's be very careful not to add more functions, just because we can
(the eternal temptation, especially when it's real easy to add new
functions)...I'd like to keep the tagset to where any "Joe Writer" can
use it, without taking a course in XML first!
<snip>
> On the other hand, we need a better model for site generation
Agreed.
<snip>
> The idea is simple:
>
> 1) every project has its own docs files, DTD and skin (those who wish to
> use global ones, will have the CVS symlinked for them).
Agreed.
> 2) doc writers should work on their docs and forget about anything else
Yep. However, they also shouldn't have to learn a new tag set each
month....
> 3) we should not move thing around: it's easy to make mistakes
Yep.
> 4) generating the site should be as easy as: login; cd
> /home/www/xml.apache.org; ant site
I'd suggest that the site generation should be not be dependent on ANT
(or any other particular tool), by abstracting into a script, i.e.
login;
cd /home/www/xml.apache.org;
build-site; (which might internally call ANT or something else)
Re: A better model for site generation
Posted by Stefano Mazzocchi <st...@apache.org>.
Sander van Zoest wrote:
>
> On Tue, 25 Jan 2000, Stefano Mazzocchi wrote:
>
> > People,
> > as you all know, the xml.apache.org site plus all the documents included
> > in all the hosted projects are built using XML/XSL technology, driven by
> > Stylebook, a command line clone of Cocoon written by Pier when working
> > for IBM.
> > Stylebook and Cocoon share the exact same design patterns, even if not a
> > single line of code. This is going to change since we believe in
> > integration, like many others here.
Hi Sander,
> Here at MP3.com, Inc. we use a similar, but less featurefull technique
> of generating XML and style based template pages on-the-fly. This is all
> written in C and are build-in apache modules that can be called via
> mod_perl for dynamic page generation based on i18n,style and/or xml content.
Ok.
> Since our approach was to get performance over features and since XSL:T
> and XSL:FO were still in the early stages, we came up with our own small
> subset of the XSL feature set that does the job quite nicely.
Is this done dynamically, then?
> I would like to work on an open source method of this using XSL with
> strict performance in mind.
This is the same goal the Cocoon project has, _exactly_ the same.
> I will be speaking about this at ApacheCon 2000, so hopefully I will find
> some time after the conference to work on this and have it available
> via this XML group.
I hope to talk about ways to integrate your work with us at the
conference. I'll be speaking about Cocoon too.
> Just thought, I would bring this up since we were talking about the creation
> of a publishing tool for the web using XML/XSL.
No, we are not. The publishing tool for the web using XML/XSL is already
there, actually we have two: "stylebook" for static content generation
and "cocoon" for dynamic content generation. The plan is to integrate
them into a single product so that you can do static generation on a
regular (time-driven?) base and dynamic generation on the flighy where
you can't do any different.
It's all java based and not as performant as it could be, but we already
have plans to increase speed and functionality. Take a look at it if you
haven't done so.
It would be totally great if mp3.com used Cocoon as publishing engine:
I'm an old time fan of mp3.com :)
--
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: A better model for site generation
Posted by Stefano Mazzocchi <st...@apache.org>.
Sander van Zoest wrote:
>
> On Tue, 25 Jan 2000, Stefano Mazzocchi wrote:
>
> > People,
> > as you all know, the xml.apache.org site plus all the documents included
> > in all the hosted projects are built using XML/XSL technology, driven by
> > Stylebook, a command line clone of Cocoon written by Pier when working
> > for IBM.
> > Stylebook and Cocoon share the exact same design patterns, even if not a
> > single line of code. This is going to change since we believe in
> > integration, like many others here.
Hi Sander,
> Here at MP3.com, Inc. we use a similar, but less featurefull technique
> of generating XML and style based template pages on-the-fly. This is all
> written in C and are build-in apache modules that can be called via
> mod_perl for dynamic page generation based on i18n,style and/or xml content.
Ok.
> Since our approach was to get performance over features and since XSL:T
> and XSL:FO were still in the early stages, we came up with our own small
> subset of the XSL feature set that does the job quite nicely.
Is this done dynamically, then?
> I would like to work on an open source method of this using XSL with
> strict performance in mind.
This is the same goal the Cocoon project has, _exactly_ the same.
> I will be speaking about this at ApacheCon 2000, so hopefully I will find
> some time after the conference to work on this and have it available
> via this XML group.
I hope to talk about ways to integrate your work with us at the
conference. I'll be speaking about Cocoon too.
> Just thought, I would bring this up since we were talking about the creation
> of a publishing tool for the web using XML/XSL.
No, we are not. The publishing tool for the web using XML/XSL is already
there, actually we have two: "stylebook" for static content generation
and "cocoon" for dynamic content generation. The plan is to integrate
them into a single product so that you can do static generation on a
regular (time-driven?) base and dynamic generation on the flighy where
you can't do any different.
It's all java based and not as performant as it could be, but we already
have plans to increase speed and functionality. Take a look at it if you
haven't done so.
It would be totally great if mp3.com used Cocoon as publishing engine:
I'm an old time fan of mp3.com :)
--
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: A better model for site generation
Posted by Sander van Zoest <sa...@mp3.com>.
On Tue, 25 Jan 2000, Stefano Mazzocchi wrote:
> People,
> as you all know, the xml.apache.org site plus all the documents included
> in all the hosted projects are built using XML/XSL technology, driven by
> Stylebook, a command line clone of Cocoon written by Pier when working
> for IBM.
> Stylebook and Cocoon share the exact same design patterns, even if not a
> single line of code. This is going to change since we believe in
> integration, like many others here.
Here at MP3.com, Inc. we use a similar, but less featurefull technique
of generating XML and style based template pages on-the-fly. This is all
written in C and are build-in apache modules that can be called via
mod_perl for dynamic page generation based on i18n,style and/or xml content.
Since our approach was to get performance over features and since XSL:T
and XSL:FO were still in the early stages, we came up with our own small
subset of the XSL feature set that does the job quite nicely.
I would like to work on an open source method of this using XSL with
strict performance in mind.
I will be speaking about this at ApacheCon 2000, so hopefully I will find
some time after the conference to work on this and have it available
via this XML group.
Just thought, I would bring this up since we were talking about the creation
of a publishing tool for the web using XML/XSL.
Cheers,
-
Sander van Zoest sander@mp3.com
High Geek (858) 623-7442
MP3.com, Inc. http://www.mp3.com/
Your premiere Music Service Provider (MSP)