[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SAX: Next Round (Lexical Event Handler)
David Megginson wrote: > > David Brownell writes: > > > > > I haven't checked, but I think that this gives us everything we need > > > > for DOM level one. > > > > Doesn't quite ... there's some more DTD information needed to: > > > > * ensure that PIs within the DTD (e.g. internal subset) > > don't show up anywhere in the DOM tree (ugh); > > You can determine this using the start/end DTD events and start/end > entity events, I think. Seemed like the start/end DTD event was for the external subset though. Sun's interface works that way, so this can be done given a real API description ... :-) > > * see declarations of external general entities; > > Do we need the declarations, or just the boundaries -- or, in other > words, do we need to provide information about declared but unused > external parsed entities? Sorry I'm too lazy to puzzle this out from > the spec right now. Actually I misspoke: It's not DOM that needs to see the declarations, it's the namespace spec which places a constraint that entity names be colon-free. (As noted, I was assuming namespaces should be layerable.) > > * expose values of defaults so that the DOM can ensure > > that defaulted attributes always have values; > > The parser should take care of this. Only if DOM and the parser are joined at the hips -- since when you remove a defaultable attribute from a DOM element, the DOM must then restore that value to its default value. (John Cowan also noted this.) > > * distinguish attributes which were defaulted from those > > that were explicitly in the document. > > Yes, this is necessary, as a few others have also pointed out > (grumble, grumble). > > > (In addition the above, if XML namespaces are to be layerable over > > a normal XML 1.0 parser, declarations of all other entities need to > > be exposed so they can be examined for conformance: they must not > > contain colons!) > > This is probably overkill for SAX -- if someone wants to layer > namespaces on top of SAX, they'll have to miss this one. ... or add new interfaces! > > > I wonder whether LexicalHandler ought to extend DocumentHandler. The > > > events it reports are synchronous with the events reported by > > > DocumentHandler. It seems to me that applications are always going to > > > want to implement either DocumentHandler or both DocumentHandler and > > > LexicalHandler. > > Probably -- the problem is that if we extend Parser then we'll have > both a setDocumentHandler and a setLexicalDocumentHandler event, and > that causes some funny problems that I'd rather punt. What I did is effectively group the two: if you set one, you set the other. One can always argue purity of essence, but that seemed to be the most useful choice for applications. - Dave > All the best, > > David > > -- > David Megginson david@m... > http://www.megginson.com/ 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/ 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
|