Hi all,
I mostly agree with all the agenda items however I won't be there. I would
like to add another one that I have previously mentioned on this list:
Can we have some elements hidden from the internet but still visible on the
intranet? For example we have some content such as individualName that we
wish to use to know who did what but we can't make this information public
because of the privacy act.
In this case it may be useful to use the gco:nilReason attribute with a value
of "withheld" to indicate that the content of this element and it's children
should not be displayed to the internet users.
This may require two XSLs. One for internet and one for intranet and other
groups. Alternatively, an XSL for editing could be different to an XSL for
presentation. This would allow "withheld" element content to be only visible
when the record is edited. The XSL rule for presentation would be something
like:
if @gco:nilReason = "withheld"
do not process this node and its children
This of course is not XSLT but a bit of pseudocode.
I would also like to see the XHTML removed from the XSL. That is, the
presentation could be done by XHTML or HTML with some reference to the XSL to
present the relevant XML in something like Xforms. This separation would
provide two advantages. One would be that a user can develop the look and
feel or skin of a web page without having to bother with the XSL.
Also the HTML component of a web page can be presented before the end of the
HTML is reached. If a large amount of XML is being transformed then the
client must wait for all the XSL to be processed before it can do any
presentation. If the output sent to the client is HTML then the client can
start doing the presentation while the XML is processed via the XSL. This
will make the results look much faster.
This is especially useful for the presentation of search results. If the
client has to wait for search results from all the remote server sites then
the presentation will wait until the slowest remote server responds.
However, if the presentation is in HTML then the results from the first
server to respond can be presented while the slowest server is still
processing the search.
This is something that is really nice to have when not all servers are equal
and users want results ASAP.
Thanks.
john
-----Original Message-----
From: geonetwork-devel-bounces@lists.sourceforge.net
[mailto:geonetwork-devel-bounces@lists.sourceforge.net] On
Behalf Of Davies Stephen
Sent: Wednesday, 11 June 2008 3:04 PM
To: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] Agenda for GeoNetwork hacking
in Bolsena&release planning [SEC=UNCLASSIFIED]Hi Jeroen,
I would like to see discussion on:1) Unit tests
GeoNetwork currently has an old version of junit.jar (version 2?) in
web/geonetwork/WEB-INF/lib. It's not used. Could the group discuss the
proposal that a) unit testing using JUnit be adopted b) JUnit
version 4.x
(latest) version be adopted.GeoNetwork is based on Java 1.5. The good news is that this allows
annotations. Would anybody be terribly upset if a /test
directory was added
to the project and that future work included creating
applicable unit tests
using JUnit annotated test cases?2) Adoption of a persistence framework
As of version 2.2.0 the GeoNetwork application cannot be deployed to a
cluster. Existing deployments probably haven't gotten to the
size where
clustering is necessary, but if this were to happen,
deployment to a cluster
will fail.There are several reasons for this. Firstly, the application
is storing
non-Serializable objects in the HttpSession. Not terribly
difficult to fix
but is still a show stopper.Secondly, and this is the real killer, the current mechanism
of generating
unique primary keys in jeeves.util.SerialFactory will fail in
a cluster due
to duplicate primary keys. The SerialFactory caches the max
primary key
values for each table. In a cluster multiple SerialFactory
instances will
exist and are oblivious of each other. The first node to
insert a record will
succeed, other nodes will fail.Geoscience Australia has deployed GeoNetwork using Oracle.
The correct way to
deal with this in Oracle is to use a SEQUENCE. This requires
generating
Oracle specific SQL, something the project has avoided doing.In my humble opinion, if GeoNetwork is to achieve its full
potential it needs
to be scalable. Issues like in memory key generation prevent this from
occurring. The bottom line is you need to need to be DB
independent but
scalable. The project should seriously consider the adoption
of a persistence
framework such as Hibernate.That's my 20 cents worth,
Stephen Davies-----Original Message-----
From: geonetwork-devel-bounces@lists.sourceforge.net
[mailto:geonetwork-devel-bounces@lists.sourceforge.net] On
Behalf Of Jeroen
Ticheler
Sent: Saturday, 7 June 2008 12:53
To: geonetwork-devel@lists.sourceforge.net
Subject: [GeoNetwork-devel] Agenda for GeoNetwork hacking in
Bolsena &release
planningHi all,
16-22 June we'll meet with quite some of the GeoNetwork
developers in
Bolsena. I wanted to start making an agenda for that week and
also see
what can be done ahead to make the meeting more efficient and give
others that are not in Bolsena a chance to provide their
inputs early
on.We have a range of projects lined up around the world that plan
developing functionality and we have to make sure these are
aligned as
much as possible or otherwise have a clear strategy on what,
where and
when functionality comes together.At present I see two major releases we have to plan for,
being version
2.3 and version 3.0. Version 2.3 could be released by 25 September
(before FOSS4G2008 starting 29 Sep in Cape Town), version 3.0
by March
2009. We may discuss a version 2.4 release if 3.0 is to risky
for some
or there are functions that can't be finished before 2.3 and
can't be
ported into 3.0 in time.I would like v2.3 to be finished before FOSS4G 2008
Rough plans for the versions (with surely many things missing
and I'm
also suggesting some directions, please add if I didn't add yours):v2.3
- CSW 2.0.2 ISO
- W*S harvesting
- GeoServer integration with direct deployment of W*S services on
upload of shapefiles and geotiffs
- Improved metadata editor (possibly in two flavors)
- First cut GUI plugin supportv3.0
- ebRIM CSW ISO support
- Application Profile plugin support
- upgraded web map client (discussion is needed here, using Open
Layers in combination with EXTjs may be the logical way to go. Also
with MapFish and with GeoServer GUI choices in mind).
- Search interface (probably rewritten from scratch) to be more
modular, removing a.o. tables, switching JavaScript API to EXTjs and
GUI themes as module support.For the agenda I will put a table on the developer WIKI that we can
fill in further.Looking forward to responses & ideas!
Ciao,
Jeroen--------------------------------------------------------------
-----------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork--------------------------------------------------------------
-----------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork