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