Outline FOAF plugin

On 06/06/07, Oshani Seneviratne <oshaniapache.org> wrote:
> I have created an outline FOAF plugin and attached the
patch to a JIRA issue
> FOR-1002 [1] . I would really appreciate if my
mentor/co-mentor or any one
> of the Forrest developers could take a look at it and
comment.

Fantastic, well done Oshani. I will have time to look over
this later
today if Gav or someone else does not beat me to it.

> As the first step, I simply wrote an xsl to extract the
plain XML data out
> of a FOAF document. The idea was to read through a
*single* FOAF document
> and generate all the person details and index those in
a single page.
> There's nothing fancy in this yet: in fact, I didn't
consider much of the
> semantics of FOAF. Only used just the basic terms such
as foaf:person,
> foaf:knows, etc.

This is exactly what we need to get us started. In open
source release
early, release often is very important. Early feedback means
that
improvements can be made quickly and easily. Don't be afraid
of
committing things that may not be perfect, or even things
with known
issues. As long as the known issues are documented that is
fine.

> For the next development step, I believe we could
create multiple pages with
> multiple FOAF files which could be either related (with
a foaf:knows
> relationship) or unrelated, and possibly enhance the
number of
> transformations of the FOAF semantics in the xsl.
Anyway, I would like to
> hear your comments on this and any other possible
enhancements that we could
> do.

I think your proposal is a good one with respect to
progression.

Thinking about your plugins wider use, the DOAP standard
uses FOAF to
record maintainer, translator and developer information. It
would be
interesting to see how your FOAF and the DOAP plugin would
play
together. That is have the DOAP plugin use your FOAF plugin
to render
the FOAF info in DOAP files.

One caveat here, Forrest does not support dependencies
between
plugins. For now we need not worry about this, as we are
planning to
switch to an IVY build management system for plugins and
that will
address the issue. However, if you move forward to this step
you
should add an entry in the issue tracker to remind us of
this
dependency.

A second caveat is that since we have not done any
dependencies
between plugins before there is no documentation on how to
do it. So
you'll probably want to float the idea here before tackling
it.

> While developing this initial version of the plugin, I
came across few
> forrest specific problems.I apologize if these have
been answered before (I
> did go through much of Forrest's code, checked almost
all of Forrest's
> documentation and the mail archives but was not able to
find the answers.)
> They are not major problems, however I would like to
get them clarified:
>
> For instance,
>
> 1. After seeding the plugin and after doing all the
configurations as
> advised in [2], I did 'forrest run'... only to find
that it failed because
> the plugin descriptor was not to be found.
>
> So, as a workaround, I did the following:
>   Copied a plugins.xml file to the foaf plugin dir
> (FORREST_HOME/whiteboard/plugins/o.a.f.p.i.foaf)
>   Added a new plugin entry there for the FOAF plugin
>   Added '
>
forrest.plugins.descriptors=file:///${project.home}/plugins.
xml'
> in to the forrest.properties file.
>
> After this, it did not complain about any missing
plugin descriptors.
> So, my question is, is this the expected way of letting
the forrest build
> know about a new plugin (at least until the plugin is
registered in the
> official plugin descriptor files)?

That is an oversight in the documentation, it would be good
if you
could provide a patch to the docs.

In this case you can add your entry directly to the
whiteboard
plugins.xml file as we will certainly be accepting your
plugin into
the whiteboard.

If you were not donating this to the project then you would
need to
create a local plugins.xml file and reference it in the
forrest.properties file as you have done. However, you would
need to
ensure existing plugins.xml files were also referenced.

