Hi Uwe,
I am really impressed by the speed your response and the universality of
your solution. Your TaggingDOMParser works just fine. Many thanks :-)
I agree that it's a common concern to locate the source of an error for
any context sensitive application (IDREFs are useful but this method is
too weak because of its global scoping). Maybe this is a problem of the
DOM standard ...
I think your solution is just fine. Wouldn't a hash table for the tags
create additional overhead? I will remove the SystemID from the Tags to save
memory. It is redundant to store it in every Tag. Maybe it should be replaced
by a pointer to the parent's SystemID -- similar to the static scoping found
in programming languages with nested blocks where a variable is searched in
the surrounding ("parent") blocks when is can't be located in the current
block...).
Thanks again :-)
Am Freitag, den 11. August 2006, um 18:07h schrieb [EMAIL PROTECTED]:
> First of all, this is one of these recurring questions that are asked
> all over again and again. Maybe the answer is put in a place so
> prominent (FAQ?) that it doesn't occur any more (I rember that I was
> asking the same question as well a couple of months ago)
>
> You will have to add tagging objects to each DOMElement while you let
> the DOMParser parse the XML file. So basically, what you do is is to
> derive a class from the DOMParser and override it's startElement
> function (yep, it is actually a SAXParser as well). Another option might
> be to maintain a hashtable with pointers to DOMNodes as keys, but I
> didn't do that (hmm, might not be too bad of an idea, maybe next time ;)
>
> The Tags need to be refernce counted if you want to clone nodes (hmm, I
> wonder if I do that in my project, actually), otherwise you'll end up
> with nasty lifetime issues for your Tag objects. For this reason, Tags
> are implemented with their own specific DataHandler, which takes care of
> these lifetime issues.
>
> However, I hope that the code I'm submitting here will answer it once
> and for all (although I don't guarantee it to be perfect nor performant,
> it just works for what I do, if it doesn't work for you it's your
> problem - and <disclaimer>I DONT TAKE RESPONSIBILITY FOR ANY PROBLEMS
> CAUSED BY IT</disclaimer> ;)
>
> Find snippets of the code I am using to do this.
>
> I hope this code is somewhat useful to you Michael, and also everyone
> else who stumbles over this problem. It that seems all too simple so
> that one would assume Xerces can do it out of the box, but unfortunately
> it can't.
>
> Cheers,
>
> Uwe
>
> ------------ from TaggingDOMParser.hpp:
[...]
> -------------------
>
> Oh, and StrX() is actually just a helper class that takes and XMLCh* in
> it's contructor and stores the UTF8-transcoded version, which can be
> obtained by it's getString() method; you might find a similar
> implementation in Xerces' examples
>
> Hope this helps, feedback welcome.
>
> Cheers,
>
> Uwe
> >is there a way to determine the line and column of the XML file
> >associated with a specific DOMNode / element? The data in my XML format
> >requires a few complex semantic validations that cannot be expressed by
> >the DTD. The simpler errors can be detected based on the context while
> >traversing the DOM tree and it would be nice to give more specific error
> >messages.
> >
> >Am I right that "DOMLocator" cannot be used since no "DOMError" occurs?
--
Michael Weitzel
