SAX: Next Round (Lexical Event Handler)

[David Brownell]

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 at megginson.com
>            http://www.megginson.com/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)