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
