forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Wheller <>
Subject Re: Selective PDF
Date Sun, 14 Nov 2004 18:40:45 GMT
On Sunday 14 November 2004 19:39, Ross Gardler wrote:
> Sean Wheller wrote:
> > Is it not easier to define an attribute such as "output" and add it to
> > elements in site.xml and tabs.xml. The values can be on error more of the
> > following: output="all,ps,rtfpdf,pod"
> Yes, this is a good idea, this is similar to the meta-data idea but it
> feels like a more logical place to put it.
> The only problem I see is that it requires us to specify when we *do*
> want something, rather than when we *don't*. This is a problem for two
> reasons, firstly it is more likely that we will want the various output
> forms (and so we are increasing the typing required in most cases),
> secondly, it requires us to know in advance what output formats will be
> available.

	Applied to all siblings. No output formats

	Applied to all siblings. No output formats
	<sibling output="pdf"/>
	Inherit value of parent and do pdf

<element output="rtf,pod,pdf">
	Applied to all siblings

<element output="rtf,pdf">
	Applied to all siblings
	<sibling output="pod"/>
	Inherit value of parent and do pod

<element output="all">
	Do transformation to all known formats. Applied to all siblings

I think the level of control far out weighs the overhead of some extra typing.
We may also consider

<site output="all">

<site output="pdf">
<element output="rtf">
	Inherit value of parent and do rtf to all siblings
	<sibling output="pod"/>
	Inherit value of parent and ancestor and do pod

> This latter point is relevant if we consider sharing documentation
> created with Forrest.

The objective is "sharing documentation," not to "sharing application."

If the focus is documentation then the source is XML. It should be 
presentation neutral. The formats are something for the application layer of 
your app to decide. As a result I do not favor adding output data into the 
meta of documents.

> Say I want to use a site you have built, but I 
> also want to provide SpeechML versions. I have to actually edit you
> site.xml file to do this, but I can't because I don't have write access.

If you say you want site.xml, then you want whole or part of the structure. In 
which case you have to ask yourself, will the remote structure suits your 
local structure?

In most cases the answer is no. So you need XInclude in order to bring in the 
part or piece of structure you need and fits to your local structure. Now 
XInclude brings in the node and its siblings warts and all. So you will by 
default get @output if the @ is specified.

Next problem. @href="filename.html" included from the remote is now a dead 
link since filename.xml is not local. To make it active you need 

Meaning? You need to modify. So you now need a method to include from remote 
and overide.

Which ever way you will 90% need to modify.

> (note, this is still a problem with each of the suggestions I made)
> The former point is easily addressed by specifying that all output
> formats are provided if the output attribute is not set.

That's six of this and half-a-dozen of the other :-)

Sean Wheller
Technical Author

View raw message