> 2. When I ran the 'ant test' target against the plugin,
it failed saying
> that there are broken links in the site. I found the
culprit to be a couple
> of rdf:ID and  rdf:resource elements I embedded in the
xsl.
>
>  For example,  there's the following line in the
foaf-to-document.xsl
>  <a href="{foaf:homepage/rdf:resource}"><xsl:value-of
> select="foaf:homepage/rdf:resource"/></a>
>
>  When Forrest renders this link it leads to a relative
path like
> "http://localhost:8888/homepage_url_given_in_foaf:homep
age/rdf:resource".
>  How can we make it absolute, so that it will be linked
to
> "homepage_url_given_in_foaf:homepage/rdf:resource" and not
> the relative url as in above?

I'll need to look at this in the code to see exactly what
is
happening, I understand the question, but not the context at
present.
perhaps you should raise an issue about this. I just added a
new
"Plugin: input.FOAF" component to JIRA for you.

> 3.I was able to see the transformation I intended with
the xsl at
> http://localh
ost:8888/personDetails.xml (in one of these
> forrest's internal doc forms I believe). However, when
I point my browser to
> http://local
host:8888/personDetails.html, I could only see
> a blank page with the default forrest skin applied. The
content was missing!
> Now, how is this page generated? Is the
> FORREST_HOME/main/webapp/sitemap.xmap responsible for
> generating this html page?

Yes. The document at [3] should help understand the process,
in
particular see the section "Understanding the
HTML-Pipeline"

> More importantly, what changes should I make to get
those content from the
> transformed FOAF into that html?

This depends on why it is not being rendered. The fact you
see a
result from the *.xml request is good. I'm guessing that
there is a
problem with the doctype or something like that. Again, it
will
probably be easier to answer your question when I look at
the code.
Create an issue for this please.

>  4. This could be a very silly question, but thought
I'd ask anyway... Would
> you advice against making changes to the plugin source
within the build dir,
> once it is locally deployed in the
FORREST_HOME/build/plugins? I ask
> because, I found it much more convenient to make
changes from the build dir,
> rather than from
> FORREST_HOME/whiteboard/plugins/o.a.f.p.i.foaf, do
'ant
> local-deploy' and then do 'forrest run' after each and
every change. 

I would advise against it, there is a potential to forget to
copy the
changes back. I've lost many hours this way in the past.

What I do is have a shell window open that I use for
deploying the
plugin, thus the deploy process is just "CTRL-TAB ->
up arrow ->
return"

Pretty soon it becomes second nature.

Alternatively, if you use an IDE you could add it as a build
step, so
that whenever you save a file it gets deployed.

> Also, I think I should mention that, although I looked
in to the possibility
> of using dispatcher with this initial outline plugin, I
am afraid I did not
> make much progress with that. Hopefully, in the coming
weeks I would be able
> to understand how to use it. Until then I am going to
experiment a bit and
> learn more. Any hints on how to get up to speed with
dispatcher with this
> plugin will be appreciated!

I'd say ignore the dispatcher for now. It is not a simple
beast, but
you can do many things with it that you can't do with plain
skins.
When you hit that problem then we'll look at the
dispatcher.

Ross

>  [1] https:
//issues.apache.org/jira/browse/FOR-1002
> [2]
> http://forrest.apache.org/docs_0_90/howto/howto-
buildPlugin.html
>

[3] http:
//forrest.apache.org/docs_0_90/howto/howto-custom-html-sourc
e.html#Understanding%20the%20HTML-Pipeline

Thanks Oshani, I have committed this initial code to the
whiteboard.
I will take a good look at it and test drive it over the
next day or two
and answer what I can then.

As a side issue, your emails are coming through in HTML,
plain text would
be better for the archivers and for quoting.

Thanks Again, initial glance looks good!

Gav...

________________________________________
From: oshanisgmail.com [mailto:oshanisgmail.com] On Behalf Of Oshani
Seneviratne
Sent: Wednesday, 6 June 2007 2:22 PM
To: Forrest Developers List
Subject: Outline FOAF plugin

Hi,

I have created an outline FOAF plugin and attached the patch
to a JIRA issue
FOR-1002 [1] . I would really appreciate if my
mentor/co-mentor or any one
of the Forrest developers could take a look at it and
comment. 

As the first step, I simply wrote an xsl to extract the
plain XML data out
of a FOAF document. The idea was to read through a *single*
FOAF document
and generate all the person details and index those in a
single page.
There's nothing fancy in this yet: in fact, I didn't
consider much of the
semantics of FOAF. Only used just the basic terms such as
foaf:person,
foaf:knows, etc. 

For the next development step, I believe we could create
multiple pages with
multiple FOAF files which could be either related (with a
foaf:knows
relationship) or unrelated, and possibly enhance the number
of
transformations of the FOAF semantics in the xsl. Anyway, I
would like to
hear your comments on this and any other possible
enhancements that we could
do. 


While developing this initial version of the plugin, I came
across few
forrest specific problems.I apologize if these have been
answered before (I
did go through much of Forrest's code, checked almost all of
Forrest's
documentation and the mail archives but was not able to find
the answers.)
They are not major problems, however I would like to get
them clarified:

For instance,

1. After seeding the plugin and after doing all the
configurations as
advised in [2], I did 'forrest run'... only to find that it
failed because
the plugin descriptor was not to be found. 

So, as a workaround, I did the following:
  Copied a plugins.xml file to the foaf plugin dir
(FORREST_HOME/whiteboard/plugins/o.a.f.p.i.foaf)
  Added a new plugin entry there for the FOAF plugin
  Added '
forrest.plugins.descriptors=file:///${project.home}/plugins.
xml'
in to the forrest.properties file. 

After this, it did not complain about any missing plugin
descriptors.
So, my question is, is this the expected way of letting the
forrest build
know about a new plugin (at least until the plugin is
registered in the
official plugin descriptor files)? 


2. When I ran the 'ant test' target against the plugin, it
failed saying
that there are broken links in the site. I found the culprit
to be a couple
of rdf:ID and  rdf:resource elements I embedded in the
xsl. 

For example,  there's the following line in the
foaf-to-document.xsl
<a href="{foaf:homepage/rdf:resource}"><xsl:value-of
select="foaf:homepage/rdf:resource"/></a>

When Forrest renders this link it leads to a relative path
like
"http://localhost:8888/homepage_url_given_in_foaf:homep
age/rdf:resource".
How can we make it absolute, so that it will be linked to
"homepage_url_given_in_foaf:homepage/rdf:resource" and not the relative url
as in above?


3.I was able to see the transformation I intended with the
xsl at
http://localh
ost:8888/personDetails.xml (in one of these forrest's
internal
doc forms I believe). However, when I point my browser to
http://local
host:8888/personDetails.html, I could only see a blank
page with
the default forrest skin applied. The content was missing!
Now, how is this
page generated? Is the FORREST_HOME/main/webapp/sitemap.xmap
responsible for
generating this html page? 
More importantly, what changes should I make to get those
content from the
transformed FOAF into that html?


4. This could be a very silly question, but thought I'd ask
anyway... Would
you advice against making changes to the plugin source
within the build dir,
once it is locally deployed in the
FORREST_HOME/build/plugins? I ask
because, I found it much more convenient to make changes
from the build dir,
rather than from
FORREST_HOME/whiteboard/plugins/o.a.f.p.i.foaf, do 'ant
local-deploy' and then do 'forrest run' after each and every
change.  


Also, I think I should mention that, although I looked in to
the possibility
of using dispatcher with this initial outline plugin, I am
afraid I did not
make much progress with that. Hopefully, in the coming weeks
I would be able
to understand how to use it. Until then I am going to
experiment a bit and
learn more. Any hints on how to get up to speed with
dispatcher with this
plugin will be appreciated! 


[1] https:
//issues.apache.org/jira/browse/FOR-1002
[2] http://forrest.apache.org/docs_0_90/howto/howto-
buildPlugin.html


Thanks,
Oshani.

On 06/06/07, Ross Gardler <rgardlerapache.org> wrote:
> On 06/06/07, Oshani Seneviratne <oshaniapache.org> wrote:
> > I have created an outline FOAF plugin and attached
the patch to a JIRA issue
> > FOR-1002 [1] . I would really appreciate if my
mentor/co-mentor or any one
> > of the Forrest developers could take a look at it
and comment.
>
> Fantastic, well done Oshani. I will have time to look
over this later
> today if Gav or someone else does not beat me to it.

OK, Gav committed your code, here are my comments (I'm being
picky,
it's the code I'm talking about, not your work. Unless we're
picky
you'll never pick up on the best practice we have developed
over the
years. If the reasoning for something doesn't make sense
please be
sure to ask about it. Most of what we do should be sensible,
but you
may be able to help us improve these processes.

Firstly, and perhaps most importantly, you must keep
status.xml up to
date. There are a number of reasons for this:

- it's how we generate the changes file and that's how our
users
figure out whether or not to upgrade
- it's how you and other developers are credited with
contribution to the plugin
- it's how developers understand what is happening in the
code
- it forms part of the documentation (especially at release
time)

Secondly, I'm afraid I couldn't get it to work. First off,
your
forrest.properties file indicated that the dispatcher
plugins were to
be used, yet there was no definition of the dispatcher theme
to be
used. you mention that you had problems with dispatcher and
were now
working with the dispatcher. So I removed these entries.

I then found that there was a full duplication of all
content in most
files. Looking at the patch you supplied this duplication
was created
when you created the diff. I'm not sure how you managed
this, I've
never seen it before. But you should get into the habit of
reading the
diff before submitting it (and to be fair Gav made a mistake
in
committing it without reviewing it properly - that's our job
as
committers).

I went through and tidied these files up and committed
them.

In summary - more attention to detail before submitting
would save
other committers plenty of time.

You should keep a sharp eye on commits to the DOAP plugin.
I'll be
making some core design changes when I get the time to do
so. Whenever
you feel these changes are applicable to your FOAF plugin
you should
follow these changes. The changes are based on experience
using the
DOAP plugin in production. If you think they are a bad move
then
please speak up.

Now, to your specific questions...

> > So, my question is, is this the expected way of
letting the forrest build
> > know about a new plugin (at least until the plugin
is registered in the
> > official plugin descriptor files)?
>
> That is an oversight in the documentation, it would be
good if you
> could provide a patch to the docs.
>
> In this case you can add your entry directly to the
whiteboard
> plugins.xml file as we will certainly be accepting your
plugin into
> the whiteboard.

I've committed this to SVN. It would be really good if you
could
clarify the documentation for us.

(are you subscribed to the svnforrest? [4] you should be
so that you
can see updates we make to your code)

> > 2. When I ran the 'ant test' target against the
plugin, it failed saying
> > that there are broken links in the site. I found
the culprit to be a couple
> > of rdf:ID and  rdf:resource elements I
embedded in the xsl.
> >
> >  For example,  there's the following line in the
foaf-to-document.xsl
> >  <a href="{foaf:homepage/rdf:resource}"><xsl:value-of
> > select="foaf:homepage/rdf:resource"/></a>
> >
> >  When Forrest renders this link it leads to a
relative path like
> > "http://localhost:8888/homepage_url_given_in_foaf:homep
age/rdf:resource".
> >  How can we make it absolute, so that it will be
linked to
> > "homepage_url_given_in_foaf:homepage/rdf:resource" and not
> > the relative url as in above?
>
> I'll need to look at this in the code to see exactly
what is
> happening, I understand the question, but not the
context at present.
> perhaps you should raise an issue about this. I just
added a new
> "Plugin: input.FOAF" component to JIRA for
you.

OK, I see the problem now:

<foaf:schoolHomepage
rdf:resource="www.cse.mrt.ac.lk"/>

This is not valid as far as I am aware. I believe an
rdf:resource must
be a URI, which must include a scheme (i.e. http) (I'm no
RDF expert
though). See [6]

> > 3.I was able to see the transformation I intended
with the xsl at
> > http://localh
ost:8888/personDetails.xml (in one of these
> > forrest's internal doc forms I believe). However,
when I point my browser to
> > http://local
host:8888/personDetails.html, I could only see
> > a blank page with the default forrest skin
applied. The content was missing!
> > Now, how is this page generated? Is the
> > FORREST_HOME/main/webapp/sitemap.xmap responsible
for
> > generating this html page?
>
> Yes. The document at [3] should help understand the
process, in
> particular see the section "Understanding the
HTML-Pipeline"
>
> > More importantly, what changes should I make to
get those content from the
> > transformed FOAF into that html?

First observation is that your XDoc returned by
http://localh
ost:8888/personDetails.xml is not a valid XDoc file.
For
example, it includes <h1> elements which are not valid
- see [5].

Secondly, it is given the namespace of http://www.w3.org/1999/x
html,
which is obviously incorrect. This is because your XSL uses
a defaul
XHTML namespace.

Ross

> >  [1] https:
//issues.apache.org/jira/browse/FOR-1002
> > [2]
> > http://forrest.apache.org/docs_0_90/howto/howto-
buildPlugin.html
> >
>
> [3] http:
//forrest.apache.org/docs_0_90/howto/howto-custom-html-sourc
e.html#Understanding%20the%20HTML-Pipeline


[4] http:
//forrest.apache.org/mail-lists.html#Lists
[5] http://forrest.apache.org/dtdx/document-v20.dtdx.html
[6] http://en.wikipedia.org/wiki/Uniform_Resource_Identifier

Ross Gardler wrote:
>
> Firstly, and perhaps most importantly, you must keep
status.xml up to
> date. There are a number of reasons for this:
> 
> - it's how we generate the changes file and that's how
our users
> figure out whether or not to upgrade
> - it's how you and other developers are credited with
contribution to the 
> plugin
> - it's how developers understand what is happening in
the code
> - it forms part of the documentation (especially at
release time)

Likewise it is important to also add an entry to the
top-level
site-author/status.xml to alert to Oshani's contribution.
This gets the contributor's name into the general release
notes.

I just now followed up to do that.

As Ross said, general changes for this plugin go into its
local status.xml file.

-David

On 07/06/07, David Crossley <crossleyapache.org> wrote:
> Ross Gardler wrote:
> >
> > Firstly, and perhaps most importantly, you must
keep status.xml up to
> > date. There are a number of reasons for this:
> >
> > - it's how we generate the changes file and that's
how our users
> > figure out whether or not to upgrade
> > - it's how you and other developers are credited
with contribution to the
> > plugin
> > - it's how developers understand what is happening
in the code
> > - it forms part of the documentation (especially
at release time)
>
> Likewise it is important to also add an entry to the
top-level
> site-author/status.xml to alert to Oshani's
contribution.
> This gets the contributor's name into the general
release notes.
>
> I just now followed up to do that.
>
> As Ross said, general changes for this plugin go into
its
> local status.xml file.

Thanks David, both Gav and I should have picked up on that -
the
strength of many eyes.

Ross

Hi Ross,


On 6/7/07, Ross Gardler <rgardlerapache.org> wrote:
> On 06/06/07, Ross Gardler <rgardlerapache.org> wrote:
> > On 06/06/07, Oshani Seneviratne <oshaniapache.org> wrote:
> > > I have created an outline FOAF plugin and
attached the patch to a JIRA issue
> > > FOR-1002 [1] . I would really appreciate if
my mentor/co-mentor or any one
> > > of the Forrest developers could take a look
at it and comment.
> >
> > Fantastic, well done Oshani. I will have time to
look over this later
> > today if Gav or someone else does not beat me to
it.
>
> OK, Gav committed your code, here are my comments (I'm
being picky,
> it's the code I'm talking about, not your work. Unless
we're picky
> you'll never pick up on the best practice we have
developed over the
> years. If the reasoning for something doesn't make
sense please be
> sure to ask about it. Most of what we do should be
sensible, but you
> may be able to help us improve these processes.
>


Your comments are most welcome.


> Firstly, and perhaps most importantly, you must keep
status.xml up to
> date. There are a number of reasons for this:
>
> - it's how we generate the changes file and that's how
our users
> figure out whether or not to upgrade
> - it's how you and other developers are credited with
contribution to the plugin
> - it's how developers understand what is happening in
the code
> - it forms part of the documentation (especially at
release time)
>


Thanks for this advice. Looking at the the status.xml files
elsewhere
and from the documentation I knew that I need to update it.
But I
deferred it altogether until I get the plugin to work.  And
unfortunately forgot to make the changes before submitting.

I assure you that, in my next patch you will see things
other than my
name in the status.xml .


> Secondly, I'm afraid I couldn't get it to work. First
off, your
> forrest.properties file indicated that the dispatcher
plugins were to
> be used, yet there was no definition of the dispatcher
theme to be
> used. you mention that you had problems with dispatcher
and were now
> working with the dispatcher. So I removed these
entries.
> I then found that there was a full duplication of all
content in most
> files. Looking at the patch you supplied this
duplication was created
> when you created the diff. I'm not sure how you managed
this, I've
> never seen it before. But you should get into the habit
of reading the
> diff before submitting it (and to be fair Gav made a
mistake in
> committing it without reviewing it properly - that's
our job as
> committers).
>
> I went through and tidied these files up and committed
them.
>
> In summary - more attention to detail before submitting
would save
> other committers plenty of time.
>


Just now I thoroughly examined the original patch I
submitted
yesterday, and I see what you mean. I wish I had done that
yesterday
itself, instead of giving it a cursory glance just to see
whether all
the files were there. I was only worried about any missing
files, and
was not at all concerned about checking for duplicates!

FWIW, I used TortoiseSVN to create the patch, and I trust it
do the
job well because I have not had any problems in creating
patches with
it in the past. So in this case, these duplicates are a real
mystery
to me too. I am 100% sure that I never added these files
twice before
creating the diff.

Anyway, I am really sorry for the extra trouble and the time
you
wasted on going through my patch. So, next time I would be
extra more
careful before submitting a patch. I will definitely double
check
everything and may be even apply it to a fresh checkout to
see if it
is alright and ready for submission.


> You should keep a sharp eye on commits to the DOAP
plugin. I'll be
> making some core design changes when I get the time to
do so. Whenever
> you feel these changes are applicable to your FOAF
plugin you should
> follow these changes. The changes are based on
experience using the
> DOAP plugin in production. If you think they are a bad
move then
> please speak up.
>


Yes, I will definitely do that. Even for this initial
version of the
FOAF plugin, I learnt quite a lot from the DOAP plugin.


> Now, to your specific questions...
>
> > > So, my question is, is this the expected way
of letting the forrest build
> > > know about a new plugin (at least until the
plugin is registered in the
> > > official plugin descriptor files)?
> >
> > That is an oversight in the documentation, it
would be good if you
> > could provide a patch to the docs.
> >
> > In this case you can add your entry directly to
the whiteboard
> > plugins.xml file as we will certainly be accepting
your plugin into
> > the whiteboard.
>
> I've committed this to SVN. It would be really good if
you could
> clarify the documentation for us.
>


Glad to do it. Hope changes to the
FORREST_HOME/site-author/content/xdocs/docs_0_90/howtohowto-
buildPlugin.xml
would do the trick.


> (are you subscribed to the svnforrest? [4] you should be
so that you
> can see updates we make to your code)


Yes, I got myself subscribed today.


>
> > > 2. When I ran the 'ant test' target against
the plugin, it failed saying
> > > that there are broken links in the site. I
found the culprit to be a couple
> > > of rdf:ID and  rdf:resource elements I
embedded in the xsl.
> > >
> > >  For example,  there's the following line in
the foaf-to-document.xsl
> > >  <a href="{foaf:homepage/rdf:resource}"><xsl:value-of
> > > select="foaf:homepage/rdf:resource"/></a>
> > >
> > >  When Forrest renders this link it leads to a
relative path like
> > > "http://localhost:8888/homepage_url_given_in_foaf:homep
age/rdf:resource".
> > >  How can we make it absolute, so that it will
be linked to
> > >
"homepage_url_given_in_foaf:homepage/rdf:resource" and not
> > > the relative url as in above?
> >
> > I'll need to look at this in the code to see
exactly what is
> > happening, I understand the question, but not the
context at present.
> > perhaps you should raise an issue about this. I
just added a new
> > "Plugin: input.FOAF" component to JIRA
for you.
>
> OK, I see the problem now:
>
> <foaf:schoolHomepage
rdf:resource="www.cse.mrt.ac.lk"/>
>
> This is not valid as far as I am aware. I believe an
rdf:resource must
> be a URI, which must include a scheme (i.e. http) (I'm
no RDF expert
> though). See [6]


Yes, you are absolutely right. Thanks a lot for finding this
mistake!
Too bad that the W3C RDF validator [7] didn't report this
error.
Anyway, it was my mistake to have included it in the example
FOAF file
in the first place.


>
> > > 3.I was able to see the transformation I
intended with the xsl at
> > > http://localh
ost:8888/personDetails.xml (in one of these
> > > forrest's internal doc forms I believe).
However, when I point my browser to
> > > http://local
host:8888/personDetails.html, I could only see
> > > a blank page with the default forrest skin
applied. The content was missing!
> > > Now, how is this page generated? Is the
> > > FORREST_HOME/main/webapp/sitemap.xmap
responsible for
> > > generating this html page?
> >
> > Yes. The document at [3] should help understand
the process, in
> > particular see the section "Understanding the
HTML-Pipeline"
> >
> > > More importantly, what changes should I make
to get those content from the
> > > transformed FOAF into that html?
>
> First observation is that your XDoc returned by
> http://localh
ost:8888/personDetails.xml is not a valid XDoc file.
For
> example, it includes <h1> elements which are not
valid - see [5].
>
> Secondly, it is given the namespace of http://www.w3.org/1999/x
html,
> which is obviously incorrect. This is because your XSL
uses a defaul
> XHTML namespace.
>


Thanks again for spotting these!
After removing the XHTML namespace the page was rendered
properly.
<h1>s and <h2>s didn't seem to do any harm.
Anyway, I will get rid of
those and use appropriate elements in their place to make it
a valid
xdoc.

Thanks & Regards,
Oshani

>
> > >  [1] https:
//issues.apache.org/jira/browse/FOR-1002
> > > [2]
> > > http://forrest.apache.org/docs_0_90/howto/howto-
buildPlugin.html
> > >
> >
> > [3] http:
//forrest.apache.org/docs_0_90/howto/howto-custom-html-sourc
e.html#Understanding%20the%20HTML-Pipeline
>
>
> [4] http:
//forrest.apache.org/mail-lists.html#Lists
> [5] http://forrest.apache.org/dtdx/document-v20.dtdx.html
> [6] http://en.wikipedia.org/wiki/Uniform_Resource_Identifier

>

[7] http://www.w3.org/RD
F/Validator/

Hi Gavin,


On 6/6/07, Gav.... <brightoncomputersbrightontown.com.au> wrote:
> Thanks Oshani, I have committed this initial code to
the whiteboard.
> I will take a good look at it and test drive it over
the next day or two
> and answer what I can then.
>
> As a side issue, your emails are coming through in
HTML, plain text would
> be better for the archivers and for quoting.
>


Oh, I seem to have forgotten to switch off rich formatting
before
posting to the list. I generally remember to do that before
posting to
public mailing lists, but like many things with this
initial
contribution, I seem to have overlooked this simple thing as
well!
Thanks for pointing it out! Will be extra more careful from
here on.

Also many thanks for committing my patch initially.

Regards,
Oshani

On 07/06/07, Oshani Seneviratne <oshaniapache.org> wrote:
> On 6/7/07, Ross Gardler <rgardlerapache.org> wrote:
> > On 06/06/07, Ross Gardler <rgardlerapache.org> wrote:
> > > On 06/06/07, Oshani Seneviratne
<oshaniapache.org> wrote:
> > > > I have created an outline FOAF plugin
and attached the patch to a JIRA issue
> > > > FOR-1002 [1] . I would really appreciate
if my mentor/co-mentor or any one
> > > > of the Forrest developers could take a
look at it and comment.
> > >
> > > Fantastic, well done Oshani. I will have time
to look over this later
> > > today if Gav or someone else does not beat me
to it.

...

> FWIW, I used TortoiseSVN to create the patch, and I
trust it do the
> job well because I have not had any problems in
creating patches with
> it in the past.

That's your first mistake, using a GUI - never trust the
little
beggers (only half joking).

> Anyway, I am really sorry for the extra trouble and the
time you
> wasted on going through my patch.

No need to be sorry. People have cleared up after me in the
past, this
is just part of the pay back. Besides, knowing that we all
makes
mistakes is what makes us willing to clear up after other
peoples.
It's only when we don't learn that we need to be sorry
(search the
archives for how many times I've not set my SVN line endings
correctly
- I'm certainly sorry about that each time 

> > > > So, my question is, is this the expected
way of letting the forrest build
> > > > know about a new plugin (at least until
the plugin is registered in the
> > > > official plugin descriptor files)?
> > >
> > > That is an oversight in the documentation, it
would be good if you
> > > could provide a patch to the docs.
> > >
> > > In this case you can add your entry directly
to the whiteboard
> > > plugins.xml file as we will certainly be
accepting your plugin into
> > > the whiteboard.
> >
> > I've committed this to SVN. It would be really
good if you could
> > clarify the documentation for us.
> >
>
>
> Glad to do it. Hope changes to the
>
FORREST_HOME/site-author/content/xdocs/docs_0_90/howtohowto-
buildPlugin.xml
> would do the trick.

Perfect.

> > First observation is that your XDoc returned by
> > http://localh
ost:8888/personDetails.xml is not a valid XDoc file.
For
> > example, it includes <h1> elements which are
not valid - see [5].
> >
> > Secondly, it is given the namespace of http://www.w3.org/1999/x
html,
> > which is obviously incorrect. This is because your
XSL uses a defaul
> > XHTML namespace.
> >
>
>
> Thanks again for spotting these!
> After removing the XHTML namespace the page was
rendered properly.
> <h1>s and <h2>s didn't seem to do any harm.
Anyway, I will get rid of
> those and use appropriate elements in their place to
make it a valid
> xdoc.

They don't do any harm if you are rendering to HTML as these
are valid
HTML elements. But try creating, for example, a PDF and
you'll see the
harm.

Thanks for your great work (and community engagement) so
far.

Ross

Oshani Seneviratne wrote:
> Ross Gardler wrote:
> >
> >... It would be really good if you could
> >clarify the documentation for us.
> 
> Glad to do it. Hope changes to the
>
FORREST_HOME/site-author/content/xdocs/docs_0_90/howtohowto-
buildPlugin.xml
> would do the trick.
> 
> >(are you subscribed to the svnforrest?
[4] you should be so that you
> >can see updates we make to your code)
> 
> Yes, I got myself subscribed today.

Oshani, i re-read some old emails wherein you said
that your exams were not over until mid-June.

It was great to get your initial plugin committed
at this stage. I know that we are all exited by the
progress.

However, please focus on your exams. Also all of us
should bear that in mind and not distract you.

-David