forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ferdinand Soethe <ferdin...@apache.org>
Subject Re: SmartSlides Input PlugIn (aka SlidyPlugin)
Date Sat, 12 Nov 2005 09:56:53 GMT


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


Mime
View raw message