Lists Home |
Date Index |
- From: David Brownell <db@Eng.Sun.COM>
- To: David Megginson <firstname.lastname@example.org>
- Date: Mon, 01 Feb 1999 16:01:27 -0800
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.
> All the best,
> David Megginson email@example.com
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)