[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: ModSAX: Proposed Core Properties
Hi David, In a message dated 3/9/99 8:30:31 PM Eastern Standard Time, david@m... writes: > http://xml.org/sax/properties/dom-node <Node> (read-only) > Get the DOM node currently being visited, if the SAX parser is > iterating over a DOM tree. If the parser recognises and supports > this property but is not currently visiting a DOM node, it should > return null (this is a good way to check for availability before the > parse begins). > This has made me realize that I was under a misconception about what the generic get() and set() parser properties would provide in terms of functionality. What I was really hoping for was: org.w3c.dom.Document parse(InputSource is, boolean events) throws SAXException; org.w3c.dom.Document parse(java.lang.String uri, boolean events) throws SAXException; /* the events boolean would be to turn on/off event calls. */ Which would allow me to code: try { ModParser mp = ParserFactory.makeModParser(); boolean supported = true; try { mp.setFeature("http://xml.org/sax/features/dom-result", true); } catch (SAXNotSupportedException snse) { supported = false; } if (supported) { Document d = mp.parse("test.xml", false); // ... process Document } } catch (SAXException se) { // handle it } So, what I'm saying is that I would like to be able to choose whether to interface to the Parser via events or via a DOM. If you agree with this, I believe using the return type is more appropriate than getting a resultant property (as I suggest next). If for some reason the above is not palatable, the same could be accomplished under the current scheme if we added a property: http://xml.org/sax/properties/dom-document <org.w3c.dom.Document> (read-only) Then I could code: try { ModParser mp = ParserFactory.makeModParser(); boolean supported = true; try { mp.setFeature("http://xml.org/sax/features/dom-capable", true); } catch (SAXNotSupportedException snse) { supported = false; } if (supported) { mp.parse("test.xml"); Document d = (Document) mp.get("http://xml.org/sax/properties/dom- document"); // ... process Document } } catch (SAXException se) { // handle it } Note: both code examples also required an added feature to check for the desired functionality. I believe the above is sorely missing from the current API. Does anyone else see a need for this? If not, why not? But before you say, "build a layer on top of SAX" -- to me that seems ridiculous when most of the Parser implementations can produce a dom Document. Best wishes, - Mike (mdaconta@a...) 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...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|