osdir.com
mailing list archive

Subject: Unexpected bahavior for XML validation with a DTD using 'sgml2pl' - msg#00085

List: ai.prolog.swi

Date: Prev Next Index Thread: Prev Next Index
With the package sgml2pl, I'm not able to do the validation
of a XML file with a DTD, because in the DTD my element name
are converted from uppercase to lowercase, and also because
missing element are automaticly generated in the DTD.

Here's a description of the beahavoir, with a XML file
and a DTD which should produce a validation error.

A simple XML file : 'my.xml'

<?xml version="1.0" encoding="iso-8859-1"?>
<A><C></C></A>


And a simple DTD file : 'my.dtd'

<!ELEMENT A (B)>
<!ELEMENT B (#PCDATA)>


The following prolog code

go :-
new_dtd('MY_DTD', DTD),
load_dtd(DTD, 'my.dtd'),
load_structure(
'my.xml', _,
[dtd(DTD), dialect('xml')]
),
dtd_property(DTD, elements(E)),
write(E).

Produce the following output:

[C, A, b, a]

No error reported! Base on this output, validation
with my DTD required to overcome the 2 following problems:

1) When loading the DTD, uppercase element name are converted
to lowercase. Any idea how to stop this behavior ?

2) When the parser reach an element not in my DTD, it
automagicaly add it to the DTD. Since I want to validate
the XML file, I need to stop to parser doing so.
Any clue how to change this behavior ?

Thanks.

I'm using SWI-Prolog (Multi-threaded, Version 5.2.11) on Linux.


Sebastien C.


__________________________________________________________
Lèche-vitrine ou lèche-écran ?
magasinage.yahoo.ca



Was this page helpful?
Yes No
Thread at a glance:

Previous Message by Date: click to view message preview

consistent segfault in PL_open_query

When I call PL_open_query with a functor that does not exist (i.e. PL_get_predicate was called successfully but the prolog rulebase does not contain the functor) then I get the following segfault (valgrind traceback) ==22677== Invalid read of size 4 ==22677== at 0x1CCA04DB: unify_definition (pl-comp.c:2911) ==22677== by 0x1CC92CBE: PL_error (pl-error.c:468) ==22677== by 0x1CCCD9D4: trapUndefined_unlocked (pl-proc.c:1537) ==22677== by 0x1CCCDAE6: trapUndefined (pl-proc.c:1574) ==22677== by 0x1CC8D5F1: getProcDefinedDefinition (pl-wam.c:903) ==22677== by 0x1CC86924: PL_open_query (pl-wam.c:1825) I think it tries to report some error but cannot because of the bad functor. HTH W

Next Message by Date: click to view message preview

Re: consistent segfault in PL_open_query

Wim, On Saturday 19 March 2005 17:25, wim delvaux wrote: > When I call PL_open_query with a functor that does not exist (i.e. > PL_get_predicate was called successfully but the prolog rulebase does not > contain the functor) then I get the following segfault (valgrind traceback) > > ==22677== Invalid read of size 4 > ==22677== at 0x1CCA04DB: unify_definition (pl-comp.c:2911) > ==22677== by 0x1CC92CBE: PL_error (pl-error.c:468) > ==22677== by 0x1CCCD9D4: trapUndefined_unlocked (pl-proc.c:1537) > ==22677== by 0x1CCCDAE6: trapUndefined (pl-proc.c:1574) > ==22677== by 0x1CC8D5F1: getProcDefinedDefinition (pl-wam.c:903) > ==22677== by 0x1CC86924: PL_open_query (pl-wam.c:1825) > > I think it tries to report some error but cannot because of the bad > functor. Thats not the problem. Functors and predicates are perfectly valid without a definition. The trouble was wrong order of initialisation in PL_open_query(), causing the error recovery failing to find the calling context (an improvement suggested by Paulo). Fixed. Cheers --- Jan P.s. I'm very unhappy valgrind doesn't work in SuSE 9.2, as far as I've investigated due to a kernel bug :-(

Previous Message by Thread: click to view message preview

consistent segfault in PL_open_query

When I call PL_open_query with a functor that does not exist (i.e. PL_get_predicate was called successfully but the prolog rulebase does not contain the functor) then I get the following segfault (valgrind traceback) ==22677== Invalid read of size 4 ==22677== at 0x1CCA04DB: unify_definition (pl-comp.c:2911) ==22677== by 0x1CC92CBE: PL_error (pl-error.c:468) ==22677== by 0x1CCCD9D4: trapUndefined_unlocked (pl-proc.c:1537) ==22677== by 0x1CCCDAE6: trapUndefined (pl-proc.c:1574) ==22677== by 0x1CC8D5F1: getProcDefinedDefinition (pl-wam.c:903) ==22677== by 0x1CC86924: PL_open_query (pl-wam.c:1825) I think it tries to report some error but cannot because of the bad functor. HTH W

Next Message by Thread: click to view message preview

Re: Unexpected bahavior for XML validation with a DTD using 'sgml2pl'

On Monday 21 March 2005 03:35, Sebastien Cabot wrote: > Base on this output, validation > with my DTD required to overcome the 2 following problems: > > 1) When loading the DTD, uppercase element name are converted > to lowercase. Any idea how to stop this behavior ? This is because loading DTDs from file doesn't allow specifying the dialect and the default dialect is SGML. Elements in SGML are case insensitive. I've added a new predicate load_dtd/3 using an option list. The option list provides dialect(Dialect) and encoding(Encoding). This is for the current development version (will be in 5.5.12). It doesn't easily backport due to the lack of stream encoding support in older versions. You get the correct result if you provide the DTD through the <!DOCTYPE directive though. > 2) When the parser reach an element not in my DTD, it > automagicaly add it to the DTD. Since I want to validate > the XML file, I need to stop to parser doing so. > Any clue how to change this behavior ? Not yet. It is deep inside the parser and indeed should be disabled by default if a DTD is provided explicitely. I do not have time to deal with this shortly. Please submit an enhancement request to Bugzilla if you want this issue to be picked up later. As a work-around, create a new DTD for each document. First objective of this parser has always been to read correct documents correctly. Getting sensible messages and `best' parser output from incorrect documents never had much priority. Crashes on incorrect documents are considered serious bugs though. Cheers --- Jan
Sign up for updates to this mailing list. email:
Loading Comments...
Home | News | Patents | Sitemap | FAQ | advertise

Advertising by