Cart
[Home] [By Thread] [By Date] [Recent Entries]
>Here's another alternative for SAX2: forget about trying to report DTD >declarations as events, and simply make the whole DTD available >through an interface with a Parser2.get() call. > >I threw together a quick (read-only) DTD interface this morning, and >uploaded it to the following location > But, what would you use for the form of the DTD? Its almost certainly not going to be stored in that way internally in the parser's pools, i.e. it would most likely be much more optimized (or even just different for whatever reasons.) So you would either have to totally translate all of that into some instance of your DTD class, or you would have to make the DTD object just a call through to get the data from the parser. However, the latter scheme has problems if you want to reuse the parser instance because now you've tied an instance of the DTD access object to an instance of the parser and you cannot reuse the parser without frying the DTD access object (and you have have no idea how long people might want to hang onto that info.) The same issue kind of happens with any DOM DTD access that might happen down the road. If the DOM stores the element/entity/etc... stuff in its own form its going to be redundant since that data is already in the parser. However, the DOM implementation doesn't want to be tied to any particular parser implementation really so you kind of have to store it redundantly to avoid other issues. If you are going to store in some other format, and that is done at a SAX like level, then you still need event APIs to come out of the parser to fill in the SAX DTD object that you are going to give back, right? Hopefully this is a coherent response. I got multiply deeply nested interrupts while trying to write it. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
