Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <41C0E752.4050003@apache.org>
Date: Thu, 16 Dec 2004 01:39:30 +0000
From: Ross Gardler <rgardler@apache.org>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
MIME-Version: 1.0
To: dev@forrest.apache.org
Subject: Re: search engine friendly skins
References: <cpn4gr$c0e$1@sea.gmane.org> <41BF2A28.4080509@apache.org>
 <cpneis$c6e$1@sea.gmane.org>
In-Reply-To: <cpneis$c6e$1@sea.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Glen Tulukin wrote:
> "Ross Gardler" <rgardler@apache.org> wrote in message
> news:41BF2A28.4080509@apache.org...
> 
>>Glen Tulukin wrote:

...

>>All this is meta-data and is something that needs consideration. There
>>are many different views on how one should store meta-data, How do you
>>propose storing this information?
> 
> 
> Header has metas.
> <!ELEMENT header (title, subtitle?, version?, type?, authors?, *, abstract?,
> meta* %local.headers;)>
> I suggest to use metas for window title and keywords. Basically, meta is
> name and value (see document-v20.mod) if I understand it correctly.

I see no problem with that in the short term, longer term meta-data 
needs to be in a separate file, at least for my own use case. However, 
when I come to implement that use case I can always add that functionality.

>>With respect to keywords are you proposing automatic generation of those
> 
> keywords?
> 
> No.

Shame, but that can come later. As long as you don't expect authors to 
add tags around keywords in their text (i.e. it is just more meta-data), 
then it would certainly be good to have.

> The doc authors should think ahead which keywords she needs to use in
> the text. For example, if the author writes gw_doc.xml about widgets for
> geeks she associates two keywords "widget" and "geek" as meta-data for this
> document. SE-friendly report should show summary that in the gw_doc xdoc the
> word "widget" is used 10 times and "geek" 5 times, both used in the
> html/meta/title and section titles. Think about keywords as a part of
> document plan, as points to score.

Yes, that is exactly what I was thinking aboute with auot-generation of 
keywords.

>>>- SE - friendly generated linkmap.xml. Usually it's not a good idea to
>>>submit home page to yahoo, it should be well-thought site map (what
> 
> other
> 
>>>non-Cocoon people understand under site map)
>>
>>What is the difference between your proposed linkmap.xml and the existing
> 
> linkmap.xml?
> SE rates a link depending on the surrounding context. I suggest to put
> keywords next to the link to increase rating. So each link will have
> meaningful context. For a human being to see links with keywords may be not
> the best document but the proposed linkmap is intended for SEs.

Would it be possible to enhance the existing linkmap to do this? Does it 
make sense to have a separate one?

>>>- link pages (have to exchange links in order to have links to yourself)
>>>etc. etc. -- you've got idea.
>>
>>How do these differ from a page with links on it?
> 
> IMHO, easier to keep links in a simple xml and apply xslt rather than edit
> xdoc manually with tr/td. It will require a custom xmap but it should not be
> a big deal. Btw, can a skin somehow notify Forrest that it needs an entry in
> the custom project xmap? I see that Forrest allows to plug in skins from any
> URL.

OK, I'm not convinced of the need for this, but if you have a use case 
then who am I to question it. This sounds like an ideal candidate for an 
input plugin.

This all sounds like good enhancements to me.

Ross