[GeoNetwork-devel] [ geonetwork-Bugs-1558489 ] schema mistackes 19115 + Cor. 19115

Badoo1 · September 14, 2006, 10:11am

Bugs item #1558489, was opened at 2006-09-14 03:11
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=533368&aid=1558489&group_id=72096

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Other functionality
Group: v2.1.0
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: schema mistackes 19115 + Cor. 19115

Initial Comment:
I notice some mistakes in the actual schema GN in
regard with the 19115 standards and the corrigendum 19115.

mdLang/languageCode --> The domain of the content of
the ""language"" element is ISO 639-2. "-2"
specifies the three letter abbreviation used for
different countries. "-1"
specifies the two letter abbreviation. Therefore, the
pick list for the ""language"" element should contain
three letter values like ""eng"" for ""English"" not
two letter values like ""en"". Use the list from
http://www.loc.gov/standards/iso639-2/langhome.html

gmd:dataSetURI --> miss in GN
distInfo --> miss the link with distributionFormat
(distInfo/distorFormat)
spatRepInfo/Georect/numDims --> Type Integer (actual
string)
spatRepInfo/Georect/chkPtAv --> Type Booleen (actual
string)
spatRepInfo/Georect/chkPtAv/orieParaAv --> Type Booleen
(actual string)
spatRepInfo/Georect/chkPtAv -->Type Booleen (actual string)
spatRepInfo/Georect/chkPtAv --> Type Booleen (actual
string)
spatRepInfo/GridSpatRep/tranParaAv --> Type Booleen
(actual string)
dataExt/geoEle/BoundPoly/exTypeCode --> Type Booleen
(actual string)
dqReport/DQElementTypes/measResult/ConResult/conPass
--> Type Booleen (actual string)
contInfo/ImgDesc/lensDistInAv --> Type Booleen (actual
string)
contInfo/ImgDesc/filmDistInAv --> Type Booleen (actual
string)
contInfo/ImgDesc/camCalInAv --> Type Booleen (actual
string)
contInfo/ImgDesc/radCalDatAv --> Type Booleen (actual
string)
contInfo/ImgDesc/trianInd --> Type Booleen (actual string)
contInfo/FetCatDesc/incWithDS --> Type Booleen (actual
string)
contInfo/FetCatDesc/compCode --> Type Booleen (actual
string)
dataIdInfo/dataExt/vertEle --> [Corrigendum
19115]Delete vertUoM. Change the name vertDatum to vertCRS
refSysInfo/MdCoRefSys --> [Corrigendum 19115]to delete
gmd:locale [Corrigendum 19115]to implement in GN.
Implementation use to explain ?
geoBox/westBL + eastBL + southBL + northBL -->
[Corrigendum 19115]change type xs:string to xs:decimal.

Pierre.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=533368&aid=1558489&group_id=72096

Andrew_Davie · September 18, 2006, 5:14am

What exactly is it about the code that mandates a 1.4 JVM? In my
experience, JVMs are typically backward compatible (that is, you can
generally run earlier code on later JVMs without recompilation). Why is it
that GeoNetwork *requires* 1.4. This seems totally backwards to me, and
certainly inconvenient.
Cheers
A
--
Andrew Davie
Geometry.

ticheler · September 21, 2006, 12:45pm

Hi Andrew,

On Sep 18, 2006, at 7:14 AM, Andrew Davie wrote:

What exactly is it about the code that mandates a 1.4 JVM? In my
experience, JVMs are typically backward compatible (that is, you can
generally run earlier code on later JVMs without recompilation). Why is it
that GeoNetwork *requires* 1.4.

You can use Java 1.5 without problems. 1.4 is the minimum you require as earlier version can not deal properly with the XML/XSL stuff.
Does that help?
Ciao,
Jeroen

This seems totally backwards to me, and
certainly inconvenient.
Cheers
A
--
Andrew Davie
Geometry.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
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

Andrew_Davie · September 22, 2006, 3:40am

Thank you for the reply. I perhaps wasn't as clear as I could have been.

When I used Java 1.5, things are OK. Specifically, I can run the "Start
Server", and then load "Open GeoNetwork Opensource" link. And all loads OK.

