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
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