Ferdinand Soethe wrote:
Ross Gardler wrote:
site: I don't see this as the case, your input plugin takes your new
schema and creates our internal format, so only documents the new
schema, there is no need to document what it is converted into internally.
No, but I'd basically have two sites with the same examples and docs.
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.
grammar: why is this needed on the output side? The output plugin should
only work with our internal format.
Well no. My last conclusion of our discussion was that the output
plugin will transform my new schema to the final slidy output.
No, that was not what I meant. All processing should go through our
intermediate format otherwise we lose the many inputs to many outputs stuff.
Input -> XSL -> internal format -> xsl -> output format
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.
Later on there will be two transformations in the output plugin
smartslides --> slidy
No - that breaks our processing definition in our TR
xhtml --> slidy
if you mean XHTML2 and are referring to the future internal format OK.
Otherwise, no for the same reason.
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.
documentation: isn't this the same as site?
hmmm, yes. Not sure why I mentioned it twice.
:-))
Ross
