forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ferdinand Soethe <>
Subject Re: SmartSlides Input PlugIn (aka SlidyPlugin)
Date Sat, 12 Nov 2005 17:28:10 GMT

>>>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
>>   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

View raw message