I can't do this when I use Java 1.6. I can still run the "Start server" OK,
but when I try to load "Open GeoNetwork Opensource" I get an exception in
the "Start server" window (shown below) and the page says "Transformation
error // Could not compile stylesheet".

The exception is...

ERROR:
'file:///C:/Program%20Files/geonetwork_desktop/web/xsl/main-page.xsl: line
5: Circular variable/parameter reference in '[variable(geonetUri)]'.'
FATAL ERROR: 'Could not compile stylesheet'
javax.xml.transform.TransformerConfigurationException: Could not compile
stylesheet
        at
com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTempl
ates(Unknown Source)
        at
com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTrans
former(Unknown Source)
        at jeeves.utils.Xml.transform(Xml.java:120)
        at jeeves.utils.Xml.transform(Xml.java:111)
        at
jeeves.server.dispatchers.ServiceManager.dispatchOutput(ServiceManager.java:
606)
        at
jeeves.server.dispatchers.ServiceManager.dispatch(ServiceManager.java:381)
        at jeeves.server.JeevesEngine.dispatch(JeevesEngine.java:614)
        at
jeeves.server.sources.http.JeevesServlet.execute(JeevesServlet.java:170)
        at
jeeves.server.sources.http.JeevesServlet.doGet(JeevesServlet.java:99)

        at javax.servlet.http.HttpServlet.service(HttpServlet.java:596)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
        at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427)
        at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandl
er.java:473)
        at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
        at org.mortbay.http.HttpContext.handle(HttpContext.java:1565)
        at
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext
.java:635)
        at org.mortbay.http.HttpContext.handle(HttpContext.java:1517)
        at org.mortbay.http.HttpServer.service(HttpServer.java:954)
        at org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
        at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983)
        at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
        at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:
244)
        at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
        at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)

This is why I asked my question about version compatibility. I can
understand not being able to *downgrade* Java versions -- you would miss
functionality that has been added to the later version. But not being able
to **upgrade** Java versions is what I was complaining about!

Right now I have to switch between Java 1.6 (my main JVM and preferred
environment) for all my other development, and Java 1.5 (for GeoNetwork
only). It's very inconvenient.

Cheers
A
--
Andrew Davie
Geometry.

-----Original Message-----
From: Jeroen Ticheler [mailto:Jeroen.Ticheler@anonymised.com]
Sent: Thursday, 21 September 2006 10:46 PM
To: Andrew Davie
Cc: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] what specifically is it about JVM 1.5+ ?

Hi Andrew,

On Sep 18, 2006, at 7:14 AM, Andrew Davie wrote:

What exactly is it about the code that mandates a 1.4 JVM? In my
experience, JVMs are typically backward compatible (that is, you can
generally run earlier code on later JVMs without recompilation).
Why is it
that GeoNetwork *requires* 1.4.

You can use Java 1.5 without problems. 1.4 is the minimum you require
as earlier version can not deal properly with the XML/XSL stuff.
Does that help?
Ciao,
Jeroen

This seems totally backwards to me, and
certainly inconvenient.
Cheers
A
--
Andrew Davie
Geometry.

----------------------------------------------------------------------
---
Using Tomcat but need to do more? Need to support web services,
security?
Get stuff done quickly with pre-integrated technology to make your
job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?
cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
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

ticheler · September 22, 2006, 6:56am

Hi Andrew,

On Sep 22, 2006, at 5:40 AM, Andrew Davie wrote:

This is why I asked my question about version compatibility. I can

understand not being able to downgrade Java versions – you would miss

functionality that has been added to the later version. But not being able

to upgrade Java versions is what I was complaining about!

OK, I think I get your problem. I understand you work with the Early Access version of Java 6, is that correct?
In case it is, you are possibly the first one to use that version and you may have run into a problem that relates to stricter handling of XML. We had similar issues while upgrading from earlier versions of JVM and I do not consider these the error of our project, but more a side effect of XML technologies still evolving. If you’re able to identify the error and fix it, we are happy to get the fix into the code so you can happily use Java 6.

Right now I have to switch between Java 1.6 (my main JVM and preferred

environment) for all my other development, and Java 1.5 (for GeoNetwork

only). It’s very inconvenient.

Understood, please help fix the issue you have and we’ll all be happy as that’s what the project is all about, getting better code and functionality!

Ciao,
Jeroen