You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Ferdinand Soethe <fe...@apache.org> on 2005/10/25 11:02:12 UTC
Slidy-Plugin
I'm currently working on a package of xml-grammar and transformations to
easily generate Slidy-Presentations, the W3C equivalent of the S5
presentation tool (See http://www.w3.org/Talks/Tools/Slidy/ for more
on Slidy).
At the moment I have
- a specialized presentation grammar to allow people who don't
know much about html to easily write xml-presentations with
any grammar-aware editor.
- a transformation from my specialized 'presenation xml' to slidy-html.
and will soon add
- a transformation from my 'presenation xml' to document13 or
xtml.
Now I would like to start building a plugin that to support
- transforming 'presenation xml' to slidy-html (unskinned
document)
- transforming 'presenation xml' to normal skinned html
- transforming 'presenation xml' to normal Forrest pdf
Am I correct to think that it should really be two plugins,
- an input plugin to translate 'presenation xml' to document13
- an output plugin to translate document13 to slidy.
And while I see this from the architectural point of view as a long term
goal, right now this is out of question for a number of reasons. So my
question really is:
(how) can I design a plugin that will provide these translations
- transforming 'presenation xml' to slidy-html (unskinned
document)
- transforming 'presenation xml' to normal skinned html
- transforming 'presenation xml' to normal Forrest pdf
without going through an intermediate format when transforming
'presenation xml' to slidy-html (unskinned document)?
Thanks for your input.
--
Ferdinand Soethe
Re: Slidy-Plugin
Posted by Ross Gardler <rg...@apache.org>.
Ferdinand Soethe wrote:
> Ross Gardler wrote:
>
> I was counting on you for some help here. Thanks!
>
>
>
>><match pattern="**.slidy.html">
>> <map:generate src="{1}.xml"/>
>> <map:transform src="{lm:tranform.slidy.html}"/>
>> <map:serialize type="html"/>
>></match>
>
>
>
> hmmm.
> Is is correct to say that <map:generate src="{1}.xml"/> will make
> Forrest take my presentation.xml file as a source? That is
> presentation-xml is fed into the transformation without detour through
> document13?
yes, the default generator is the file generator. The above assumes that
** is the path to your presentation.xml within your project directory,
of course. You will probably want to add {project:content.xdocs} in
front of that. If so you should really be using the locationmap:
<map:generate src="{lm:project.{1}.xml}"/>
is equivalent to
<map:generate src="{project:content.xdocs}/{1}.xml"/>
(that is from memory, if it doesn't work for you check the forrest.xmap
for the correct syntax)
> If so, this is all that I wanted to achieve. The rest (transform to
> document13 for skinning and pdf is clear).
>
> But what about about the lm-indirection {lm:tranform.slidy.html}. How
> is the plugin supposed to provide the resolution to the xsl-file.
See the projectinfo plugin. I recently modified that to use the
locationmap. You need to look at input.xmap and locationmap.xml.
> And how am I supposed to point to the .js, image- and .css files
> required by slidy?
Look in the s5 plugin for guidance on that one. However, be aware of
http://issues.apache.org/jira/browse/FOR-341
It will sting you for the same reason as it stung me with the s5 plugin.
This should be easy to resolve now that we have better raw-content
handling and the locationmap. Ask when you hit it :-)
Ross
Re: Slidy-Plugin
Posted by Ferdinand Soethe <fe...@apache.org>.
Ross Gardler wrote:
I was counting on you for some help here. Thanks!
> <match pattern="**.slidy.html">
> <map:generate src="{1}.xml"/>
> <map:transform src="{lm:tranform.slidy.html}"/>
> <map:serialize type="html"/>
> </match>
hmmm.
Is is correct to say that <map:generate src="{1}.xml"/> will make
Forrest take my presentation.xml file as a source? That is
presentation-xml is fed into the transformation without detour through
document13?
If so, this is all that I wanted to achieve. The rest (transform to
document13 for skinning and pdf is clear).
But what about about the lm-indirection {lm:tranform.slidy.html}. How
is the plugin supposed to provide the resolution to the xsl-file.
And how am I supposed to point to the .js, image- and .css files
required by slidy?
Thanks,
Ferdinand Soethe
Re: Slidy-Plugin
Posted by Ross Gardler <rg...@apache.org>.
Ferdinand Soethe wrote:
> I'm currently working on a package of xml-grammar and transformations to
> easily generate Slidy-Presentations, the W3C equivalent of the S5
> presentation tool (See http://www.w3.org/Talks/Tools/Slidy/ for more
> on Slidy).
Cool, a license compatible slide plugin :-))
(Thanks to Sylvain who pointed us at this thing in Stuttgart)
...
> Now I would like to start building a plugin that to support
>
> - transforming 'presenation xml' to slidy-html (unskinned
> document)
> - transforming 'presenation xml' to normal skinned html
> - transforming 'presenation xml' to normal Forrest pdf
>
> Am I correct to think that it should really be two plugins,
>
> - an input plugin to translate 'presenation xml' to document13
> - an output plugin to translate document13 to slidy.
Yes..
> And while I see this from the architectural point of view as a long term
> goal, right now this is out of question for a number of reasons.
Why? It is usually the fastest way to do things.
> So my
> question really is:
>
> (how) can I design a plugin that will provide these translations
>
> - transforming 'presenation xml' to slidy-html (unskinned
> document)
<match pattern="**.slidy.html">
<map:generate src="{1}.xml"/>
<map:transform src="{lm:tranform.slidy.html}"/>
<map:serialize type="html"/>
</match>
request: http://domain.org/path/to/slides/myslides.slidy.html
Belongs in org.apache.forrest.plugins.output.slidy
> - transforming 'presenation xml' to normal skinned html
<match pattern="**.xml">
<!-- here you must only process files of your presentation DTD
The output must be XDoc
See the simplified docobook plugin for example how to do this -->
</match>
request: http://domain.org/path/to/slides/myslides.html
Belongs in org.apache.forrest.plugins.input.slidy
> - transforming 'presenation xml' to normal Forrest pdf
You'd get this by implmenting the above.
> without going through an intermediate format when transforming
> 'presenation xml' to slidy-html (unskinned document)?
The above does go through the intermediate format, but there is no other
was of doing it unless you want to write a presentation.xml to
Formatting Objects stylseheet to get your PDF, which is much more
complex and time consuming than building the intermediate format,
expsecially when you consider that your html generating XSL is very
close to XDoc anyway.
There is a workaround that *may* work, it depends on what your HTML
looks like. In the input plugin you could use the HTML generated by your
output plugin and process that with the html-to-document stylesheet.
This is a technique I have used in the projectInfo plugin becuase I do
not have control over the doap-to-html stylsheet. However, I do not
recomend this route, it is full of potholes.
Ross
Re: Slidy-Plugin - where to put grammar files
Posted by Ross Gardler <rg...@apache.org>.
Ferdinand Soethe wrote:
>
> I need to install a new grammar for the plugin source files, but I'm
> unclear where it should go.
PLUGIN_HOME/resources/schema?
> Also, it has to be relax-ng
> (preferred) or schema to support all the features, is that a problem?
I'm not sure of the status of our relax-ng support. I know David did
some work on this recently. Perhaps he can throw more light on it.
Ross
Re: SmartSlides Input PlugIn (aka SlidyPlugin)
Posted by Ross Gardler <rg...@apache.org>.
Ferdinand Soethe wrote:
>>I've responded there. Can I ask you also read the archives about why we
>>insist on going through an internal format.
>
>
> I actually have been following these discussion in the past and I
> still agree with you
>
> - as long as we are talking about publishing content in
> standard Forrest output channels
Well that is what Forrest does, so no argument there.
(I snipped the brakcet about slidy as there is a whole other thread
about that now and will address it there)
> - as long as we talk about XHTML2 as our meta format because xdocs is
> way to limited to transport all the information that specialized
> grammars provide.
We have *always* talked of this. Note that a long time ago we agreed
that anything in the XHTML2 subset we have agreed on can be put in to
document 2.0 as and when requried without the need for a vote.
So again, no argument for me.
>>This comes up every six
>>months or so.
>
>
>>I distinctly remember a very similar discussion with Sean
>>Wellar (or Whellar, or some similar spelling, sorry Sean), this was in
>>relation to bypassing XDoc for docbook inputs.
>
>
> It's Sean Wheller actually. And now that I see his name again I
> recognize him as the maker of my favorite XML-Editor (Oxygen) if it is
> the same person.
>
> Anyway. It seems like you have two to argue about this now :-)
Actually, what you argue in the other thread is completely different
from what others (including Sean) have argued in the passed. What has
become clear in the other thread is that you are talking about bypassing
the internal format when you don't want to use Forrest's skinning. That
is a completely different issue and I will address it in your thread
"Bypass plugins".
>>>That said, to make this work you'd have to start by
>>>
>>>- allowing div and span elements in the doc13 grammar (which would be good for a number
>>> of other applications as well)
>
>
>>div and span are both in our XHTML2 subset so not problem there.
>>Similarly views use them extensively.
>
>
> Well I'm talking about div and span being used in Xdocs. Which atm is
> not legal in it's grammar.
It is in our agreed XHTML2 subset, tehrefore you can add it to Document
v2.0 if you need it.
>>>- continue by preventing our current pipelines from 'loosing' or
>>> overwriting class and id attributes from a number of elements (some
>>> of them - such as body - involving rather complex changes).
>
>
>>We have already established that is a bug, so no problem there.
>
>
> Except that I consider it a waste of resources to do this for
> soon-to-be-phased-out xdocs.
So spend the respources on getting XHTML2 implemented then ;-)
>>>Some of which to looked like a nightmare in terms of doing it,
>>>documenting it and preserving backward compatibility etc. And
>>>Especially since a clean implementation of XHTML2 would remove most of
>>>these obstacles anyway.
>
>
>>Another push for XHMTL2 then, good.
>
>
> OK, so what is the solution for that plugin now?
Do you mean the XHTML2 plugin? If so the answer is that the views folk
felt the approach was wrong. We are now waiting for views 2 before we
can proceed.
Ross
Re: SmartSlides Input PlugIn (aka SlidyPlugin)
Posted by Ferdinand Soethe <fe...@apache.org>.
>>>The source for the output plugin should be our internal format,
>>>otherwise you would be creating a dependency between the two plugins.
>>>The idea is to show what an internal format document should look like.
>>
>>
>> Would I? My intention was to transform my special format right into
>> the output format. No dependency there. But I agree that the naming
>> would be misleading (thus my proposal for a new bypass plugin class).
> Let me see if I understand:
> "special format" = smartslides grammar
> "output format" = slidy
> If this is correct you are creating a dependency between the input
> plugin (smartslides) and output plugin (slidy) since sldy can only work
> with the smartslides grammar.
OK, in that sence you are right. SmartSlides-output does require input
that follows my SmartSlides grammar (or provides similar information,
which excludes many other input channels).
> I've responded there. Can I ask you also read the archives about why we
> insist on going through an internal format.
I actually have been following these discussion in the past and I
still agree with you
- as long as we are talking about publishing content in
standard Forrest output channels
(not so sure about specialized output like Slidy anymore)
- as long as we talk about XHTML2 as our meta format because xdocs is
way to limited to transport all the information that specialized
grammars provide.
> This comes up every six
> months or so.
> I distinctly remember a very similar discussion with Sean
> Wellar (or Whellar, or some similar spelling, sorry Sean), this was in
> relation to bypassing XDoc for docbook inputs.
It's Sean Wheller actually. And now that I see his name again I
recognize him as the maker of my favorite XML-Editor (Oxygen) if it is
the same person.
Anyway. It seems like you have two to argue about this now :-)
>> That said, to make this work you'd have to start by
>>
>> - allowing div and span elements in the doc13 grammar (which would be good for a number
>> of other applications as well)
> div and span are both in our XHTML2 subset so not problem there.
> Similarly views use them extensively.
Well I'm talking about div and span being used in Xdocs. Which atm is
not legal in it's grammar.
>> - continue by preventing our current pipelines from 'loosing' or
>> overwriting class and id attributes from a number of elements (some
>> of them - such as body - involving rather complex changes).
> We have already established that is a bug, so no problem there.
Except that I consider it a waste of resources to do this for
soon-to-be-phased-out xdocs.
>> Some of which to looked like a nightmare in terms of doing it,
>> documenting it and preserving backward compatibility etc. And
>> Especially since a clean implementation of XHTML2 would remove most of
>> these obstacles anyway.
> Another push for XHMTL2 then, good.
OK, so what is the solution for that plugin now?
--
Ferdinand Soethe
Re: SmartSlides Input PlugIn (aka SlidyPlugin)
Posted by Ross Gardler <rg...@apache.org>.
Ferdinand Soethe wrote:
>
> Ross Gardler wrote:
>>The source for the output plugin should be our internal format,
>>otherwise you would be creating a dependency between the two plugins.
>>The idea is to show what an internal format document should look like.
>
>
> Would I? My intention was to transform my special format right into
> the output format. No dependency there. But I agree that the naming
> would be misleading (thus my proposal for a new bypass plugin class).
Let me see if I understand:
"special format" = smartslides grammar
"output format" = slidy
If this is correct you are creating a dependency between the input
plugin (smartslides) and output plugin (slidy) since sldy can only work
with the smartslides grammar.
>>>Main reason for this being that I saw no way of transporting
>>>all the data from my grammar through the limitations of docVxx.
>
>
>>I bet I can :-)
>>Give an example or two of problems.
>
>
> Yes, you probably could. But read my proposal first to find out why I
> think that this doesn't really make so much sense.
I've responded there. Can I ask you also read the archives about why we
insist on going through an internal format. This comes up every six
months or so. I distinctly remember a very similar discussion with Sean
Wellar (or Whellar, or some similar spelling, sorry Sean), this was in
relation to bypassing XDoc for docbook inputs.
> That said, to make this work you'd have to start by
>
> - allowing div and span elements in the doc13 grammar (which would be good for a number
> of other applications as well)
div and span are both in our XHTML2 subset so not problem there.
Similarly views use them extensively.
> - continue by preventing our current pipelines from 'loosing' or
> overwriting class and id attributes from a number of elements (some
> of them - such as body - involving rather complex changes).
We have already established that is a bug, so no problem there.
> Some of which to looked like a nightmare in terms of doing it,
> documenting it and preserving backward compatibility etc. And
> Especially since a clean implementation of XHTML2 would remove most of
> these obstacles anyway.
Another push for XHMTL2 then, good.
> I'll add the output plugin with just the bare structure now so you can
> take a look at the transformations.
Cool.
Ross
Re: SmartSlides Input PlugIn (aka SlidyPlugin)
Posted by Ferdinand Soethe <fe...@apache.org>.
Ross Gardler wrote:
> Having said this, I know you are doing this for ApacheCon and I know you
> are therefore on a deadline. While the plugin is in whiteboard we can do
> what you need to do in order to meet your deadlines. I am only saying
> what we need to have in order for it to come out of whiteboard. So, as
> long as we are moving towards a processing pipeline as defined in our TR
> we can cut corners in the short term.
Well it seems like the ApacheCon deadline is off since there are not
enough registrations for the tutorial. And I have already created the
presentation by direct transformation which will remain yet another
version of smartslides anyway.
So ... grumbling ... we might as well do it right.
Although ... No! I'll make this a separate thread ... Done.
> The source for the output plugin should be our internal format,
> otherwise you would be creating a dependency between the two plugins.
> The idea is to show what an internal format document should look like.
Would I? My intention was to transform my special format right into
the output format. No dependency there. But I agree that the naming
would be misleading (thus my proposal for a new bypass plugin class).
>> Main reason for this being that I saw no way of transporting
>> all the data from my grammar through the limitations of docVxx.
> I bet I can :-)
> Give an example or two of problems.
Yes, you probably could. But read my proposal first to find out why I
think that this doesn't really make so much sense.
That said, to make this work you'd have to start by
- allowing div and span elements in the doc13 grammar (which would be good for a number
of other applications as well)
- continue by preventing our current pipelines from 'loosing' or
overwriting class and id attributes from a number of elements (some
of them - such as body - involving rather complex changes).
Some of which to looked like a nightmare in terms of doing it,
documenting it and preserving backward compatibility etc. And
Especially since a clean implementation of XHTML2 would remove most of
these obstacles anyway.
I'll add the output plugin with just the bare structure now so you can
take a look at the transformations.
--
Ferdinand Soethe
Re: SmartSlides Input PlugIn (aka SlidyPlugin)
Posted by Ross Gardler <rg...@apache.org>.
Ferdinand Soethe wrote:
> Ross Gardler wrote:
>
>
>>site: I don't see this as the case, your input plugin takes your new
>>schema and creates our internal format, so only documents the new
>>schema, there is no need to document what it is converted into internally.
>
>
> No, but I'd basically have two sites with the same examples and docs.
The source for the output plugin should be our internal format,
otherwise you would be creating a dependency between the two plugins.
The idea is to show what an internal format document should look like.
>>grammar: why is this needed on the output side? The output plugin should
>>only work with our internal format.
>
>
> Well no. My last conclusion of our discussion was that the output
> plugin will transform my new schema to the final slidy output.
No, that was not what I meant. All processing should go through our
intermediate format otherwise we lose the many inputs to many outputs stuff.
Input -> XSL -> internal format -> xsl -> output format
> Main reason for this being that I saw no way of transporting
> all the data from my grammar through the limitations of docVxx.
I bet I can :-)
Give an example or two of problems.
> Later on there will be two transformations in the output plugin
>
> smartslides --> slidy
No - that breaks our processing definition in our TR
> xhtml --> slidy
if you mean XHTML2 and are referring to the future internal format OK.
Otherwise, no for the same reason.
Having said this, I know you are doing this for ApacheCon and I know you
are therefore on a deadline. While the plugin is in whiteboard we can do
what you need to do in order to meet your deadlines. I am only saying
what we need to have in order for it to come out of whiteboard. So, as
long as we are moving towards a processing pipeline as defined in our TR
we can cut corners in the short term.
>>documentation: isn't this the same as site?
>
>
> hmmm, yes. Not sure why I mentioned it twice.
:-))
Ross
Re: SmartSlides Input PlugIn (aka SlidyPlugin)
Posted by Ferdinand Soethe <fe...@apache.org>.
Ross Gardler wrote:
> site: I don't see this as the case, your input plugin takes your new
> schema and creates our internal format, so only documents the new
> schema, there is no need to document what it is converted into internally.
No, but I'd basically have two sites with the same examples and docs.
> grammar: why is this needed on the output side? The output plugin should
> only work with our internal format.
Well no. My last conclusion of our discussion was that the output
plugin will transform my new schema to the final slidy output.
Main reason for this being that I saw no way of transporting
all the data from my grammar through the limitations of docVxx.
Later on there will be two transformations in the output plugin
smartslides --> slidy
xhtml --> slidy
> documentation: isn't this the same as site?
hmmm, yes. Not sure why I mentioned it twice.
--
Ferdinand Soethe
Re: SmartSlides Input PlugIn (aka SlidyPlugin)
Posted by Ross Gardler <rg...@apache.org>.
Ferdinand Soethe wrote:
> OK, I've commited part 1, the input plugin for now to learn about
> connecting the grammar properly.
>
> SmartSlides is about creating smart presentations using a specialized
> grammar that guides the users through the creation process.
>
> I've renamed it to 'SmartSlides' since 'Slidy' is really only a small part of it
> all and will only play a role in the output-plugin.
>
> At this point the ant test fails because
> the presentation example document cannot be verified.
I have no idea about relaxNG I'm afraid.
> Btw: Is there a way around having to create yet another plugin for the
> output as a slidy presentation. It will create so much redundand code
> (example site, grammar, documentation) that it would really be much
> nicer if I could create it as an inAndOutputPlugin.
It is possible to "cheat" the plugin system and have a plugin that does
both input and output. However, there are very good reasons for not
doing this, most importantly separation of concerns, a plugin should
only do one job, input, or output. This makes it much easier to maintain
and resuse code.
Looking at your examples of redundant code:
site: I don't see this as the case, your input plugin takes your new
schema and creates our internal format, so only documents the new
schema, there is no need to document what it is converted into internally.
grammar: why is this needed on the output side? The output plugin should
only work with our internal format.
documentation: isn't this the same as site?
Ross
Re: SmartSlides Input PlugIn (aka SlidyPlugin)
Posted by Ferdinand Soethe <fe...@apache.org>.
btw: I have deliberately not used location path in the plugin yet as I
wanted it to be available for version 7 as well.
--
Ferdinand Soethe
SmartSlides Input PlugIn (aka SlidyPlugin)
Posted by Ferdinand Soethe <fe...@apache.org>.
OK, I've commited part 1, the input plugin for now to learn about
connecting the grammar properly.
SmartSlides is about creating smart presentations using a specialized
grammar that guides the users through the creation process.
I've renamed it to 'SmartSlides' since 'Slidy' is really only a small part of it
all and will only play a role in the output-plugin.
At this point the ant test fails because
the presentation example document cannot be verified.
Btw: Is there a way around having to create yet another plugin for the
output as a slidy presentation. It will create so much redundand code
(example site, grammar, documentation) that it would really be much
nicer if I could create it as an inAndOutputPlugin.
--
Ferdinand Soethe
Re: Slidy-Plugin - where to put grammar files
Posted by David Crossley <cr...@apache.org>.
Ferdinand Soethe wrote:
>
> I need to install a new grammar for the plugin source files, but I'm
> unclear where it should go. Also, it has to be relax-ng
> (preferred) or schema to support all the features, is that a problem?
Well RNG is what we would all prefer isn't it.
Without seeing the rest of it, i will make a guess
at what we need.
We have established ways for source documents to declare
DTDs and we can detect and handle such documents and
associated resources. The DTDs can be either in the core,
or in plugins, or supplied by each project.
There are other methods using the Content Aware Pipelines
SourceTypeAction [1]. Rather than depending on the case of
which DOCTYPE, we use the document element and namespace,
or other methods.
With DTDs, the actual DTDs are required to be be present
for the actual parsing of the source. With RELAX NG, the
grammars are separate.
We can have validating components in our sitemap pipelines
if we so choose, or have them as separate pipelines. [2]
So where to store the grammars.
We have core grammars at
main/webapp/resources/schema/relaxng/
For plugins we have resources/schema/
Add more structure if needed.
If you use validation transformers in the sitemaps
then refer to these resources via the plugin's
locationmap.
Would that be sufficient?
Later we might find ways to obtain remote grammars
so that we don't need to redistribute. Not yet.
Keen to see this plugin, and the use of RELAX NG.
Please commit it so that we can all help.
Don't try to get it all perfect beforehand. :-)
[1] http://forrest.apache.org/docs/dev/cap.html
[2] http://marc.theaimsgroup.com/?l=forrest-dev&m=112598308027438
-David
Re: Slidy-Plugin - where to put grammar files
Posted by Ferdinand Soethe <fe...@apache.org>.
I need to install a new grammar for the plugin source files, but I'm
unclear where it should go. Also, it has to be relax-ng
(preferred) or schema to support all the features, is that a problem?
Thanks,
--
Ferdinand Soethe