Rebelling parser writers (Was: ]]> within a CDATA marked section ?)

[James Clark]

Richard Light wrote:
> 
> In message <01BCFB68.64DAE950 at xyplex34.uio.no>, Jarle Stabell
> <jarle.stabell at dokpro.uio.no> writes
> 
> >After attempting to process a document containing errors, I want to present to
> >the user a list of error messages, and when the user clicks on one of these
> >messages, I want to highlight the exact part of the document where the error
> >occurs.
> >The problem with entity expansion is that the parser isn't parsing what the
> user
> >literally wrote into the entity definitions, it is parsing a
> processed/"virtual"
> >version, which *may* not be a real subpart of the document, so one has to map
> >"virtual" locations/positions to physical (real document) positions, which
> >doesn't seem trivial to me. It is also likely to give slightly confusing error
> >messages, as it may be mentioning expanded stuff ("<xxx>") which the user never
> >wrote, the user may have written "&lt;xxx&gt;" etc.
> 
> I don't think this is as much of a problem as you fear.  Every entity is
> physically declared somewhere in a real source - usually a good ol' file
> on disc.  Of course, that file may not be the one you started from ...
> 
> My RunSP program (http://www.light.demon.co.uk/runsp) does exactly what
> you describe (for nsgmls).  It runs it under Windows and then allows the
> user to navigate from one error message to the next, in a simple editor
> environment that lets them sort out the problems they find.  All I did
> was to parse the error messages, pick out file name, line number and
> character offset, and place a bookmark at the relevant point in the file
> concerned.  This works equally well for errors in the DTD or SGML
> Declaration as for those in what we think of as the 'real document'.
> (Which is something that never occurred to me when designing RunSP - but
> of course the Declaration and DTD are equally part of the document as
> far as the parser is concerned.)

SP does exactly the sort of virtual location to physical location
mapping that Jarle was talking about.  For example, given a file
test.xml:

<!DOCTYPE doc [
<!ELEMENT doc (#PCDATA)>
<!ENTITY % e1 "!ELEMENT">
<!ENTITY e2 "&#60;%e1;">
]>
<doc>&e2;</doc>

nsgmlsu -e will report:

In entity e2 included from test.xml:6:9
nsgmlsu:test.xml:3:16:E: "ELEMENT" declaration not allowed in instance

The position it reports (column 16 in line 3 of test.xml) is the
position of "ELEMENT" in test.xml.  It has kept track of the fact that
the 3rd character in the replacement text of e2 came from the 2nd
character in the replacement text of e1 and that the 1st character in
the replacement text of e1 was specified at line 3 column 16 of
test.xml.  Implementing this is not trivial.

James



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)