W3C home > Mailing lists > Public > public-mobileok-checker@w3.org > March 2011

Re: problems with the latest source code

From: Francois Daoust <fd@w3.org>
Date: Thu, 31 Mar 2011 20:06:08 +0200
Message-ID: <4D94C290.5050007@w3.org>
To: Matteo Bertamini <matteo.bertamini@studenti.unitn.it>
CC: public-mobileok-checker@w3.org
Hi Matteo,

Sorry for the slow response.


On 03/21/2011 05:56 PM, Matteo Bertamini wrote:
> Heya folks,
> I'm using this library for some tasks I'm working on Accessible project (http://www.accessible-eu.org/) and  I downloaded the latest version through CVS, I created a netbeans project by following the (dated) guide and I tried to launch a test but I always obtain this error:
[...]
> Cannot find CatalogManager.properties
[...]
> mobok.org.w3c.mwi.mobileok.basic.TestException: java.net.MalformedURLException: no protocol: %
> mobok.org.w3c.mwi.mobileok.basic.XhtmlContent.validateMobile(XhtmlContent.java:904)
[...]
>
> I really can't understand this output: where CatalogManager.properties should be? It's in the working directory with its dtd directory! And also: I can't understand the "no protocol" error. Unfortunately, I used to have a former version of the code, and it used to work perfectly! May someone can help me? How could I fetch older versions of the code? What's happening?

The "Cannot find CatalogManager.properties" message is the important message here. It means that the file that tells the mobileOK Checker where to look for the local catalog of DTDs has not been found. In the default source code, this file is in the "src" folder, at the same level as the "org" folder:
  http://dev.w3.org/2007/mobileok-ref/src/CatalogManager.properties

This file should normally get searched for in the classpath of the application. I do not know why it doesn't get picked up in your case. Could it be because you've prefixed all namespaces with "mobok"?

In particular, if the file is still at the same level as the "org" folder (which is not the root folder anymore in your case), it might not be picked up appropriately.

If that's not the reason, that's still where you should look: the CatalogManager.properties file needs to be loaded for the mobileOK Checker to find out whether it knows a DTD or not.

The exception that occurs next is a side effect of the previous problem. The MalformedURLException is triggered "manually" in the code on purpose to raise the fact that the DTD could not be found to avoid the resolution of an unknown DTD (which would involve an HTTP exchange with the remote server targeted by the DTD). It's not elegant, but I could not find any other way to prevent that resolution.

That's needed for performance reason and because the markup of the page under test is only validated against known DTDs: the mobileOK Checker does not try to validate it against the declared DTD when that DTD is unknown.

That said, no matter what the declared DTD may say, the markup of the page under test is always validated against the XHTML Basic 1.1 DTD, which is supposed to be a known DTD. In your case, since the catalog could not be loaded, the XHTML Basic 1.1 DTD becomes "unknown", and the exception gets raised. As soon as you fix the catalog loading problem, this exception should disappear.

I don't recall any change in the code in the last year or so that might have affected catalog resolution, but I might have forgotten something. I'm not familiar with Netbeans. Could that change the way the classpath is defined somehow?

Francois.

>
> Thanks in advance for your precious help,
> Matteo
Received on Thursday, 31 March 2011 18:06:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 31 March 2011 18:06:47 GMT