forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: SmartSlides Input PlugIn (aka SlidyPlugin)
Date Sat, 12 Nov 2005 11:58:10 GMT
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

Mime
View raw message