RE: VALID_MARKUP local DTD catalog

Hi Abel,


> *Is it possible that the Catalog Resolver is not downloading the DTDs
>  from the net when a particular one is not included in the local copy?
> (We had to add basic 1.1 DTD to the local DTD repository in order to
>  check this grammar)


Its my understanding that the default behaviour is that the
CatalogResolver will attempt to download the file referenced by SYSTEM
ID if it can't find a mapping to the something in the local catalogue.
This is something we want to avoid.


> *We have made the process of checking against a particular DTD (not
the
> declared one) extending the catalog resolver class and overwriting
> the resolver entity method. Might this be done through the
configuration
> of the Resolver?

I have never tried this. In ready.mobi this was achieved by swapping an
appropriate DOCTYPE into the document to be validated, and removing the
original one (if present). What you propose is to use a separate
resolver. If we do this, I wonder if we would need separate
CatalogManager.properties, and Catalog.xml files, or can these be
reused...?



Ruadhan




> -----Original Message-----
> From: Abel Rionda [mailto:abel.rionda@fundacionctic.org]
> Sent: 01 June 2007 12:02
> To: Ruadhan O'Donoghue
> Cc: public-mobileok-checker@w3.org
> Subject: RE: VALID_MARKUP local DTD catalog
> 
> 
> Hi,
> 
> Some comments related to markup validation test [1]:
> 
> *In the latest version of moki we have an XHTMLValidity element,
> But according with this test it would be better having two different
> Blocks such as
> 
> -<MarkUpValidity>: Validate against its declared DOCTYPE and report
>  errors (It is a simply rename of the current
>  XHTMLValidity element)
> 
> -<MobileValidity>: Validate against XHTML Basic and MP DTDs and report
> errors (perhaps it would better without any report of validation
> errors?)
> 
> [We have committed above changes]
> 
> Ruadhan, we have two questions:
> 
> *Is it possible that the Catalog Resolver is not downloading the DTDs
>  from the net when a particular one is not included in the local copy?
> (We had to add basic 1.1 DTD to the local DTD repository in order to
>  check this grammar)
> 
> *We have made the process of checking against a particular DTD (not
the
> declared one) extending the catalog resolver class and overwriting
> the resolver entity method. Might this be done through the
configuration
> of the Resolver?
> 
> 
> [1]
>
http://www.w3.org/TR/mobileOK-basic10-tests/#test_content_format_support
> 
> 
> Regards,
> 
> CTIC team.
> 
> -----Mensaje original-----
> De: public-mobileok-checker-request@w3.org
> [mailto:public-mobileok-checker-request@w3.org] En nombre de Ruadhan
> O'Donoghue
> Enviado el: jueves, 31 de mayo de 2007 16:13
> Para: Miguel Garcia; public-mobileok-checker@w3.org
> Asunto: RE: VALID_MARKUP local DTD catalog
> 
> 
> I've committed some code to this end:
> 
> (1) I've swapped out the JHOVE validation as the messages coming out
> weren't very helpful
> 
> (2) I've added a local catalogue of DTDs. The directory "dtd" contains
> three subdirectories: www.openmobilealliance.org, www.wapforum.org,
and
> www.w3.org
> 
> The paths to the DTDs we are interested in have been preserved in the
> local directory structure.
> 
> Should we include the Openwave XHTML MP DTD?
> 
> Are there any others?
> 
> Ruadhan
> 
> 
> > -----Original Message-----
> > From: public-mobileok-checker-request@w3.org
[mailto:public-mobileok-
> > checker-request@w3.org] On Behalf Of Miguel Garcia
> > Sent: 29 May 2007 12:58
> > To: public-mobileok-checker@w3.org
> > Subject: RE: VALID_MARKUP local DTD catalog
> >
> >
> > Hi,
> >
> > Yes, it is right solution having a catatalog with the common DTDs
used
> > by the checker.
> >
> > As Abel and I pointed in a study about third parties [1], JHOVE uses
a
> > SAX parser too and include several DTDs as internal resources in
> benefit
> > of efficiency. (None of mobile DTDs are included).
> >
> > To fullfil this, JHOVE uses an adhoc DTDMapper which we should
extend
> in
> > order to add new DTDs.
> >
> > On the other hand, in JHOVE is possible to specified the SAX parser
> > implementation [2] but we don't know
> >
> > If the CatalogResolver can be set in a external manner avoiding
modify
> > JHOVE source code. (e.g we haven't access to the parser object to do
> > this method call:
> >
>
reader.setProperty("http://apache.org/xml/properties/internal/entity-res
> > olver", resolver);
> > )
> >
> > [1] http://docs.google.com/Doc?id=dhbw7zt7_0f8w6bq
> > [2] http://hul.harvard.edu/jhove/xml-hul.html
> >
> > Regards,
> >
> >
> > Miguel
> > ________________________________________
> > De: public-mobileok-checker-request@w3.org
> > [mailto:public-mobileok-checker-request@w3.org] En nombre de Jo
Rabin
> > Enviado el: martes, 29 de mayo de 2007 12:19
> > Para: Ruadhan O'Donoghue; public-mobileok-checker@w3.org
> > Asunto: RE: VALID_MARKUP local DTD catalog
> >
> > Good point.
> >
> > The test is "If the document is an HTML document and it fails to
> > validate according to its given DOCTYPE , FAIL"
> > So we need a reasonable catalogue of known html and html dtds. We
> don't
> > need any non-html dtds and I agree that we should not go fetch
random
> > dtds.
> >
> > Jo
> > ________________________________________
> > From: public-mobileok-checker-request@w3.org
> > [mailto:public-mobileok-checker-request@w3.org] On Behalf Of Ruadhan
> > O'Donoghue
> > Sent: 29 May 2007 11:11
> > To: public-mobileok-checker@w3.org
> > Subject: VALID_MARKUP local DTD catalog
> >
> > Hi,
> >
> > I'm not sure if anyone has been looking at this, but for validating
> the
> > original document, we are going to need a local catalog of DTDs. In
> > ready.mobi we use the Xerces CatalogResolver class to map between
> > DOCTYPEs and local copies of the DTDs.
> >
> >
> > Any thoughts on the following?
> >
> > (1) We need to validate the document against its stated DOCTYPE and
> > XHTML Basic 1.1 (and maybe 1.2). So the set of DTDs that we wish to
> > store locally should include
> > XHTML Basic*, MP*, HTML*
> >
> > Are there others? And do we store variations like the Openwave XHTML
> > DTDs which turn up quite a bit? Perhaps we should compile an
> exhaustive
> > list of the DOCTYPES that we will recognise.
> >
> >
> > (2) The behaviour when a DOCTYPE specifies an obscure DTD not in the
> > catalog - fetching a DTD from the wild is not a good idea, so we
> should
> > just report an "unrecognised DOCTYPE - will not try to validate"
> > error... Is this the desired behaviour?
> >
> >
> > Ruadhan
>

Received on Thursday, 7 June 2007 16:06:28 UTC