Return-Path: 
 <dev-return-13813-apmail-forrest-dev-archive=forrest.apache.org@forrest.apache.org>
Delivered-To: apmail-forrest-dev-archive@www.apache.org
Received: (qmail 82874 invoked from network); 14 Nov 2004 18:45:07 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur-2.apache.org with SMTP; 14 Nov 2004 18:45:07 -0000
Received: (qmail 28174 invoked by uid 500); 14 Nov 2004 18:45:07 -0000
Delivered-To: apmail-forrest-dev-archive@forrest.apache.org
Received: (qmail 28143 invoked by uid 500); 14 Nov 2004 18:45:06 -0000
Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@forrest.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@forrest.apache.org>
list-post: <mailto:dev@forrest.apache.org>
Reply-To: dev@forrest.apache.org
Delivered-To: mailing list dev@forrest.apache.org
Received: (qmail 28132 invoked by uid 99); 14 Nov 2004 18:45:06 -0000
X-ASF-Spam-Status: No, hits=0.5 required=10.0
	tests=DNS_FROM_RFC_WHOIS,FORGED_RCVD_HELO,SPF_HELO_PASS
X-Spam-Check-By: apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Received: from [196.25.240.76] (HELO ctb-mesg4.saix.net) (196.25.240.76)
  by apache.org (qpsmtpd/0.28) with ESMTP; Sun, 14 Nov 2004 10:45:03 -0800
Received: from sean.site (ndn-75-166.telkomadsl.co.za [165.165.75.166])
	by ctb-mesg4.saix.net (Postfix) with ESMTP id 50789AA0A
	for <dev@forrest.apache.org>; Sun, 14 Nov 2004 20:44:54 +0200 (SAST)
From: Sean Wheller <sean@inwords.co.za>
Reply-To: sean@inwords.co.za
Organization: In Words
To: dev@forrest.apache.org
Subject: Re: Selective PDF
Date: Sun, 14 Nov 2004 20:40:45 +0200
User-Agent: KMail/1.6.2
References: <200411141149.20071.sean@inwords.co.za>
 <200411141851.18331.sean@inwords.co.za> <4197984E.2030502@apache.org>
In-Reply-To: <4197984E.2030502@apache.org>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200411142040.45330.sean@inwords.co.za>
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

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.

<element>
	Applied to all siblings. No output formats
</element>

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

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

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

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

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

<site output="all">
...
</site>

<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
</element>
</site>

>
> 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 
@href="http://some.url/filename.html"

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
sean@inwords.co.za
http://www.inwords.co.za