On 12/2/05, Ross Gardler <[EMAIL PROTECTED]> wrote: > Tim Williams wrote: > > On 12/2/05, Ross Gardler <[EMAIL PROTECTED]> wrote: > > > >>Tim Williams wrote: > >> > >>>On 12/2/05, Thorsten Scherler <[EMAIL PROTECTED]> wrote: > >>> > >>> > >>>>Hi all, > >>> > >>> > >>>I've unfortunately been too busy to properly keep up with all of your > >>>progress so this may not be worth much. > >>> > >>> > >>> > >>>>lately we proposed a new attribute @element for the forrest:hook > >>>>element. Now it is possible to have any markup as hook. > >>> > >>> > >>>I didn't catch this but now that I understand it, it makes me think > >>>that we might be letting our templating language make too many > >>>assumptions about the output (e.g. that it is markup). Same thing for > >>>the new hooksXPath attribute. How are these supportive of non-markup > >>>output formats like text/rtf? > >> > >>This is markup to create an internal representation of the document for > >>later output. RTF is generated from XSL/FO (markup) and text is from our > >>internal document format (markup). > >> > >>We are an XML publishing framework, it is fair to assume everything we > >>publish will, at some point in the lifecycle, be markup ;-) > > > > > >>From your comments, I gather I'm missing something. I think of these > > *.fv as output not internal format. They are manipulating the > > internal format to produce a certain output, thus the need for the > > @type on view element. Of course, it's fair to assume the internal > > will be markup but why have a type attribute on a view if it cannot be > > anything other than markup? From my understanding some of these > > markup-related attributes (e.g. hooksXPath, element) don't make sense > > to me when @type != html/xml. > > In order to get a non-XML output from Forrest you have to go via the > internal structure. That is the power of Forrest: > > many inputs -> many outputs. > > To manage the complexity of this we provide an internal format, > therefore only need to provide a single input transformation for each > input and a single output transformation for each desired output format.
yes I do have a vague grasp of how forrest operates. > The structurer does not, IMHO, change that. If that is the intention > then it raises some very serious concerns in my mind. Thorsten, can you > clarify your own thoughts here. Yowsers, I must not be typing with clarity today. I'm not suggesting that Thorsten has any intention different than the srcformat->internalformat->outputformat that we have today. I suppose instead of confusing the issue further, I'll just ask as simple question: Once we're in a V2 world, what is the essence of an output plugin? I assumed that, for example, instead of document2text.xsl, we'd have text.fv. [potentially combine your answer with my question below] > (NOTE: Thorsten has a design goal of making Views independant of > Forrest, so your concerns may be valid, but not from the perspective of > Forrest where we are only relly interested in our internal format.) > > >>>>- would it not be sufficient to have forrest:view and forrest:contract? > >>> > >>> > >>>If you had two contracts that needed the same output style how could > >>>you do it without having a hook to contain them? > >> > >>In use, a single contract provides a single output style. There may be > >>multiple implementations of the contract for different outputs but only > >>one is used at any one time. > >> > >>That is, if you want two different outpus, you will have two different > >>views, one for each output. > > > > > > I mean two different contracts that were to be bound together on the > > output (e.g. nav-section and search-input). For output purposes they > > need to be "contained" together somehow -- accomplished through a > > hook->div right now (or at least it was). > > As I understand Thorstens proposal, each contract defines where it > appears in the views ouptut document (potentially distinct from the > Forrest output document). That doesn't change, ony the way of defining > how this location is defined will change. Why would a contract define it's position in the output? That would make contracts much less re-usable I'd think. Seems to me they should be context indepedent. That seemed to be where Thorsten was heading by wanting to remove the head/body booleans I think. The xpath insertion points should be in the view (*fv) rather than the contract. Anyway,along with my question above, how is a view output document potentially distinct from the forrest output doc? Views is creating the forrest output doc as I understand it -- i think the answer to this and my question above will clear a lot up for me. Thanks, --tim
