Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: pass (hermes.apache.org: domain of
 cjxaf-forrest-dev-1@m.gmane.org designates 80.91.229.2 as permitted sender)
To: dev@forrest.apache.org
From: "Glen Tulukin" <glen@iteclectic.com>
Subject: Re: search engine friendly skins
Date: Tue, 14 Dec 2004 14:22:54 -0500
Lines: 87
Message-ID: <cpneis$c6e$1@sea.gmane.org>
References: <cpn4gr$c0e$1@sea.gmane.org> <41BF2A28.4080509@apache.org>
Sender: news <news@sea.gmane.org>


"Ross Gardler" <rgardler@apache.org> wrote in message
news:41BF2A28.4080509@apache.org...
> Glen Tulukin wrote:
> > To name few features I am working on (or already have done but in
process of
> > porting from 0.5 to 0.6):
>
> You'd be mich better off doing this in 0.7 if your intention is that
> your changes end up in Forrest code bae. There are considerable changes
> in directory structure between 0.6 and 0.7 which means any patches you
> provide against 0.6 will be difficult for us to apply.
Sure, I am in 0.7 and do daily updates fron SVN repository. Our production
version is in 0.6.

> > - separate Window title and the doc title (html/meta/title and
> > document/header/title). Now it's the same, but it's not good for SE
> > - concept of a keyword -- a doc has a hidden element that lists keywords
and
> > those keywords must be used in the doc frequently enough, closer to the
> > beginning of the page and preferably in the h1, h2 elements
> > - consolidated keyword / title report for each page
>
> 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.

Previously I switched of xdoc validation and did with the xdoc whatever I
wanted but now the project has a designated content author with XML Spy and
linked document-v20.dtd, so I have to switch validation back on.

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

No. 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.

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

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

>
> > I follow recommendations from www.searchenginewatch.com (and by the way
if
> > you can suggest any other sites -- I'll appreciate).
> >
> > If you think it's something people might need I am willing to contribute
to
> > the project.
>
> My questions are meant to encourage not to discourage. I think the basic
> ideas you propose are great, we just need to think about how they fit in
> with the existing Forrest model of things.
Thanks for welcoming :-).