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.
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.
(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.
Ross
